[Windows][parent process about pages][print-to-pdf] Print preview infinite loading state and wrong output
Categories
(Core :: Print Preview, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | disabled |
firefox82 | --- | verified |
People
(Reporter: emilghitta, Assigned: emilio)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression, Whiteboard: [print2020_v82][old-ui-])
Attachments
(4 files)
Affected versions
- 81.0a1 (BuildId:20200817093723)
Affected platforms
- Windows 10 64bit
Unaffected platforms
- macOS 10.14
- Ubuntu 18.04 64bit.
Preconditions
- Ensure that the
print.tab_modal.enabled
pref is set totrue
Steps to reproduce
- Launch Firefox.
- Access the about:support page.
- Open print preview.
- Switch between available destinations (ex: From printer x to Save to PDF)
Expected result
- The print preview gets successfully updated & the print to file or print to paper is successfully performed.
Actual result
- The print preview remains in an infinite loading state and clicking print returns in (see attachment for print to file) a blank page (for print to paper).
Regression Window
- This seems to be a regression:
- Potential Regressor: Bug 1658043
Additional Information
- The following errors are being outputted inside the browser console while triggering this:
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrintSettingsService.initPrintSettingsFromPrinter]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/actors/PrintingChild.jsm :: getPrintSettings :: line 126" data: no] PrintingChild.jsm:126:13
can't access property "showPrintProgress", printSettings is null PrintingChild.jsm:322
- For further information regarding this issue please observe the attached screencast.
Reporter | ||
Comment 1•4 years ago
|
||
Hi Olli!
It seems that mozregression pointed out Bug 1658454 - nsISHEntry.cacheKey setter for session-history-in-parent, r=peterv
for causing this regression.
Can you please take a look?
Thank you!
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
Comment 3•4 years ago
|
||
Set release status flags based on info from the regressing bug 1658454
Updated•4 years ago
|
Comment 4•4 years ago
|
||
This only happens for me for the Save to PDF printer. I can switch between my other printers on Windows, but once I select Save to PDF the preview stops working.
Comment 5•4 years ago
|
||
Super weird. I accidentally noticed this bug, but I never got any bugmail about this.
However, bug 1658454 most probably didn't regress this.
https://hg.mozilla.org/mozilla-central/rev/9d3ade989dabfcdf2a63e1c9b71edcf27ea48c50 which happened a bit before bug 1658454 smells way more likely.
Comment 6•4 years ago
|
||
And I can't reproduce this anyhow.
Emil, if you can reproduce this, could you check if https://hg.mozilla.org/mozilla-central/rev/9d3ade989dabfcdf2a63e1c9b71edcf27ea48c50 regressed this?
Reporter | ||
Comment 7•4 years ago
•
|
||
I can still reproduce this behavior. Indeed Bug 1658043 seems to be the better candidate for causing this regression (tried with the last release without & first release with from https://hg.mozilla.org/mozilla-central/rev/9d3ade989dabfcdf2a63e1c9b71edcf27ea48c50)
I'm going to update this Bug to better reflect this.
Thank you Olli ! And sorry for pointing out the wrong patch!
Reporter | ||
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Hi Mike, is there someone who could look at this any time soon? Thank you!
Comment 9•4 years ago
|
||
I can reproduce on my Windows machine, but not on macOS.
There are exceptions in the browser console - initPrintSettingsFromPrinter
is throwing NS_ERROR_FAILURE. :jwatt, is that expected for the PDF printer, or something?
Updated•4 years ago
|
Comment 10•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #9)
There are exceptions in the browser console -
initPrintSettingsFromPrinter
is throwing NS_ERROR_FAILURE. :jwatt, is that expected for the PDF printer, or something?
For our own "Save to PDF" pseudo "printer" it would be. But we have code to guard against that, don't we?
Comment 11•4 years ago
|
||
(In reply to Jonathan Watt [:jwatt] from comment #10)
(In reply to :Gijs (he/him) from comment #9)
There are exceptions in the browser console -
initPrintSettingsFromPrinter
is throwing NS_ERROR_FAILURE. :jwatt, is that expected for the PDF printer, or something?For our own "Save to PDF" pseudo "printer" it would be. But we have code to guard against that, don't we?
Not in PrintingChild.jsm we don't...
Comment 12•4 years ago
|
||
Also not in setPrinterDefaultsForSelectedPrinter, in pringPageSetup.js .
Comment 13•4 years ago
•
|
||
(In reply to :Gijs (he/him) from comment #11)
(In reply to Jonathan Watt [:jwatt] from comment #10)
(In reply to :Gijs (he/him) from comment #9)
There are exceptions in the browser console -
initPrintSettingsFromPrinter
is throwing NS_ERROR_FAILURE. :jwatt, is that expected for the PDF printer, or something?For our own "Save to PDF" pseudo "printer" it would be. But we have code to guard against that, don't we?
Not in PrintingChild.jsm we don't...
Guarding this access alone doesn't appear to be sufficient to fix this issue - we get the same behaviour but an error dialog now also shows up, because
docShell
.initOrReusePrintPreviewViewer()
.printPreview(printSettings, contentWindow, listener);
at https://searchfox.org/mozilla-central/rev/d54210d490ef335b13fc1fcac817525120c8c46b/toolkit/actors/PrintingChild.jsm#370-372 throws (in the printPreview
call).
Happy to keep debugging but not sure where to go from here.
Edit:
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserPrint.printPreview]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/actors/PrintingChild.jsm :: printPreviewInitialize :: line 376" data: no] PrintingChild.jsm:376:14
printPreviewInitialize resource://gre/actors/PrintingChild.jsm:376
is the precise error if that helps.
Comment 14•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #11)
Not in PrintingChild.jsm we don't...
For some reason I had in mind that being loaded in the content process == errors go to the Web Console (not Browser Console). :/
(In reply to :Gijs (he/him) from comment #12)
Also not in setPrinterDefaultsForSelectedPrinter, in pringPageSetup.js .
I'm pretty sure that file isn't used by the new UI.
Comment 15•4 years ago
•
|
||
This really needs someone to walk through what's happening under nsPrintJob::DoCommonPrint in a debugger. Can you post your new guard code to save that person writing the same thing?
Comment 16•4 years ago
|
||
As noted on Matrix:
- despite this code being in
PrintingChild.jsm
, we're running in the parent (because it's a parent-process about: page) - PrintingChild.jsm needs to have the same "is this the PDF printer" check, or a try...catch (as it appears to work on non-Windows?)
- further failure is because when previewing, the settings for the PDF printer do not have a filename set. If we print child process pages, we create a
nsDeviceContextSpecProxy
which doesn't care. But if we're in the parent process, we try to create annsDeviceContextSpecWin
instance, which in the PDF case creates annsIFile
instance and tries toinitWithPath
it with the specified path (ie""
). That fails, which means we fail to create the print target, which causes theprintPreview()
call to fail.
:jwatt suggested we may not want to create a print target at all in the print preview case? Unsure if that is the most expedient solution here.
Anyway, I think we should maybe downgrade this issue's severity as it only affects parent process pages, which are relatively rare, and it only affects printing to PDF. Unless we think it's going to be very common for people to be attempting to print about:support
and similar to PDF... :jstutte, thoughts?
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 18•4 years ago
|
||
Now it turned out it's scary since it causes a crash (bug 1663426).
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 19•4 years ago
|
||
Ideally print preview and co. shouldn't need a PrintTarget at all, I'd think...
Though that's a bigger refactoring.
Comment 20•4 years ago
|
||
(It sounds like this is a core bug…)
Updated•4 years ago
|
Comment 21•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b6be24539b1d Handle printing with an empty file name in nsDeviceContextSpecWin. r=jwatt
Comment 22•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Comment 23•4 years ago
|
||
Reproduced the initial issue using an old Nightly build (2020-08-17), verified that using Firefox 82.0b3 the print preview is opened but still suffers from a delay (bug 1665272). Using Nightly 83.0a1 which also contains the fix from bug 1665272 the print preview opens almost instantly so I will call this as verified fixed since once the patch from 1665272 will land in Beta 82 it will have similar performance as well.
Comment 24•4 years ago
|
||
Description
•