window.close not working after window.print if both are called before or during the load event.
Categories
(Core :: Printing: Setup, defect)
Tracking
()
People
(Reporter: s.baguette, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
160 bytes,
text/html
|
Details | |
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
|
Details | Review |
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
Test case. This file is opened with window.open('test_case.html');
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)
This might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1662975
This bugfix landed on Firefox 81.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
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.
Assignee | ||
Comment 6•4 years ago
|
||
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•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Assignee | ||
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d73fe72c4b20 Make the "deferred window close" keep making sense after bug 1636728. r=smaug
Assignee | ||
Comment 11•4 years ago
|
||
[Tracking Requested - why for this release]: Simple fix for printing regression that affects some sites in the wild, see bug 1667422.
Comment 12•4 years ago
|
||
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•4 years ago
|
||
bugherder |
Comment 14•4 years ago
•
|
||
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.
Assignee | ||
Comment 15•4 years ago
|
||
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
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 16•4 years ago
|
||
(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•4 years ago
|
||
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•4 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 19•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
bugherder uplift |
Comment 22•4 years ago
|
||
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.
Description
•