Existing window.opener is overwritten by window.open

ASSIGNED
Assigned to

Status

()

defect
P3
minor
ASSIGNED
17 years ago
Last year

People

(Reporter: anders, Assigned: bobowen)

Tracking

({compat, testcase})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

17 years ago
When calling window.open(url,name) from a window with the same name, it will
just return the existing window with the new URL as expected, but the
window.opener property is overwritten, so window.opener == window.
I couldn't find any references to what the correct behavior is, but I was
expecting to have the original window.opener value preserved as it happens in IE.
confirming; what does NS4 do?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: compat
OS: Windows 2000 → All
Hardware: PC → All
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: desale → general
Assignee: nobody → bobowencode
Status: NEW → ASSIGNED
Comment on attachment 8383052 [details] [diff] [review]
don't overwrite window.opener when navigating an existing window using window.open

As far as my reading of the spec at [1] and [2] goes this behaviour is incorrect.
Chrome appears to do the same as Firefox, but IE and Opera appear to keep the original opener.

I need to write a test for this, although my re-write of the tests for bug 885140 (which I'm about to upload) rely on the specced behaviour, which is why I've ended up fixing this.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-opener
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
Attachment #8383052 - Flags: review?(bugs)
(I assume you tested obsolete old Opera)
So currently Blink and Gecko have one behavior and Trident other.
What does WebKit do? Probably the same as Blink.

Better to bring this issue to whatwg, before changing the behavior, IMO.
I agree not changing the opener makes sense, but since majority of engines don't probably do that
atm...
Boris, Jst, any feedback here, or do you recall other related bugs?
Flags: needinfo?(jst)
Flags: needinfo?(bzbarsky)
Attachment #8383052 - Flags: review?(bugs)
(In reply to Olli Pettay [:smaug] from comment #5)
> (I assume you tested obsolete old Opera)
> So currently Blink and Gecko have one behavior and Trident other.
> What does WebKit do? Probably the same as Blink.

Yes, this would have been for Presto, I've not tested WebKit, but the code certainly appears to do the same as Blink, as you suggest.

> Better to bring this issue to whatwg, before changing the behavior, IMO.

OK, good idea thanks.
Email sent.
I don't think I have much to add to comment 1, past us no longer caring about compat with NS4.
Flags: needinfo?(bzbarsky)
Hmm, not much in terms of useful memory of details around this topic here I'm afraid :(

The fact that chrome/webkit behave like we do may very well mean that they did that to match us due to some sites depending on this behavior, which may very well have been in an if (!ie) code path or somesuch back in the day. Tricky one...
Flags: needinfo?(jst)
No longer blocks: 885140
So, Hixie got back to me [1] and confirmed that, as far as he's concerned, window.opener should stay as the original opener in this circumstance.

He also asked if I'd done any compatibility testing.
How would we normally go about this?
Do we just land the change and see if it causes any problems in nightly?
I assume some sort of announcement to a mail group would help, in case of problems. :-)

Later in the thread Charlie Reis from Google said they'd be open to changing Blink as well, if there are no compat issues.

I'll have to add a test(s) as well, but that should be fairly straight forward.

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254093.html
Flags: needinfo?(jst)
Flags: needinfo?(bzbarsky)
> How would we normally go about this?

Badly.  :(

One thing that may be worth doing is just adding telemetry for how much the opener getter is called after it's been reset like this.

Past that, yes, we could ship the change in nightly/aurora for a bit and see if anything breaks.

> Later in the thread Charlie Reis from Google said they'd be open to changing Blink as
> well, if there are no compat issues.

Can we get them to go first?  We're a bit tired of going first on this stuff and taking the compat hits.
Flags: needinfo?(bzbarsky)
Flags: needinfo?(jstenback+bmo)

Comment 12

2 years ago
(In reply to Anders Blaagaard from comment #0)
> When calling window.open(url,name) from a window with the same name, it will
> just return the existing window with the new URL as expected, but the
> window.opener property is overwritten, so window.opener == window.

Anders,
So a test would require 3 windows: the window opener, 1 child window and another URL for that child window and some javascript to get/report what is the window.opener once navigated to the 2nd URL for that child window. Am I correct?

(In reply to Bob Owen (:bobowen) from comment #4)
> I need to write a test for this

(In reply to Bob Owen (:bobowen) from comment #10)
> I'll have to add a test(s) as well, but that should be fairly straight
> forward.

Please verify that this test is correct:

http://www.gtalbot.org/BugzillaSection/Bug174349Opener.html

and report any issues regarding it.

Note: turning OFF the "Open a new tab instead of a new window" in about:preferences is preferable when trying that test... although if it is ON, the test should still be valid and working as expected.
Keywords: testcase

Comment 13

2 years ago
> So a test would require 3 windows: 
Err. Rather the test requires 2 window objects and 3 distinct, different web addresses (URLs) 

> Note: turning OFF the "Open a new tab instead of a new window" in
> about:preferences is preferable when trying that test... although if it is
> ON, the test should still be valid and working as expected.

In Chrome 59.0.3071.115 and Chrome 61.0.3141.7, there is no such (or equivalent) user setting/preference for spawning new child window, otherwise I could not find any.

http://www.gtalbot.org/BugzillaSection/Bug174349Opener.html
fail in Firefox 54.0, Chrome 59 and Chrome 61 ... same as Bob Owen wrote in comment 4 .

Can anyone report Safari 10.2 and Edge 15.15063 results of Bug174349Opener.html test?
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.