[Bug]: Deleted trailing pages return when downloading after restoring page order

Attach (recommended) or Link to PDF file

three_pages_with_number.pdf

Web browser and its version

Chrome 152.0.7977.83

Operating system and its version

macOS 26.6.2

PDF.js version

Local generic build from master at ee470d5db4c8517ea3ccbfc489deab9311cc3a81.

Is the bug present in the latest PDF.js version?

Reproduced on the current master above with enableSplitMerge enabled. This preference is disabled by default in the generic build; I have not verified the hosted demo or Firefox's built-in viewer.

Is a browser extension

No.

Steps to reproduce the problem

1. Build the generic viewer with npx gulp generic and serve the repository with npx gulp server.

2. Open http://localhost:8888/build/generic/web/viewer.html?file=/test/pdfs/three_pages_with_number.pdf and enable page editing. For a local test, run this in the viewer's console and reload:

   localStorage.setItem("pdfjs.preferences", JSON.stringify({ enableSplitMerge: true }));
   location.reload();
   

3. Open the Pages sidebar, select page 3 using its checkbox, and delete it. The viewer now has pages 1 and 2.

4. Drag the second thumbnail before the first, giving the order [2, 1].

5. Drag the second thumbnail before the first again, restoring [1, 2].

6. Download the PDF using the main toolbar's Save button and reopen it.

What is the expected behavior?

The downloaded PDF should contain only pages 1 and 2, in that order, matching the viewer.

What went wrong?

The viewer still shows two pages, but the downloaded PDF contains all three original pages. Downloading immediately after step 3 correctly produces two pages; the two subsequent moves cause the deleted page to return.

Additional context

PagesMapper.movePages() clears the mapping when each remaining page ID equals its position plus one. After deleting the last page, [1, 2] satisfies that check even though the original document had three pages. hasBeenAltered() then returns false, so downloadOrSave() takes the original-data download path.

I reproduced the sidebar interactions in Chrome and reparsed the downloaded bytes to check the page count. No JavaScript exceptions were reported. I checked the related GitHub issues/PRs and Bugzilla PDF Viewer reports and did not find a matching report.

Reproduce the problem with the generic viewer using npx gulp generic and npx gulp server, then trace PagesMapper.movePages(), hasBeenAltered(), and downloadOrSave(). Verify that deleting page 3 and restoring the order [1, 2] still produces a downloaded PDF containing only pages 1 and 2.