User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Windows 8.1, Firefox 84.0.1 (64-bit). A printer driver is present (may be virtual).
• Open any multi-page PDF file (may work with webpages too). Pages should be distinct to make the result apparent.
• Hit Ctrl+P to open the system print dialog.
• Enter "2,1" (no quot.) or any other list of single pages in non-ascending order.
• Optional: Use a virtual printer or the "Preview" function of your printer's driver to save paper.
• Hit Print.

Actual results:

The print ranges have been sorted in ascending order by page, and the result then passed to the printer driver. If you entered "2,1" as your print range, page 1 was printed first and then page 2.

While the bug is minor and only affects a small portion of users, it makes printing booklets and other more complicated materials very difficult, if the printer's driver does not support them natively.

Expected results:

The list of pages passed to the printer should have remained unsorted. In my example, page 2 should have been printed before page 1.

Also please note that this is a result of Bug #499640 getting fixed a month ago.

Hmm, are you sure of the regression range? bug 499640 landed in 85. Is there any chance you could run mozregression to see what actually broke it?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Hmm, are you sure of the regression range? bug 499640 landed in 85. Is there any chance you could run mozregression to see what actually broke it?

Strange, I was one of the users who urged (hi jwatt!) the fix of Bug #499640, and have observed its fix, as well as this bug in its implementation, now (currently running 84.0.1, last update 2020-12-26). This bug could not have existed before the fix of Bug #499640 (could not input non-ascending page numbers when only one print range was available), so I am afraid that mozregression would be of no use. If you think otherwise and have it installed, run it and see for yourself.
Also printing from other applications (those using the system dialog) does not exhibit this bug, so it is most likely on Firefox's side.

Thanks for reporting!

This was the expected behavior for bug 499640, so it's not a regression. Though we may want to think about supporting this in the future

(In reply to Emma Malysz from comment #3)

This was the expected behavior for bug 499640

I disagree with your assessment (defect→enhancement), but I am not going to revert it as I understand why you made it:
I understand why the developer implemented page sorting: it was an attempt to make the software smarter, but an unintentional effect was that the software is now less intuitive and offers fewer options. Sorting page ranges is not standard behavior for programs using the Windows print dialog, so there is a risk of confused users and wasted paper. Since this "feature" is redundant (most users input the print ranges sorted, and those who don't do it on purpose), I do not see a great
Please just remove the "feature" so that users get the expected result out of your product - it takes, after all, much less developer effort to remove code than to write more.

(In reply to Václav Trpišovský from comment #4)
Correction:

I do not see a great
...reason why it should be kept.

Set release status flags based on info from the regressing bug 499640

(In reply to Václav Trpišovský from comment #4)

I disagree with your assessment (defect→enhancement), but I am not going to revert it as I understand why you made it:
I understand why the developer implemented page sorting: it was an attempt to make the software smarter, but an unintentional effect was that the software is now less intuitive and offers fewer options. Sorting page ranges is not standard behavior for programs using the Windows print dialog, so there is a risk of confused users and wasted paper. Since this "feature" is redundant (most users input the print ranges sorted, and those who don't do it on purpose), I do not see a great
Please just remove the "feature" so that users get the expected result out of your product - it takes, after all, much less developer effort to remove code than to write more.

This is a misunderstanding about what's going on. We didn't add code to do page sorting which we could simply remove. Instead, we simply always print documents in-order, and we filter out pages based on whether or not they're in the page range.

As far as I can tell:

• On Linux (my local platform), Firefox has always had this behavior (when printing with the legacy system dialog).
• On Mac, the system dialog doesn't seem to let you specify a complex page range at all (it only has "from/to")
• On Windows 10, the system dialog doesn't seem to let you specify a complex page range (it says "enter either a page number or a single page range") [EDIT: I made this observation using Firefox release, v84; apparently this was because we were using an old dialog option there, and we switched in bug 1675956]

Also on Windows: for comparison, Edge and Chrome do let you specify a complex page range, but they still print the pages in ascending order of page-number.

So I'm not seeing any browser/platform/configuration where the behavior matches your "expected behavior" from comment 0. Am I missing something? Is there a browser that does the thing you want on this?

(In reply to Daniel Holbert [:dholbert] from comment #7)

• On Windows 10, the system dialog doesn't seem to let you specify a complex page range (it says "enter either a page number or a single page range")

Hmm, maybe the print dialog is different on Windows 8.1 - I just tested in BrowserStack and I do see that it offers "Enter page numbers and/or page ranges separated by commas" there. I can't actually see what the printed output looks like there, but maybe that is one platform where this behaves like you expect.

It would be useful to know whether Chrome matches your expected behavior vs. matches what Firefox is doing. (I would bet it matches what Firefox is doing, and how printing behave with the system dialog on other platforms where complex ranges are allowed.)

Ah, it looks like the "Enter a page number" vs. "Enter page numbers" behavior in the system dialog is a configurable thing, and depends on the way you set up the system dialog; and we switched from the former behavior to the latter behavior (for the system dialog) in bug 1675956.

(In reply to Daniel Holbert [:dholbert] from comment #9)

Ah, it looks like the "Enter a page number" vs. "Enter page numbers" behavior in the system dialog is a configurable thing, and depends on the way you set up the system dialog; and we switched from the former behavior to the latter behavior (for the system dialog) in bug 1675956.

Yes, you are correct, the complex page ranges are available since the fix of Bug #1675956.

To clear the needinfo request you made... the following describe my experience with printing on Windows only (have never printed from another OS).
• Chromium-based browsers (incl. the current Edge) use either their own print dialog (called by Ctrl+P) or the system dialog (Ctrl+Shift+P), both of which allow for non-continuous print ranges. I have never used the built-in one due to higher lag and lack of options (cannot even show printer properties!), but it outputs pages in ascending order. On the contrary, the system dialog prints pages in the specified order.
• Internet Explorer 11 uses Acrobat's print dialog when printing PDFs (with non-consecutive print range support), and outputs pages in the specified order. On the other hand, it uses the system dialog when printing webpages and does not allow for complex page ranges at all.
• All other programs I used to print more complicated documents (MS Office (1997-365), Adobe Reader, Sumatra PDF) allowed for non-continuous print ranges (either in the system dialog or a custom one) and printed in the specified order.
• Other Windows programs I tested (Notepad, WordPad) do not allow non-continuous print ranges.

So, the only program that I know to "sort" pages while printing is Chromium while using its clumsy custom dialog, or Firefox 86 or newer (only applicable after the fix of Bug #1675956). (I actually saw the fix in FF84, but the official record of the bug disagrees with me so nevermind.)

This does not change the point I made before:

Sorting page ranges is not standard behavior for programs using the Windows print dialog, so there is a risk of confused users and wasted paper. Since this "feature" is redundant (most users input the print ranges sorted, and those who don't do it on purpose), I do not see a great reason why it sould be kept.

If anyone has experience with printing or have other OSs to test, feel free to add more info.

(In reply to Václav Trpišovský from comment #10)

To clear the needinfo request you made... the following describe my experience with printing on Windows only (have never printed from another OS).

(Really appreciate you providing this additional detail - thanks!)

• Chromium-based browsers (incl. the current Edge) [...] the system dialog prints pages in the specified order.

Are you sure about this? (Is this based off of memory, or did you re-test and confirm this behavior in these browsers?)

I ask because I tried to verify this locally but was unable to do so. In my environment, Chrome and Edge don't successfully print anything when I use the system dialog and print a reversed-order page selection. (I used https://www.mozilla.org/en-US/MPL/2.0/ as my testcase, and I chose "5,1" as the page numbers. If I do this with Microsoft Print-To-PDF as the printer, I get a 0-byte PDF which fails to open; and when I use a physical printer, the print job gets stuck at the "spooling" phase in the local print queue, and nothing ever prints.

This does not change the point I made before:

The upshot of your point there is essentially that we shouldn't keep this sorting "feature" - but per beginning of comment 7, it's not really a feature that we could remove, but rather just a natural outcome of the way that our printing pipeline works. It would be possible for us to change that, but it's not a trivial change (and not as simple as just turning something off).

Implementation note for developers potentially working on this in the future:

• We have a distinction between "PrintedSheetFrame" (the physical blank sheet) vs. nsPageFrame (the actual page of content that gets placed onto it -- or pages of content, in e.g. 4-pages-per-sheet mode)
• Right now, the way things work is that all of the pages get assigned to some sheet, in ascending order. So e.g. if we have 4-pages-per-sheet, then the first sheet has Page 1-4, Sheet 2 has Pages 5-8, etc.
• If there's a print range, then that's handled by simply marking pages as un-displayed and giving the sheet an extra page to compensate. So e.g. if you had a user-providd print range of pages "1,2,4,7-10" with 4 pages per sheet, then: Sheet 1 would own pages 1-7 (with 1,2,4,7 displayed and the out-of-range pages marked as undisplayed), and Sheet 2 would manage pages 8-10 (or really 8-N, if this is an N-page document for some N > 10; and pages 11-N would be marked as undisplayed).
• In a 1-page-per-sheet mode (the default), with that same print range, it still ends up similar albeit a little simpler -- sheet 1 owns Page 1, while Sheet 2 would own Pages 2 and 3 (with page 3 marked as undisplayed), and sheet 3 would own pages 4-6 (with pages 5 and 6 marked as undisplayed), etc.

This all has the nice invariant that a nsPageFrame's next-continuation-chain (all of the higher-numbered pages, and all their content) will all be later siblings in its own sheet, or they'll be in one of its sheet's next-continuations. None of its next siblings will be in a previous sheet.

To fix this bug properly (especially in a robust way that works with pages-per-sheet), we would need to break that invariant, I think. Or maybe cheat around it in some way.

(In reply to Daniel Holbert [:dholbert] from comments #11 and #12)

Is this based off of memory, or did you re-test and confirm this behavior in these browsers?

I failed to install Microsoft Print-to-PDF so I could not replicate that (I will try later today). I used my physical printer driver (Epson L3050) unless specified but I do not see a reason why this shouldn't work with any other driver.
• Firefox: Used both a physical (Epson L3050) and a virtual (Microsoft XPS Document Writer) to test right before my bug submission.
• Chromium (Google Chrome 87.0.4280.88, "un-Googled" version 84.0.4107.0, as well as Edge 87.0.664.66): I tested both print methods yesterday using my physical printer, with results I posted above.
• IE11: I tested both print "methods" (from both PDF and HTML) yesterday using a physical printer, with results I posted above. The built-in PDF browser (Acrobat) might be an add-on (never investigated this).
• Word 1997: I vividly remember printing a booklet from my grandfather's computer (Windows 7, around 2017) on an old OKI laser printer. It used the system dialog (or a similar-looking one) and allowed me to shuffle pages.
• Word 2007: I tested today to refresh my memory: it used the its own dialog (which looked almost like the system one), and allowed me to shuffle pages.
• Word 365: I tested yesterday: it used its own dialog, and allowed me to shuffle pages.
• Adobe Acrobat Reader DC: I tested today to refresh my memory: it used its own dialog, and allowed me to shuffle pages.
• Sumatra PDF: I tested today to refresh my memory: it used the system dialog, and allowed me to shuffle pages.
• Notepad and WordPad: I tested yesterday, both with aforementioned results.

I could post screenshots if you wish.

In my environment, Chrome and Edge don't successfully print anything when I use the system dialog and print a reversed-order page selection.

Strange, I verified with the same document and page range, though with other printer drivers (Epson L3050 and Microsoft XPS Document Writer) and a different system (Windows 8.1), and got results described above. I will try Microsoft Print-to-PDF on Windows 10 later today. Please note that the MS XPS Document Writer (at least in my case) first created a 0-byte XPS file and only then wrote content to it, so after a minute the file was complete and openable - if you attempted to read it before, you got an error. So please check if you can print at all, and note that your printer's driver will probably not even display a preview if the printer is unavailable.

Also sorry for being naïve about what I thought was a "sorting" function: I am just an advanced user, not a developer, and I have never seen a line of Firefox code in my life. Thank you for giving a detailed insight for future developers trying to implement a fix.

Another point you made:

robust way that works with pages-per-sheet

This should not be an issue since this is usually done on the driver's side. I haven't had any issues with this, whether it was specified in the system dialog, a custom dialog, or printer properties.

(In reply to Daniel Holbert [:dholbert] from comment #11)

I ask because I tried to verify this locally but was unable to do so. In my environment, Chrome and Edge don't successfully print anything when I use the system dialog and print a reversed-order page selection. (I used https://www.mozilla.org/en-US/MPL/2.0/ as my testcase, and I chose "5,1" as the page numbers. If I do this with Microsoft Print-To-PDF as the printer, I get a 0-byte PDF which fails to open; and when I use a physical printer, the print job gets stuck at the "spooling" phase in the local print queue, and nothing ever prints.

I am back and have tested with a setup similar to yours. The solution is to wait a few minutes until Microsoft Print to PDF completes writing to the file - until then, it appears as 0 bytes. I cannot troubleshoot for your physical printer, but check if you can print at all - there may be another issue.
Here is the summary of what I did:
Software: Windows 10 x64 v1909 build 18636.1198, Google Chrome 87.0.4280.88 x64, Microsoft Print to PDF driver version 10.0.18362.1, driver date 2006-06-21 (found in the printer's "Hardware Properties")
Document: https://www.mozilla.org/en-US/MPL/2.0/
Page Range: 5,1
Note: All print functions in my system are set to A4 paper, you may get slightly different content on each page if you use another. If the paper is so big that the document fits within 4 pages, page 5 will not even exist!

Experiment 1:
Printed pages "5,1" with the built-in dialog (Ctrl+P). A 0-byte file was created, and after 2 minutes of refreshing File Explorer, I saw its size jump to 685,596 B. It contained page 1 (starts with "MOZILLA PUBLIC LICENSE") and then 5 (starts with "the Covered Software is not [...]").

Experiment 2:
Printed pages "5,1" with the system dialog (Ctrl+Shift+P). A 0-byte file was created, and after 2 minutes of refreshing File Explorer, its size jumped to 665,267 B. It contained page 5 (starts with "the Covered Software is not [...]") and then 1 (starts with "MOZILLA PUBLIC LICENSE").

Thanks for following up on that. There must be some local flakiness around my printer (and/or some local print service) which was causing my occasional failures to print reversed page ranges from Chrome/Edge.

(In reply to Václav Trpišovský from comment #13)

robust way that works with pages-per-sheet

This should not be an issue since this is usually done on the driver's side.

Yeah, that's how we used to handle it; but with our new built-in print dialog, we have to offer a live print-preview of how the pages-per-sheet rendering is going to look, which means we have to implement it ourselves (which is what I've done in other bugs).

So, summing up the state of things:
(1) This is a valid bug report -- users may reasonably expect that if they ask for pages "5,1", then the pages will come out in that order with page 5 first.
(2) As a reference: desktop print software does typically behave that way (using the user's provided page-ordering); I confirmed this in Libreoffice on Windows, and Václav mentioned some other programs including e.g. MS Office products.
(3) However, as another reference: Chrome & Edge match Firefox on this, i.e. they print the pages in ascending order, if you print with their built-in print-dialog. On Linux, Chrome-with-the-system-print-dialog also matches Firefox and prints in ascending order (and on Mac, the system print dialog doesn't offer complex ranges at all so it's not applicable there). The only place where Chrome/Edge disagree with our behavior is specifically on Windows, if you use the system print dialog, where Chrome/Edge reportedly do use the user-provided ordering. (This inconsistency-based-on-which-dialog-you-use actually feels kind of like a bug on their side; in a sense, it's nice that we're at least consistent on our behavior. :) )
(4) Also worth noting: our behavior here isn't a regression (we haven't broken something that previously worked). Up until recently, we only supported complex page ranges on one platform -- Linux -- and we've always printed pages in ascending order there, as we do now on all platforms.

Given (3) and (4), this probably isn't super high-priority right now, but it would be nice to fix, per (1) and (2).

Version 100 and we've still got this bug. Especially aggravating when it takes multiple attempts to print something the way I need, and an unnecessary click has been added to each attempt to bypass the annoying modular print dialog after you've gone through with DISABLING A SENSIBLE PREFERENCE.

(In reply to Václav Trpišovský from comment #17)

and an unnecessary click has been added to each attempt to bypass the annoying modular print dialog after you've gone through with DISABLING A SENSIBLE PREFERENCE.

Note that bug 1712104 provides a new preference with the same behavior (bypassing Firefox's dialog), while being much simpler under the hood. Unfortunately that's not in Firefox 100, but it's available in Firefox 101 (current beta).

I'm using Firefox 126.0 on Windows 10 and this bug is still present. I love Firefox, so I was motivated to provide additional details demonstrating how annoying this issue can be for users that encounter it.

I work with PDFs that combine hundreds of small related documents into a single file for convenience. I review the PDF contents, and I'm usually interested in printing 4 of the sub-documents as page ranges.

I ask Firefox to print pages: "83-85,32-36,423-426,48-52"
The printer prints out the pages: "32-36,48-52,83-85,423-426"

I use the "double sided printing" option to save paper. For odd numbered page ranges, the reverse side of the last page contains the first page of the next range. This has the unfortunate consequence of ensuring I cannot rearrange the printed pages before I staple the package together. I'm forced to recycle the entire printout and reprint using a different application (eg. Foxit PDF Reader) to print the pages I want in the order I want them. So much for saving paper!

(2) As a reference: desktop print software does typically behave that way (using the user's provided page-ordering); I confirmed this in Libreoffice on Windows, and Václav mentioned some other programs including e.g. MS Office products.
(3) However, as another reference: Chrome & Edge match Firefox on this, i.e. they print the pages in ascending order...

Applications like Chrome, Edge, and Firefox are disregarding the user's explicitly provided page ordering, and instead printing according to the document's numerical ordering. This assumes the document numbering is more important or more correct than the user's request. For many documents, this distinction may not matter, or the user may not care because they don't use "double sided printing" and are able to rearrange the printed pages after printing. However, this behaviour is wrong in the general case, and forces some users to use other applications to achieve their desired printout.