1632441 - Script-closable window with http:// URL opened from a file:// window does not close after calling window.close()

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[adrigarry]

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

Steps to reproduce:

Page A open a new page B, then after some user actions on page B, this page should be closed by window.close().

Actual results:

Since 75 release, the page B is not closed anymore.

I can't find any relative information on 75 version's release note. Is that a know issue ? Or this is a new behavior relating to https://www.w3.org/TR/html52/browsers.html#dom-window-close specifications ?

Expected results:

Before 75 release of Firefox, the page B was closed.

Comment 1

[Virginia (please send need info request to Brindusa Tot)]

Hi adrigarry,

Thanks for your report.

Would you happen to have any test page as example so we can investigate this issue?

Please also confirm if you are able to reproduce this issue in the latest Firefox Nightly version, you can download it here: https://nightly.mozilla.org/

In the meantime, I'll assign this ticket to the Core DOM: Core & HTML component.

Thanks,
Virginia

Comment 2

[adrigarry]

Attachment: nodejs simple server to reproduce issue

Hi,

In the zip archive, you can find a nodejs simple server. To reproduce, launch server ('node server.js'), and open in firefox the test.html page. This page will open another page that should automatically close few seconds after.

I have reproduce this issue with the latest firefox Nightly version.

Thanks,
Adri

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Edgar, could this be related to the new user activation model? Page B uses setTimeout.

Dear reporter, could you please help try to get the regression window with the tool https://mozilla.github.io/mozregression/ ? thanks!

Comment 4

[Edgar Chen [:edgar]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)

Edgar, could this be related to the new user activation model? Page B uses setTimeout.

It doesn't look like something related to the new user activation model. window.close() doesn't check user action. but I will take a look at anyway.

Comment 5

[Edgar Chen [:edgar]]

I could reproduce this on latest Nightly with the steps in comment #2, I saw following warning message on console,

Scripts may not close windows that were not opened by script.

Comment 6

[Edgar Chen [:edgar]]

91:17.41 INFO: Last good revision: b0e84820d231a3b5a47f2ea72c384828d91f4c49
91:17.41 INFO: First bad revision: b158903288bb2968dff9e587a3a8ca67f7435e37
91:17.41 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0e84820d231a3b5a47f2ea72c384828d91f4c49&tochange=b158903288bb2968dff9e587a3a8ca67f7435e37

It is caused by bug 1603006, Paul, could you take a look? Thanks.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

[Tracking Requested - why for this release]:
This is rather core web functionality being broken.

Comment 8

[Paul Bone [:pbone]]

I don't know the cause, investigating now. Thanks.

Comment 9

[Paul Bone [:pbone]]

I can't reproduce this, I've tried: Nightly and Release on Windows 10, and Nightly on Linux.

• I use the webserver enclosed (as described in comment 2)
• Open a new tab and put localhost:3000/test.html in the address bar (or `hostname:3000/test.html' when I was using windows because node was running on linux).
• The next tab opens, it has the message that it will close, and then it closes.

As I understand it from comment 0, if the tab closes firefox works correctly, if the tab stays open then it's broken.

The test included opens the tabs from the same origin, but the bug title says "not same origin" Is this test incomplete?

Comment 10

[Paul Bone [:pbone]]

Edgar, how did you reproduce it? Is there something I'm missing? Thanks.

Comment 11

[Edgar Chen [:edgar]]

I could reproduce it with loading test.html from file.

Comment 12

[Paul Bone [:pbone]]

Nope, still doesn't reproduce on Nighly, Realease, Linux or Windows.

I'm accepting a pop-up warning as it begins, should I not be doing that? I'm also editing the path in the4 test so it works at all with file:// OH! I think I see, it's the problem going from file:// to http://

Comment 13

[Paul Bone [:pbone]]

Okay, it reproduces in nightly on Linux when going from file:// to http:// and fission is disabled or it's in a non-fission window.

Comment 14

[Julien Cristau [:jcristau]]

wontfix for 77 per bug 1550571 comment 2

Comment 15

[Paul Bone [:pbone]]

The workaround Bug 1634779 may be uplifted. I want to keep this as 'affected' for 77.

Comment 16

[Paul Bone [:pbone]]

Attachment: Bug 1632441 - Add a test case for this bug r=kmag

Bug 1634779 has added a fix for this bug. This patch adds a test to ensure
we don't regress this behaviour again.

Comment 17

[Paul Bone [:pbone]]

Marking as fixed in beta since Bug 1634779 has now been uplifted.

Comment 18

[Andrei Purice]

Reproduced the issue on Firefox 77.0a1 (20200419091145) on Windows 10 and Ubuntu 18.04.4.
Verified fixed on Firefox 77.0b9 (20200521224544). This is also Verified fixed on Firefox 78.0a1 (20200521093657) .

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7124267b7288
Add a test case for this bug r=kmag

Comment 20

[Dorel Luca [:dluca]]

Backed out changeset 7124267b7288 (bug 1632441) for browser_file_to_http_script_closable.js failures CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=304495894&repo=autoland&lineNumber=5376

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=7124267b7288eb6781020e3f7bba940d3cf89aaf

Backout:
https://hg.mozilla.org/integration/autoland/rev/8cd8bd121c60bd097d262b2bdc8f078e4073929b

Comment 21

[Paul Bone [:pbone]]

Thanks. it looks like there's a race on some builds.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f078f7649ab0
Add a test case for this bug r=kmag

Comment 23

[Razvan Maries]

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

Comment 24

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

The patch landed in nightly and beta is affected.
:pbone, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 25

[Paul Bone [:pbone]]

The bug is already fixed in 78 by Bug 1634779, this patch only adds a regression test and doesn't need to be uplifted.

Thanks.