174349 - Existing window.opener is overwritten by window.open

Status: ASSIGNED

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

Description

[Anders Blaagaard]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

confirming; what does NS4 do?

Comment 2

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 3

[Bob Owen (:bobowen)]

Attachment: don't overwrite window.opener when navigating an existing window using window.open

Comment 4

[Bob Owen (:bobowen)]

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

Comment 5

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

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

Comment 6

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

Boris, Jst, any feedback here, or do you recall other related bugs?

Comment 7

[Bob Owen (:bobowen)]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

I don't think I have much to add to comment 1, past us no longer caring about compat with NS4.

Comment 9

[Johnny Stenback (:jst)]

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

Comment 10

[Bob Owen (:bobowen)]

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

Comment 11

[Boris Zbarsky [: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.

Comment 12

[Gérard Talbot]

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

Comment 13

[Gérard Talbot]

> 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?