Since Firefox 72, target="_blank" and window.close() do no longer work together
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
People
(Reporter: maximilian.schlederer, Assigned: nika)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
Assume you create a new window (pop-up) using javascript and have its content be something like this:
<html>
<body>
<form action="some_action.php" target="_blank">
... some form fields ...
<button onclick="window.close()">
submit in new tab & close pop-up
</button>
</form>
<a href="some_page.php" target="_blank" onclick="window.close()">
open link in new tab & close pop-up
</a>
</body>
</html>
I have also attached a test case (html).
Actual results:
If you click the "submit in new tab & close pop-up" button or the "open link in new tab & close pop-up" link this happens:
- Firefox only opens an empty tab, i.e. the submission of the form (the opening of the link) fails
- The pop-up closes itself
Expected results:
If you click the button "submit in new tab & close pop-up" the following should happen:
- Firefox submits the form in a new tab (because target="_blank" is set in the <form>)
- The pop-up closes itself (because onclick="window.close()" is set)
And if you click the link "open link in new tab & close pop-up" the following should happen:
- Firefox opens the link in a new tab (because target="_blank" is set in the <a>)
- The pop-up closes itself (because onclick="window.close()" is set)
This clearly seems to be a bug, right? Is this a known problem? I tested it with older versions and the problem apparently was introduced relatively recently with Firefox 72. More precisely, the form submission bug was introduced with Firefox 72 Beta 1 and the link opening bug was introduced with Firefox 72 Beta 7.
In Chrome and Internet Explorer both cases work as expected.
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•5 years ago
|
||
When a tab closes, pending network tasks may be canceled. Try a delay on closing the tab:
<button onclick="window.setTimeout(function(){window.close();}, 250);">
Example:
|
Reporter | |
Comment 3•5 years ago
|
||
Yes setting a short timeout is the obvious workaround. However I want to emphasize that closing the window here should not cancel any "pending network tasks" since those belong (should belong) to the newly opened tab and not to the one which is closed.
|
||
Comment 4•5 years ago
|
||
This should be working now on Nightly (bug 1353466).
Reporter, could you try Nightly and reopen this if this doesn't work.
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 5•5 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #4)
This should be working now on Nightly (bug 1353466).
Reporter, could you try Nightly and reopen this if this doesn't work.
It doesn't work. Instead the problem got worse: Apart from the form failing to submit / the link failing to open, now not even a new tab is created.
|
|
||
Comment 6•5 years ago
|
||
The severity field is not set for this bug.
:smaug, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 7•5 years ago
|
||
I can reproduce this problem in Firefox 83 Nightly with the test case. In Chrome, it opens a new tab. In Firefox, it doesn't open a new tab.
Assign to Nika.
P3/S3
|
Assignee | |
Comment 8•5 years ago
|
||
This is being caused by a race between the close logic going through and the window.open logic. When the link is clicked, first the onclick listener is called, which will call window.close(), and then the new pop-up window is created due to clicking on a <a target=_blank> link.
- The close call will immediately dispatch
DOMWindowClose, which is handled by content JS, and starts the window close process.- A message will be sent from content to parent to start the close,
- This message will end up spinning the parent process event loop at least once before actually closing the window (which will mark the content context as discarded)
- The pop-up creation will send an a
CreateWindowInDifferentProcessmessage to the parent process.
The issue here is that it is possible for the DOMWindowClose message from content to parent to be fully processed, including the full spin of the event loop, before the CreateWindowInDifferentProcess message arrives. This means that the parent process already considers the window closed when the message arrives. The window opening request is then cancelled due to the parent context already being discarded, and we encounter this bug.
The easiest fix here is probably to relax the check in CreateWindowInDifferentProcess to allow creating a pop-up window if the parent window is partially, but not fully, discarded.
|
|
Assignee | |
Comment 9•5 years ago
|
||
|
||
Comment 10•4 years ago
|
||
|
||
Comment 11•4 years ago
|
||
Backed out changeset 5eacf74bc04f (Bug 1643450) for causing android mochitest failures in test_window_open_from_closing.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/a22a57f1a65315d0b2e055e190b8104adf31854c
Failure log: https://treeherder.mozilla.org/logviewer?job_id=325995251&repo=autoland&lineNumber=5735
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 12•4 years ago
|
||
|
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 13•4 years ago
|
||
|
||
Comment 14•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/baa6b71bfaef
https://hg.mozilla.org/mozilla-central/rev/f82872c9ec11
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
Description
•