1591302 - Firefox 70.0 allows window.close() to close target="_blank" window, but 72.0a1 nightly doesn't

Status: RESOLVED DUPLICATE of bug 1353466

(Core :: DOM: Core & HTML, enhancement)

Description

[FFuser]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36

Steps to reproduce:

Click a link with target="_blank".
Then, click a link with window.close() in the new window/tab.
The link is like <a href="javascript:void(0)" onclick="window.close()">Close</a>.

These links are internal link. Not cross domain, but inside my site.

Actual results:

A warning "Scripts may not close windows that were not opened by script." occurs, and window.close() is blocked on Firefox 72.0a1 nightly.

Expected results:

window.close() should work, and shouldn't be blocked.

Chrome 78.0.3904.70 and Chrome Canary 80.0.3949.0 allow window.close() to close target="_blank" window. Firefox 70.0 also allows this.

However, Firefox 72.0a1 nightly only allows window.close() to close windows opened by window.open(), and not allows to close windows opened by target="_blank".

I understand that this behavior is due to this document:
https://developer.mozilla.org/en-US/docs/Web/API/Window/close

But I think this is too strict.

I recommend that Firefox should allow window.close() to close not only windows that were opened by script, but also windows with target="_blank" that were opened by user's action.

These links are clicked by user's action, not by script.
Users intend to close the window by themselves, by clicking the window.close() link.
If such window.close() is blocked, users are confused.
So Firefox shouldn't block this window.close().

Firefox should allow window.close() to close windows that were opened by target="_blank" links, which are clicked by users themselves.

In fact, Chrome allows to close them.

Comment 1

[FFuser]

If the new window opened by target="_blank" doesn't have opener (such as the case with rel="noopener"),
the window.close() should be blocked to prevent Tabnabbing.

But if the new window has opener and the link is internal link (Both opener and the new window are in the same site),
the site sometimes want to use opener.
The site want to prevent Tabnabbing only through external link.

In such cases, the site want to use window.close().

Comment 2

[Daniel Bodea [:danibodea]]

A test page is needed in order to confirm this issue/enhancement, but it seems very well described, so I will set its component to Tabbed Browser and let it get picked up by a more skilled person. If the component set is not appropriate, please change it to a more appropriate one. Thank you!

Comment 3

[FFuser]

Wow... This bug may be fixed in Firefox nightly 72.0a1 (2019-10-29) !

Here is a test page, but this issue no longer occurs now.
https://ss1.xrea.com/ango.g3.xrea.com/jkkn/firefox_bug.html

Comment 4

[FFuser]

Let me correct it.
It still occurs on this page:
http://sinst.php.xdomain.jp/all_stations.php

(This is my Japanese site.
First, click "新相ノ木" link.
Then, click "閉じる" on footer.
"閉じる" means "close".)

Maybe Firefox has been changed so that it always blocks window.close() in non-SSL sites.
If so, this is a reasonable design and not a bug.

Comment 5

[FFuser]

Wait... Non-ssl may not be the cause...

firefox_bug.html works well even under file:/// environment,
but the HTML file from all_stations.php results in block of window.close()...

I deleted rel="nofollow" from all_stations.php, and re-tested them,
but the result is the same.

What is the difference between http://sinst.php.xdomain.jp/all_stations.php and https://ss1.xrea.com/ango.g3.xrea.com/jkkn/firefox_bug.html ?

Comment 6

[FFuser]

Sorry for lots of corrections.
I mistyped the test page firefox_bug.html. I typed target="blank", missing "_" before "blank"
I corrected and retested the firefox_bug.html, and the bug still occurs.
So please delete Comment 3-5. These comments are wrong.

Comment 7

[FFuser]

Here is a test page:
https://ss1.xrea.com/ango.g3.xrea.com/jkkn/firefox_bug.html

I also captured a repro video:
https://drive.google.com/open?id=1ZV9gc5S3mXwjp5GpuEE1HR_ikBDq1pnI

Comment 8

[Daniel Bodea [:danibodea]]

I can now confirm the reproduction f this issue in Nightly v72.0a1 from 2019-10-29 and beta v71.0b5. It does NOT occur on Release v70.0 or in ESR v68.2.0esr. For more info on the reproduction for later use, I recommend using the repro video from comment 7. Thank you, FFuser!

Comment 9

[FFuser]

First of all, is this a specification change intended by someone, or an unintended bug?
If it is a bug, I hope someone will fix it before the official version is released.
As this change was made in a recent version, it may be easy to determine who caused the change.

Comment 10

[FFuser]

Any updates?
This doesn't seem to be fixed yet, even on Firefox nightly 72.0a1.
I hope this will be fixed before the official release of Firefox 71 on December 2019, because this is a recent regression.

Comment 11

[FFuser]

Wrong: even on Firefox nightly 72.0a1
Correct: even on Firefox nightly 72.0a1 (2019-11-18)

Comment 12

[Masatoshi Kimura [:emk]]

This is a fallout from bug 1522083. Since this is enabled only for Nightly and early Beta, Release channel is not affected (bug 1546415.)

Comment 13

[Anne (:annevk)]

This sounds a lot like bug 1531289, bug 1608852, and most notably bug 1353466, of which this is probably a duplicate?

Comment 14

[(no longer active)]

(In reply to Anne (:annevk) from comment #13)

This sounds a lot like bug 1531289, bug 1608852, and most notably bug 1353466, of which this is probably a duplicate?

Sounds very plausible.

Comment 15

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

I cannot reproduce this on nightly 79.0a1 (2020-06-02). Looks it was resolved by bug 1353466 which was landed in nightly 79 two days ago.

Comment 16

[Anne (:annevk)]

That's great, same here.