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

Steps to reproduce:

I just tried to print (standard default: A4 portrait duplex) my online bank statement displayed as a web page, with Firefox browser (v85.0 - Windows 10) to my KYOCEERA ECOSYS P2040dw duplex printer.

Actual results:

First I noticed that Firefox had updated to v85.0 and changed the Print interface to a new "Chrome-like" dialog (except no detailed duplex "flip" setting....).

Then I noticed that, on the printed sheet, page 1 was OK, while page 2 on the reverse side was UPSIDE DOWN (including Firefox header and footer)

I tried changing the printer default settings in Windows (e.g. "flip on short side"), to no avail.

I tried printing the same web page from Chrome, IE, and Edge, which both printed the duplex page OK, as usual.

To be honest with you, I tried printing the Firefox web page on my OTHER printer (Canon Pixma MG7751) and it printed OK in duplex mode. Yet I cannot use this printer for everyday office use, as it is an inkjet photo printer (slow and expensive)

Expected results:

Up to a couple of days ago, before your NEW print interface got auto-installed, the printed pages would print normally (A4 portrait MUST flip on LONG side), as they do using my other computer which is still with Firefox v84 ......

What this all means is that somehow either Kyocera or Mozilla isn't 100% compliant with some standard or protocol used for printing, yet this is not my problem. I've used Kyocera printers with Firefox for over 20 years and NEVER had a compatibility issue, and since you DID auto-install this new feature, I believe it is your duty to make things right !

Thank you for your interest.

After installing Firefox v84.0, then re-installing v85.0, everything was normal again: duplex printed web pages were OK (on both sides).

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

(In reply to JLT from comment #1)

After installing Firefox v84.0, then re-installing v85.0, everything was normal again: duplex printed web pages were OK (on both sides).

That's good to hear.

To clarify: after your reinstall, do you still see the new print UI, or are you back to seeing the old print UI? (I'm curious whether this is now working-in-the-new-UI for you, vs. if you ended up seeing the old print UI which was always working.)

(I seem to recall that we haven't rolled out the new print UI to all Firefox 85 users yet, but I'm not entirely sure.)

Hello

Indeed the v85 which self installed (as soon as I had installed v84) had the NEW print interface, but this time it worked correctly. All's well thzat ends well (for me at least). I still haven't understood your deployment philosophy for this new feature..... Good luck to you, I still love Firefox on my PC's, the Android version is good too.

Hello,
i'd like to report similar issue;
on Firefox 85.0.2 (64Bit) whenever i would like to print, there opens up up a new printing dialogue, where i can choose under "More settings" the "Two-sided printing".
Whenever i choose there the "Print on Both Sides",
it would in fact do duplex printing , but the second page would be reverted, which is exactly what i'd like to avoid.

only option to circumvent this annoiance seems to print via "print using the system dialogue" where i have properly setup the printer for duplex-printing by duxplexing via "long-edge binding".

It would be good to offer this option also on the firefox printing menu to avoid this two step solution;

please let me know if i did something wrong here; the printer is an Epson ET-4750.

operating system is Windows 7 64bit.

I can reproduce this, using Firefox Nightly 87.0a1 (2021-02-08) on Windows 10. --> confirming & clarifying summary a bit.

I printed pages 1-2 of https://www.mozilla.org/en-US/MPL/2.0/ with the "two-sided printing" checkbox checked, using the new tab-modal print dialog; and page 2 (on the back of page 1) was upside-down. (In my case this was on US Letter paper with an Epson XP-960 network printer.)

I spent a chunk of today looking at this in a debugger, and I'm pretty confident we just got the windows-API enum values backwards here.

In a debug build of current mozilla-central, I do see us hitting nsPrintSettingsWin::CopyToNative, and we correctly read the user-provided Gecko duplex value (which for now is always kDuplexFlipOnSideEdge), and we set aDevMode->dmDuplex = DMDUP_HORIZONTAL, which I think we intend to mean "flip the page horizontally".

But, in fact, that's not what that DMDUP enum value means; I think we got it backwards! The documentation for DEVMODEW's dmDuplex member-var says the following about this enum value:

DMDUP_HORIZONTAL
Print double-sided, using short edge binding.
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-devmodew#dmdup_horizontal

I assume the "binding" edge is the edge that would get bound in a book (and hence also the edge that you'd turn up to flip the page over) . So in fact, kDuplexFlipOnSideEdge wants to trigger long-edge binding, which is DMDUP_VERTICAL, not DMDUP_HORIZONTAL.

I found references in Chromium's source code [1] and in a delphi forum-post [2] that confirm this mapping, too.

So: this seems to have just been a misunderstanding and an easy fix.

[1] here and here, "LongEdge" is matched with DMDUP_VERTICAL
[2] http://www.delphigroups.info/2/f7/493467.html
"To flip on the long edge, this value would have to be set to DMDUP_VERTICAL"

We seem to have misinterpreted the Windows API constants and got them
backwards, which in practice meant that a user choosing long-edge flipping (or
having it chosen-by-default for them) would get short-edge flipping, and vice
versa.

The Microsoft docs say that their DMDUP_VERTICAL enum means "long-edge
binding", which is the behavior that we're intending to trigger with our own
kDuplexFlipOnSideEdge enum. And similarly, their DMDUP_HORIZONTAL enum
corresponds to "short-edge binding", which is what our kDuplexFlipOnTopEdge
enum represents. This patch updates our code to use these enum-pairings.

Documentation references:
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-devmodew#dmdup_vertical
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-devmodew#dmdup_horizontal

Comment on attachment 9202485 [details]
Bug 1689412: Fix the mapping between our own printing duplex enum-values and the windows API's corresponding enum-values. r?emilio,jfkthame,nordzilla

Beta/Release Uplift Approval Request

• User impact if declined: Users will get unexpected results from their duplex print jobs (content on the "back side" of a printed page will be upside-down, which isn't the default behavior that we're intending to use).

(specifically: this probably affects all users on Windows who receive our new print UI [as a portion of our release users already have], and who have duplex-capable printers & who choose to use that option.)

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: (1) Configure a Windows environment with a printer that's capable of duplex printing (i.e. can print both back & front of a printed page)
  (2) Ensure you have print.tab_modal.enabled set to true
  (3) Print attached testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=9202179 ) -- and under "More Settings", click the checkbox under "Two-sided printing". (If you don't see that option, then it means your printer doesn't support duplex printing, or we can't tell that it does.)
  (4) Look at the resulting printed page.

EXPECTED RESULTS: The "top edge" for page 1 should be the same as the "top edge" for page 2 on the back.

ACTUAL RESULTS (with this bug): The "top edge" for page 1 is the bottom edge for page 2 on the back. (i.e. we unexpectedly print using "tumble" style duplex printing)

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This is somewhat risky because this codepath is unfortunately untested -- it requires particular hardware (duplex printer) to actually exercise the codepath and see the resulting output.

However: the patch is pretty minimal (just a pretty targeted search-and-replace); and as discussed in comment 9, I'm pretty confident this was simply a typo (swapping the meaning of some enums in a windows API), and I'm pretty confident that our amended interpretation is correct.

I've also tested this in a local build and verified that it fixes the bug there (though it hasn't hit Nightly yet, hence "verified in nightly: no" indicated above).

• String changes made/needed: None

[Tracking Requested - why for this release]: unexpectedly upside-down page content (see comment 12)

Based on code-inspection, it looks like from a user's perspective, this is a regression from bug 1666734, which is the bug that added the checkbox to our UI, and made it select the enum that corresponds to DMDUP_HORIZONTAL (which at the time we called kDuplexHorizontal and now we call kDuplexFlipOnSideEdge). Before that bug, users wouldn't have been able to trigger this.

That means all versions since Firefox 84 are affected (though not all users of 84/85 have been given the new print UI by default, so many users will still get the native print dialog which I believe would bypass this bug).

Note: we'll actually need a rebased patch for beta (to account for some renamings that happened in bug 1673099, which the trunk patch is based on top of but which did not land & probably doesn't need to land on beta86).

I'll post a rebased beta-friendly patch later on this evening.

Also note: this is especially confusing since it seems like GTK has its naming reversed with respect to windows.

GTK's documentation for its "horizontal" duplex mode (GTK_PRINT_DUPLEX_HORIZONTAL) isn't particularly helpful, but it seems to correspond to long-edge binding, which is the opposite of what the os-provided "horizontal" keyword means on Windows. I'm basing this on my own observations that this currently works on GTK -- no patch needed there -- and I'm also basing on this eclipse code-snippet which maps their LONG_EDGE enum to GTK_PRINT_DUPLEX_HORIZONTAL, and SHORT_EDGE to GTK_PRINT_DUPLEX_VERTICAL:
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20Printing/gtk/org/eclipse/swt/printing/PrintDialog.java?id=40cb272af51e68257747a70536bec80228362b68#n361
(And this mapping is the opposite of the Windows semantics - see comment 10.)

This means it's all-the-better that we've renamed our own constants in bug bug 1673099 to use clearer names...

https://hg.mozilla.org/mozilla-central/rev/b1b7724dbe72

Comment on attachment 9202485 [details]
Bug 1689412: Fix the mapping between our own printing duplex enum-values and the windows API's corresponding enum-values. r?emilio,jfkthame,nordzilla

That looks a bit risky for our last beta as this is an area of our code prone to regressions and the fix just landed in Nightly. Given that we have already shipped 2 releases with this bug, I think that we should let it ride the 87 train, thanks.

(In reply to Pascal Chevrel:pascalc from comment #18)

Given that we have already shipped 2 releases with this bug, I think that we should let it ride the 87 train, thanks.

Normally I'd be of the same opinion -- but in this case, in the two releases that we already shipped with this bug, most users weren't affected since they didn't have the new print UI turned on by default (e.g. it's only enabled for 25% of users in Firefox 85) -- whereas we're planning on enabling it for all release users in Firefox 86.

Does that impact your approval calculus at all?

Also FWIW, I verified that the bug is indeed fixed in today's Nightly.

Comment on attachment 9202485 [details]
Bug 1689412: Fix the mapping between our own printing duplex enum-values and the windows API's corresponding enum-values. r?emilio,jfkthame,nordzilla

I discussed it with the team and we are going to take this patch in our last beta :)

Great, thank you!

https://hg.mozilla.org/releases/mozilla-beta/rev/05381d3748a5

I verified the beta-fix myself, in beta builds from treeherder.

• I reproduced the bug (second page upside-down, i.e. short-edge duplex) in the last treeherder build without the fix (using the Windows 2012 opt "target.zip" artifact - the STR from comment 12 produce the "user impact" described there):
  https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=ba83f004fa5760c0759aae4887544cda1bd8fa75

• I got expected results (second page not upside-down, i.e. we print with long-edge duplex now) in the first treeherder build with the fix:
  https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=05381d3748a5462c8ed23019d1570c7ca25ffe54

(This should still get QA verification from someone on the QA team with a duplex printer, to exercise this beyond just my setup & my printer/print-driver.)

Reproduced the issue on Firefox 87.0a1 (2021-02-10) under Windows 10 with the attached testcase from Comment 12.

The issue is no longer reproducible on Firefox 87.0a1 (2021-02-14) and on Firefox 86.0b9 (https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=05381d3748a5462c8ed23019d1570c7ca25ffe54 from Comment 23).

Seems that macOS 11.2.1 prints the pages correctly but on Ubuntu 20.04 there are two options for Two-sided printing (Flip on side edge/top edge) and both of them prints the page as the affected builds on Windows.

(just posting one more version of the testcase, with more pages, to help with testing pages-per-sheet scenarios in investigations on subsequent bugs)

(In reply to Catalin Sasca, QA [:csasca] from comment #24)

on Ubuntu 20.04 there are two options for Two-sided printing (Flip on side edge/top edge)

Those two options were just added (for all platforms) in bug 1671702, BTW. (Previously we just had a checkbox & only used the setting that corresponds to the "flip on side edge" menu-option. Also: note that we're changing these labels soon, in bug 1692316.)

and both of them prints the page as the affected builds on Windows.

Odd -- that's not what I see. Would you mind trying again to be extra-sure? (printing a 2-page doc, e.g. testcase 1 here, in Portrait mode, using the first duplex option which is "flip on side edge")

I just retested and confirmed that this produces "expected results" for me -- if I flip the page over from the right edge (like turning the page of a book), I see a correctly-oriented page 2. (And if I choose the other option, "flip on top edge", then I get the other behavior where I have to flip the page vertically in order to see a correctly-oriented page 2.) I'm using Nightly 87.0a1 (2021-02-16) on Ubuntu 20.10.

Retested the side edge (printed on the top of the page only) and flip edge (printed one on top and the other one on the bottom) on Nightly 87.0a1 (2021-02-16). Seems that the printer options works correctly.

Note that users who actively reproduced this bug may continue to be affected by this bug, until they uncheck & re-check the Two-Sided Printing checkbox in their print dialog.

If they reproduced the bug, then they would've had 2 i.e. "short-edge-duplex-mode" saved in about:config for their print.[printer-name].print_duplex setting, which then we'd respect as the default going forward (even though now we consider the checkbox as corresponding to 1 i.e. long-edge duplex). We would probably keep using 2 i.e. short-edge duplex as the default for that user/printer, for subsequent print operations, until the user actively changes the print settings (by e.g. unchecking the box and updating the saved value).

That's my theory for what's going on in related bug 1694484, which is a version of this bug that's still cropping up in 86, which seems to go away if users mess with the settings in the print dialog a bit.

(The good news is that in Firefox 87, the checkbox will be turning into an actual dropdown menu that shows you the actual duplex mode that we're going to use [none vs. long-edge vs. short-edge] and lets you pick between them.)

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

Note that users who actively reproduced this bug may continue to be affected by this bug, until they uncheck & re-check the Two-Sided Printing checkbox in their print dialog.

Actually, it's more subtle than that -- but I think users who were not opted in to the new print dialog in Firefox <85 are the users who would now (in version 86) be affected by something very much like this original bug, unfortunately.

See bug 1694879 for details.