Closed Bug 1591302 Opened 4 years ago Closed 4 years ago

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

Categories

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

72 Branch
Desktop
All
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1353466
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- affected
firefox72 --- affected

People

(Reporter: potassium634iodide828, Unassigned)

References

(Regression)

Details

(Keywords: regression)

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.

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().

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!

Type: defect → enhancement
Component: Untriaged → Tabbed Browser

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

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.

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 ?

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.

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!

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop

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.

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.

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

Component: Tabbed Browser → DOM: Core & HTML
Product: Firefox → Core

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

Regressed by: 1522083
Keywords: regression

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

Depends on: 1353466

(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.

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.

That's great, same here.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.