Closed Bug 1667342 Opened 1 month ago Closed 1 month ago

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

Categories

(Core :: Printing: Setup, defect)

Firefox 81
All
Windows 10
defect

Tracking

()

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

People

(Reporter: s.baguette, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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

Attached file Test case

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.

Status: UNCONFIRMED → RESOLVED
Closed: 1 month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1662975
Status: RESOLVED → UNCONFIRMED
OS: Unspecified → Windows 10
Hardware: Unspecified → All
Resolution: DUPLICATE → ---
Flags: needinfo?(emilio)

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.

Duplicate of this bug: 1667350

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.

Summary: window.close not working after window.print → window.close not working after window.print if both are called before or during the load event.

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

Component: Untriaged → Printing: Setup
Product: Firefox → Core

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.

Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(emilio)
Regressed by: 1636728
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
See Also: → 1667422
Duplicate of this bug: 1667422

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

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.

Status: ASSIGNED → RESOLVED
Closed: 1 month ago1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

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.

Flags: needinfo?(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
Flags: needinfo?(emilio)
Attachment #9177866 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

(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 on attachment 9177866 [details]
Bug 1667342 - Make the "deferred window close" keep making sense after bug 1636728. r=smaug

approved for 82.0b5

Attachment #9177866 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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
Attachment #9177866 - Flags: approval-mozilla-release?

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.

Attachment #9177866 - Flags: approval-mozilla-release? → approval-mozilla-release+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.