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
OS: Windows 2000 → All
Hardware: PC → All
Mass-reassigning bugs to firstname.lastname@example.org
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  and  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.  http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-opener  http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
(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?
(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.
So, Hixie got back to me  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.  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/254093.html
> 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.
> 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?
You need to log in before you can comment on or make changes to this bug.