1694879 - Users unexpectedly get "short-edge" as the default duplex print mode (i.e. upside down content), if they did any duplex printing with the system dialog in Firefox 81-85 (and have "2" saved as their "duplex" value in about:config as a result)

Status: RESOLVED WONTFIX

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

We have a problem with duplex printing in the Firefox 86 release, unfortunately.

(Duplex is weird -- if you're not familiar with it, then for the purpose of this summary, just know that "long-edge" is the common/usually-expected duplex mode, and "short-edge" is the less-common/less-expected mode; see this overview from Ricoh to learn more.)

BACKSTORY:
When we updated our duplex-printing implementation to use our own platform-independent enum values in bug 1659856, we unfortunately got things backwards when mapping between our own enum values and the Windows print APIs. (This is an understandable mistake, because Windows and GTK use exactly the same naming scheme to mean precisely opposite things, and the platform naming & documentation are kinda vague across the board.)

So, in other words: we hardcoded a mapping between Windows' long-edge duplex-enum and our own internal short-edge duplex-enum (and vice versa).

This meant the following two behaviors were both possible & were both experienced by our users, up to & including the Firefox 85 release:
(1) For Windows users who were opted in to our new tab-modal print dialog: our "Two-sided printing" checkbox (added in v84 in bug 1666734) would produce the wrong behavior; we'd print upside-down on the back of the page, when we didn't intend to do so.
(2) For all other Windows users (who didn't have the new print UI): duplex printing would Just Work without any issues, even though we were internally serializing their duplex preferences using our wrong enum value!! This is because we'd mis-map the value when serializing it into about:config (from the windows print dialog), and then we'd mis-map it again when deserializing it back out for the next print operation; so it would round-trip correctly, without the user noticing that anything was amiss.

Behavior (1) there was definitely a bug, and it was reported to us about a month ago, as bug 1689412. We fixed it by correcting the enum mappings on Windows, in Firefox 86 & newer; so now our internal enum values are correctly mapped to the Windows API enum values.

Unfortunately, bug 1689412's fix necessarily breaks the "round-trip", for users who had experienced Behavior (2) -- i.e. users who had an existing duplex print setting in about:config which we had mis-mapped to the wrong value (as we always did). Those users who had performed a duplex print operation in Firefox <= 85 would have the wrong duplex print mode (2 aka "short-edge") encoded as their chosen duplex mode in about:config -- and we previously were deserializing this out to the common/usually-expected Windows "long-edge" enum, but in v86 & newer, we'll dutifully map it to the Windows "short-edge" enum, which will be a surprise to these users & will cause them to have upside-down content on the back of their pages.

We also don't surface this particularly well; for now (in v86), we only have a checkbox labeled "Print on both sides", which could mean long-edge or short-edge. (When the user actively checks this box, we toggle long-edge duplex; but if we're restoring its checked state from saved preferences, we don't tell the user which duplex-mode we've restored.)

However, there is some good news:
(A) Fresh profiles are fine & won't be affected by this issue (as are profiles for anyone who's never printed in duplex-mode before).
(B) If affected users un-check and re-check the "print on both sides" checkbox in their print dialog, then this will update their serialized about:config duplex setting (for their chosen printer) with the correctly-mapped value, and they'll be ok from that point on.
(C) In Firefox 87, the "print on both sides" checkbox is being replaced with a dropdown menu that actually tells the user their chosen duplex-mode (long-edge / short-edge), so this will become a bit more transparent at that point, and they can clearly see what setting is chosen and change it as-needed (to the extent that they understand what long-edge/short-edge mean).

But in the meantime, we need to figure out what (if anything) we can do to improve things for the affected users...

Note: I'm marking this as a regression from bug 1689412 since that's the proximate cause (though really there's no simple way we could have fixed bug 1689412 without also causing this issue). And for the record, we have two bugs on file for users hitting this issue in the wild already: bug 1694484 and bug 1694769 (which I'll mark as duplicates of this bug).

Comment 3

[Daniel Holbert [:dholbert]]

So I see a few options for how to address this:
(1) Do nothing. Depending on how many users are affected and the riskiness of a real fix, it's worth considering (particularly given Good-News-A/B/C in comment 0).

(2) Just consider the existing printer.[printer_name].duplex pref busted & untrustworthy from here on out, and adjust our code to use some new pref-name instead, e.g. .duplex_mode let's say (adding _mode). This would mean that users would all get reset to "no duplex" as the default for now, and they would have to manually click the "Print on both sides" checkbox on their next print operation if they want it to be duplex.

Any other options?

As a strawman alternative that I think we can probably dismiss: we could hypothetically do an in-place fixup where we check for print.[printer_name].duplex=2 values and update them all to 1 (doing s/kDuplexFlipOnShortEdge/kDuplexFlipOnLongEdge/ in the saved settings, basically). But that would obviously cause trouble for users who have intentionally selected short-edge duplex in the system print dialog (we'd overwrite their choice); and the management of that sort of migration is complex; we'd need to track if we've already done it, so that we don't repeat ourselves and keep stomping on a user choice. We also would need to be sure to consider users who may be affected & who happen to let many months/versions go by before they open Firefox again, etc. So I'm not sure the complexity/overhead of that sort of a solution is merited here.

Comment 4

[Jonathan Kew [:jfkthame]]

Yeah, this is pretty unfortunate. I think what we probably should have done would have been to delete (or maybe update 2 -> 1) any existing duplex pref during migration to the new version, so everyone would just get the default behavior on first print job after the update. But we missed that chance.

I don't know how flexible our mechanisms to push a pref update are; can we tweak (or simply delete) existing print.*.duplex prefs to return people to the default behavior, and at the same time set a new pref print.duplex_reset.applied or something, which we'd use as a signal not to do this again in that profile? I.e. basically I'm wondering how feasible your "strawman" is; can we apply a "wildcard" (because it's per-printer) pref change that is conditioned on the setting of another pref? Essentially, do now via prefs what we should've done during migration to the new version.

Comment 5

[Jonathan Kew [:jfkthame]]

From a brief look at the preference-rollout action in Normandy, it's not apparent to me that we'd be able to use it to (re)set the per-printer duplex pref, as we don't know the specific name(s) of the pref(s) we'd need to target on a given system.

So we could write profile-migration code to handle this case, but it doesn't look like Normandy supports it afaics.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is a defect, but please change it back in case of error.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 8

[Pascal Chevrel:pascalc]

Daniel, could you set a priority/severity for this bug? Thanks

Comment 9

[Tim Spurway [:tspurway]]

:jwatt could you set a priority on this one?

Comment 10

[Daniel Holbert [:dholbert]]

I think this is effectively WONTFIX; the problem is that some users have slightly-broken data in their prefs (which was set by an earlier Firefox release, which had some values backwards and therefore saved some settings whose values we now interpret differently).

Fortunately this issue has been mitigated somewhat by the presence of a dropdown menu (added in Firefox 87) to show the duplex mode that we're about to use, & to let users choose between duplex modes, if the one that we're using isn't the one they want.

Any fix / additional mitigation that we might make here would likely overwrite the saved preferences of some other set of users. Given that, and given that affected users have a relatively-discoverable way to address this, I think no-action is the best action here at this point.