Closed Bug 1669187 Opened 1 year ago Closed 1 year ago

Print preview settings are ignored on first print to a printer when `print.tab_modal.enabled` is set to `false`

Categories

(Toolkit :: Printing, defect, P1)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
83 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 + verified
firefox83 --- fixed

People

(Reporter: cmuresan, Assigned: jwatt)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [print2020_v82] [old-ui+])

Attachments

(2 files)

[Affected versions]:

  • Firefox Nightly 83.0a1, Build ID 20201004212809
  • Firefox Beta 82.0b7, BuildID 20201002191150

[Affected Platforms]:

  • Windows 10
  • Ubuntu 20.04

[Prerequisites]:

  • Have the print.tab_modal.enabled set to false.

[Steps to reproduce]:

  1. Open a new Firefox Beta profile and navigate to a printable page.
  2. Click the Firefox Menu button and select the Print... option.
  3. Click the Landscape option and observe the behavior.

[Expected results]:

  • The page is refreshed and the orientation is changed to landscape.

[Actual results]:

  • The page is refreshed and the orientation remains in portrait.

[Notes]:

  • The issue is no longer reproducible after printing a page.
  • Attached a screen recording of the issue.

Regression for the old ui. Tracking this for 82.

Whiteboard: [print2020_v82] [old-ui+]

I can reproduce, I'll take a look.

Assignee: nobody → bobowencode
Status: NEW → ASSIGNED

Looks like this is another symptom of print_printer not being set until first print.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1668621

I've searched for a regression window and have reached to following pushlog. I've confirmed this regression window on two different machines (Linux MX 4.19 and Windows 10).

Based on it, it looks like bug 1667953 has caused the issue and not bug 1668516 like I initially thought. I think we should reopen this issue and treat it separately from bug 1668621 based on this information and the fact that this behavior is not reproducible on Firefox Release 81 while bug 1668621 is.

@jwatt, could you please take a look at this issue? Is there anything in bug 1667953 that could have caused this?

Status: RESOLVED → REOPENED
Flags: needinfo?(jwatt)
Regressed by: 1667953
No longer regressed by: 1668516
Resolution: DUPLICATE → ---

(In reply to Ciprian Muresan [:cmuresan], Ecosystem QA from comment #4)

@jwatt, could you please take a look at this issue? Is there anything in bug 1667953 that could have caused this?

Thanks for doing the bisect.

Yes, given what we know now, it makes perfect sense that bug 1667953 would cause this. The issue is that when print_printer hasn't been set (the user hasn't printed before) we implicitly save the print settings unprefixed when saving them in order to pass settings to the content process. Since https://phabricator.services.mozilla.com/D91819 made us ignore most unprefixed prefs in nsPrintSettingsService::InitPrintSettingsFromPrefs, we now fail to pick up those "passed settings" in the content process.

Flags: needinfo?(jwatt)
Summary: Can't set page orientation to landscape without printing in portrait first when `print.tab_modal.enabled` is set to `false` → Print preview settings are ignored on first print to a printer when `print.tab_modal.enabled` is set to `false`
Blocks: 1669922
Attachment #9180348 - Attachment description: Bug 1669187. WIP Try to make sure we always have a last used printer saved. r=bobowen → Bug 1669187. Make sure we have a last used printer saved in the common case. r=bobowen
Duplicate of this bug: 1668621
Duplicate of this bug: 1668762
Duplicate of this bug: 1669922

The landed version of this patch uses the system default printer, if one is set. It does not further fall back to trying to get an available printer list using the nsIPrinterList as the original version of the patch did. That's because it seemed way too risky to uplift that to Beta, given that it requires making a bunch of code async, and the APIs to get the printer list and default settings from a printer have very variable delays according to our telemetry, for ~1% of users taking over (potentially way over) 10 seconds.

This patch fixed the issue for me on Window 10 and macOS 10.15.7. It did not fix things on Ubuntu 20.04. Again, the differences are whether a system default printer is set or not. It's possible the patch will not fix the issue for Windows 7 users (I don't know, yet), and it's possible that it will not fix the issue for macOS users who have never printed before using any app on their computer. However, the issue is only present for users using the old UI, who have never printed using Firefox before, and who are using Print Preview or the Page Settings dialog. (Our telemetry says that only around 7% of prints are made via print preview, and presumably a similarly small number of prints involve the Print Settings dialog.) That should be a relatively small subset of users affected (albeit mostly new users, the ones we're trying to retain), and the patch on this bug should significantly further reduce that subset of users given most of them are on Windows. As for the rest, I think we may have to live with the regression until we switch to the new print UI.

Pushed by jwatt@jwatt.org:
https://hg.mozilla.org/integration/autoland/rev/9270d4334587
Make sure we have a last used printer saved in the common case. r=bobowen,remote-protocol-reviewers

Comment on attachment 9180348 [details]
Bug 1669187. Make sure we have a last used printer saved in the common case. r=bobowen

Beta/Release Uplift Approval Request

  • User impact if declined: Users printing for the first time who are using Print Preview or using the Page Setup dialog will have settings changes they make ignored, which is a very poor first user experience.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Bob and I have talked over the risk and we think it should be fairly low since for the most part it just reuses some existing tried and tested code, just in a different way in the particular case that the user has never printed before.
  • String changes made/needed:
Attachment #9180348 - Flags: approval-mozilla-beta?

Comment on attachment 9180348 [details]
Bug 1669187. Make sure we have a last used printer saved in the common case. r=bobowen

fix issues with settings on first print; approved for 82.0b9

Attachment #9180348 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Priority: -- → P1
Assignee: bobowencode → jwatt
Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

I have verified that changing the orientation to landscape and back, changing the scaling options, modifying the margins, and checking the image backgrounds and pictures options work as expected before printing a page on the latest Beta 82.0b9 (BuildID 20201008183927) using Windows 10 and Windows 7.
The issues are still reproducible on LinuxMX 4.19 and Ubuntu 20.04, however based on comment 10, this seems to be expected in this case. Based on this and the verification, I'll mark this issue as Verified.

Status: RESOLVED → VERIFIED

(In reply to Ciprian Muresan [:cmuresan], Ecosystem QA from comment #16)

I have verified that changing the orientation to landscape and back, changing the scaling options, modifying the margins, and checking the image backgrounds and pictures options work as expected before printing a page on the latest Beta 82.0b9 (BuildID 20201008183927) using Windows 10 and Windows 7.
The issues are still reproducible on LinuxMX 4.19 and Ubuntu 20.04, however based on comment 10, this seems to be expected in this case. Based on this and the verification, I'll mark this issue as Verified.

Thanks, if you set a default printer on those linux machines, does that then work?

Flags: needinfo?(cmuresan)

If I'd need an actual printer I can't do that because I don't have one available, but I've reached out to Emil Ghitta and he might be able to check this.

Flags: needinfo?(cmuresan) → needinfo?(emil.ghitta)

Thanks, if you set a default printer on those linux machines, does that then work?

By strictly opening a new profile and executing the steps from bug’s description with a printer connected, the issue is still reproducible. Changes made from Print or Print Setup still doesn't make any difference unless they are followed by an actual printing action.
The issue is fixed without executing any printing operation first, only if the print_printer pref is manually populated with the name of the used printer.

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #19)

Thanks, if you set a default printer on those linux machines, does that then work?

By strictly opening a new profile and executing the steps from bug’s description with a printer connected, the issue is still reproducible. Changes made from Print or Print Setup still doesn't make any difference unless they are followed by an actual printing action.
The issue is fixed without executing any printing operation first, only if the print_printer pref is manually populated with the name of the used printer.

Did you try setting the printer as default in the operating system printer configuration tool?
I think on at least some (possibly most/all) linux systems a default printer isn't set automatically.

Flags: needinfo?(anca.soncutean)

(In reply to Bob Owen (:bobowen) from comment #20)

Did you try setting the printer as default in the operating system printer configuration tool?
I think on at least some (possibly most/all) linux systems a default printer isn't set automatically.

Yes, the printer wasn't set as default at the OS level, once I did that, indeed the issue is no longer reproducible (with latest Nightly/ latest Beta on Ubuntu 18.04)

Flags: needinfo?(anca.soncutean)
Flags: needinfo?(emil.ghitta)
You need to log in before you can comment on or make changes to this bug.