1697836 - Firefox 86: Printing via script can lock up browser tab (invisible print dialog?)

Status: VERIFIED FIXED

(Core :: Printing: Setup, defect, P2)

Description

[Dean]

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

Steps to reproduce:

I have a fairly complicated private web app with multiply-nested iframes.

Main Window --> navbar --> hidden iframe(s) for printing
--> content window
--> lightbox overlay

I have encountered a problem in the following scenario:

• A print version of a page is opened in the lightbox
• window.onload script on that page immediately closes (hides) the lightbox iframe, and loads the same URL into the hidden print iframe.
• window.onload script in the hidden iframe calls window.print()

Actual results:

The new-version print dialog does not display, and the entire browser tab locks up. You can scroll, but you can't click links or otherwise interact with the page. YOU ALSO CAN'T NAVIGATE AWAY USING THE ADDRESS BAR'S URL WINDOW, SEARCH BOX, OR RELOAD BUTTON. (These aren't frozen, but neither do they trigger page navigation or reload). Other tabs are unaffected.

It's as if the print dialog has popped up, but somehow is invisible... as if it got hidden along with the lightbox iframe.

The problem doesn't occur if I do ANY of the following:

• I change print.tab_modal.enabled to false in about:config
• I don't close (hide) the lightbox iframe.
• I use setTimeout to delay loading the hidden print iframe by a significant amount (enough time for the lightbox to close first, perhaps?)
• I use developer tools to set a breakpoint prior to window.print() in the part of the script that executes in the hidden print iframe, then resume execution once the debugger pauses there.

Expected results:

It seems like this is a bug in Firefox 86, whereby the new-version print dialog appears in an invisible state in certain circumstances, permanently blocking further user interaction with the browser tab. It should, of course, be visible!

(Apologies but since the app is private I can't provide a link to the actual page where this occurs. If the above information isn't enough to track down the bug, I may be able to provide a reduced test case: please ask if needed).

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'DevTools::General' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Dean]

(In reply to Dean from comment #0)

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

Steps to reproduce:

I have a fairly complicated private web app with multiply-nested iframes.

Main Window --> navbar --> hidden iframe(s) for printing
--> content window
--> lightbox overlay

I have encountered a problem in the following scenario:

• A print version of a page is opened in the lightbox
• window.onload script on that page immediately closes (hides) the lightbox iframe, and loads the same URL into the hidden print iframe.
• window.onload script in the hidden iframe calls window.print()

Actual results:

The new-version print dialog does not display, and the entire browser tab locks up. You can scroll, but you can't click links or otherwise interact with the page. YOU ALSO CAN'T NAVIGATE AWAY USING THE ADDRESS BAR'S URL WINDOW, SEARCH BOX, OR RELOAD BUTTON. (These aren't frozen, but neither do they trigger page navigation or reload). Other tabs are unaffected.

It's as if the print dialog has popped up, but somehow is invisible... as if it got hidden along with the lightbox iframe.

The problem doesn't occur if I do ANY of the following:

• I change print.tab_modal.enabled to false in about:config
• I don't close (hide) the lightbox iframe.
• I use setTimeout to delay loading the hidden print iframe by a significant amount (enough time for the lightbox to close first, perhaps?)
• I use developer tools to set a breakpoint prior to window.print() in the part of the script that executes in the hidden print iframe, then resume execution once the debugger pauses there.

Expected results:

It seems like this is a bug in Firefox 86, whereby the new-version print dialog appears in an invisible state in certain circumstances, permanently blocking further user interaction with the browser tab. It should, of course, be visible!

(Apologies but since the app is private I can't provide a link to the actual page where this occurs. If the above information isn't enough to track down the bug, I may be able to provide a reduced test case: please ask if needed).

Comment 3

[Dean]

Oops, sorry for the text in the above comment... I just meant to revert the bugbot's decision to put this in the DevTools category.

Comment 4

[Andrei Purice]

Hey Dean,
Can you provide the mentioned test case and steps on how to reproduce it following that test case so we can take a look over it ? Thanks.

Comment 5

[Dean]

Attachment: PRINTBUG.zip

OK, test case is attached.

Unzip the four files to a web server, loacting them in the same folder.
Then navigate to PRINTBUG_MAIN.html

Note that the page is interactive (hover over the colored block to see it change color).
Click the link to open a data page. Then click the link to print.
Note that (a) No print dialog comes up, and (b) The page is no longer interactive... you can't even reload or navigate via the URL bar.

(If you middle-click the "print" link, printing works, however).

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Thank you! will look.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Thank you for the excellent test-case!

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1697836 - Improve error handling when failing to window.print(). r=mstriemer,emalysz

Ensure we report the error to the web console, and that the print
browser gets removed, as that is what will exit the modal state in the
page that's printing.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1697836 - Avoid throwing when asking for a selection. r=mstriemer,emalysz

Selection may be null if the page got hidden in e.g., the afterprint
event listener or somewhere else.

Add a try catch for good measure, assuming there's no selection is
always safe.

I'll try to get an automated test-case for this working, though it might
be tricky.

Depends on D109714

Comment 10

[Dean]

Hi Emilio.

I'm not 100% sure what your last two comments mean exactly, but I'd like to point out that in my test case, the iframe that is removed/hidden IS NOT the iframe that calls window.print()! The bug isn't that the print preview dialog stays up after the iframe that called it goes away... it's that it is apparently being hidden when an entirely different iframe (though with coincidentally the same URL) gets removed/hidden.

The correct behavior is that the print dialog should be visible, NOT that it should be removed.

Roughly, the intent of my script was "Don't try printing from the lightbox iframe, because that can be closed by the user at any time: So if a print window detects that it's inside the lighbox, don't print; instead immediately open the same URL in a different (invisible) iframe, and close the lightbox".

It looks like the print preview dialog is somehow confused as to which iframe it is connected to: The lightbox, or the invisible one. They both have the same URL.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

(In reply to Dean from comment #10)

I'm not 100% sure what your last two comments mean exactly, but I'd like to point out that in my test case, the iframe that is removed/hidden IS NOT the iframe that calls window.print()! The bug isn't that the print preview dialog stays up after the iframe that called it goes away... it's that it is apparently being hidden when an entirely different iframe (though with coincidentally the same URL) gets removed/hidden.

The last two comments are the two fixes for this bug. The first one is what caused the lack of interactivity when something in our front-end threw, the second one is the actual fix.

The correct behavior is that the print dialog should be visible, NOT that it should be removed.

Yes, after these two patches, the test-case shows the modal window and you can print of course :-)

Once this bug is closed as FIXED, you should be able to download a build from https://nightly.mozilla.org and confirm that the bug is fixed in your app as well.

Roughly, the intent of my script was "Don't try printing from the lightbox iframe, because that can be closed by the user at any time: So if a print window detects that it's inside the lighbox, don't print; instead immediately open the same URL in a different (invisible) iframe, and close the lightbox".

It looks like the print preview dialog is somehow confused as to which iframe it is connected to: The lightbox, or the invisible one. They both have the same URL.

What happened was that the lightbox hides on afterprint (as expected), but we had code trying to see if the user had selected something in the page, to allow to "print selection". afterprint for window.print doesn't fire after the modal has closed, but after the print clone gets created (see bug 1685011), so that code was trying to read the selection of the iframe that was getting printed, which was no longer displayed, and things went boom, basically.

Comment 12

[Dean]

The lightbox hides on afterprint?
Why? The lightbox SHOULD NEVER CALL window.print(). It should just close itself.

The actual page that should print is doing so from an invisible iframe, and it is this iframe that gets removed on afterprint.
Printing does not occur from the lightbox, so the lighbox iframe OUGHT NOT affect printing in any way.

NONETHELESS, if you modify the code so that the lightbox isn't closed, the bug doesn't occur!

What you've described above is definitely a bug that could/should affect my test case, but there's at least something else incorrect happening here, because nothing about the lightbox iframe being hidden or not-hidden should affect anything related to printing.

So the question is, prior to your fix, why did things NOT "go boom, basically" if you left the lightbox window open?
(It's a trivial code modification to test this - just delete or comment out "navbar.hideLightbox();" from the PRINTBUG_DATAPAGE.html file).
In this situation, the invisible iframe is still removed on afterprint, but for some reason the bug wasn't triggered.

(So I'm speculating, but could it have been looking for the selection based on the iframe's URL, and accidentally picking the wrong one?)

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/405b9d73ad3a
Improve error handling when failing to window.print(). r=emalysz
https://hg.mozilla.org/integration/autoland/rev/fa953bcf76f8
Avoid throwing when asking for a selection. r=emalysz

Comment 14

[Emilio Cobos Álvarez (:emilio)]

(In reply to Dean from comment #12)

So the question is, prior to your fix, why did things NOT "go boom, basically" if you left the lightbox window open?
(It's a trivial code modification to test this - just delete or comment out "navbar.hideLightbox();" from the PRINTBUG_DATAPAGE.html file).
In this situation, the invisible iframe is still removed on afterprint, but for some reason the bug wasn't triggered.

Because we're looking for the active selection in the browsing context tree, and the active selection is in the frame where you click the button (in the lightbox). My attempts to create a reduced test-case did not include the "printing actually a different iframe, and clicking the button in another iframe that gets hidden". I'll try on Monday to create a better test-case based on this.

(So I'm speculating, but could it have been looking for the selection based on the iframe's URL, and accidentally picking the wrong one?)

Yeah, indeed it's looking at the active browsing context (which in this case is the frame in the lightbox). That's a bit sketchy for window.print() indeed. For Ctrl+P it makes perfect sense though. So maybe a more reliable fix is not even try to get the selection anyways in the window.print() case, as what we're printing may not be the active page. Anyhow the fix I landed is very low risk and should also fix the bug, if you could try a nightly build tomorrow or the day after it'd be great.

ni?ing me to remember to give another shot at creating a test-case.

Comment 15

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/405b9d73ad3a
https://hg.mozilla.org/mozilla-central/rev/fa953bcf76f8

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

(In reply to Dean from comment #12)

(So I'm speculating, but could it have been looking for the selection based on the iframe's URL, and accidentally picking the wrong one?)

Yeah, turns out we want to always get the selection from the focused window, which makes perfect sense when you use e.g. Ctrl+P or such (so that you print the selection of the iframe that you're selecting for example). For window.print(), probably we don't want it to escape the window tree that was actually printed... Anyhow that's probably worth investigating as a follow-up.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1697836 - Add an automated test for this bug. r=emalysz,mstriemer

Comment 19

[Dean]

Emilio, I can confirm that the problem is now fixed for my app when I try it in Firefox nightly. Thanks!

However if window.print() called from script within an inactive iframe is looking for a selection within the active iframe, which isn't the one that called window.print() then obviously, the selection would not generally be correct or applicable in that case, even if it found an active window that had a selection in it.

If I understand correctly, you've prevented an exception from throwing when a selection window can't be found at all (which was what was causing the problem for me), but haven't yet fixed the underlying cause, which is that when you call window.print() from script in a particular window, it should be looking for a selection only in the tree rooted at that window in the first place.

So that's definitely also still a bug. Since this current bug is marked RESOLVED, will you be posting a new bug ID for that, or would you prefer that I did that...?

Comment 20

[Emilio Cobos Álvarez (:emilio)]

Thanks for confirming it's fixed for you now! Indeed, there is still an underlying logic issue in the print selection code, I've filed bug 1701504 with suggestions on how to fix it.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9211478 [details]
Bug 1697836 - Improve error handling when failing to window.print(). r=mstriemer,emalysz

Beta/Release Uplift Approval Request

• User impact if declined: Comment 0 in some edge cases related to window.print() and iframes.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 5
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a very low-risk fix (avoid throwing in an edge case, leaving the printing code in an unstable state). This uncovered an underlying logic issue that is a bit more subtle and is tracked by bug 1701504, but that's an even harder-to-hit edge case which doesn't affect correctness of the actual print operation (it may make us mistakenly show the "Print selection only" checkbox).
• String changes made/needed: none

Comment 22

[Bogdan Maris, Desktop Test Engineering]

Reproduced the initial issue using the testcase from comment 5 using an old Nightly from 2021-03-11, verified that this is fixed using latest Nightly from today 2021-03-29 across platforms (Windows 10, Ubuntu 18.04 and macOS 11.3).

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0b1b04e026a
Add an automated test for this bug. r=emalysz

Comment 24

[Bogdan Tara[:bogdan_tara | bogdant]]

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

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9211478 [details]
Bug 1697836 - Improve error handling when failing to window.print(). r=mstriemer,emalysz

Approved for 88.0b5.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/24d1ae92e229
https://hg.mozilla.org/releases/mozilla-beta/rev/8180dead8f98
https://hg.mozilla.org/releases/mozilla-beta/rev/a160e74f5105

Comment 27

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #22)

Reproduced the initial issue using the testcase from comment 5 using an old Nightly from 2021-03-11, verified that this is fixed using latest Nightly from today 2021-03-29 across platforms (Windows 10, Ubuntu 18.04 and macOS 11.3).

Also verified this is fixed using Firefox 88.0b5.