1667342 - window.close not working after window.print if both are called before or during the load event.

Status: VERIFIED FIXED

(Core :: Printing: Setup, defect)

Description

[ElDiablo]

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

Steps to reproduce:

Open a webpage ending with
window.print();
window.close();

Actual results:

The popup window won't close after printing

Expected results:

The popup window should close

Comment 1

[ElDiablo]

Attachment: Test case

Test case. This file is opened with window.open('test_case.html');

Comment 2

[ElDiablo]

The popup window is closing properly with Firefox 80.
This stopped working with Firefox 81, and is still not working on Nightly 83.0a1 (2020-09-24)

Comment 3

[ElDiablo]

This might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1662975
This bugfix landed on Firefox 81.

Comment 4

[Tom S [:evilpie]]

I can reproduce. With window.open("print.html") we open a new tab. After canceling the print prompt the tab stays open.
For me in Chrome the tab is immediately closed and no print preview is shown.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

I had just filed bug 1667350 for this. This only happens if print() and close() are both invoked before or during onload.

All browsers delay print() until after the load event has fired, see the discussion in https://phabricator.services.mozilla.com/D87898.

We block closing the window if such thing happens, and it seems Chrome doesn't. Unsure about Safari.

It seems before we also "auto-closed" the window after print if needed and now we don't... I'll look at why.

Comment 7

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

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

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

This was only being checked on OnDonePrinting() which isn't called in
the original docshell. Move it to the window because we don't need to
care about document viewers getting closed during print operations,
they're top level browsers that don't run script.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d73fe72c4b20
Make the "deferred window close" keep making sense after bug 1636728. r=smaug

Comment 11

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: Simple fix for printing regression that affects some sites in the wild, see bug 1667422.

Comment 12

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

It would be nice to understand how common this pattern is in the wild to aid in deciding whether this needs to drive a dot release or not.

Comment 13

[Cristian Brindusan [:cbrindusan]]

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

Comment 14

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Please nominate this for Beta approval when you get a chance so we can get as much bake time as possible ahead of any dot release decisions.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9177866 [details]
Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined: comment 0+
• 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: Open devtools, run window.open("https://bugzilla.mozilla.org/attachment.cgi?id=9177843"), ensure to allow popups. Close or print from the print dialog that should show up. Ensure the popup and the page closes after that.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively simple fix for a printing regression. Not too risky IMO.
• String changes made/needed: none

Comment 16

[ElDiablo]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

It would be nice to understand how common this pattern is in the wild to aid in deciding whether this needs to drive a dot release or not.

In our business, we use this in conjunction with auto_print feature.
When user ends processing a parcel, we open a popup with window.print & window.close, to generate a label.
I can't really say if our use is that common, but I think we should not be the only ones to need this feature.

Comment 17

[Julien Cristau [:jcristau]]

Comment on attachment 9177866 [details]
Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

approved for 82.0b5

Comment 18

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/57d04f9d97a4

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9177866 [details]
Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined: Some dialogs don't close after printing.
• 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: see above.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively simple fix + test.
• String changes made/needed: none

Comment 20

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Comment on attachment 9177866 [details]
Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

Approved for 81.0.1.

Comment 21

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-release/rev/aa09fcefb2ed

Comment 22

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Confirming this issue as verified fixed on 81.0.1(20200930150533), 82.0b5(20200929175845) and 83.0a1(20200930214529) with Windows 10x64 ,macOS 10.15.7 and Ubuntu 18.04.