Open
Bug 174349
Opened 22 years ago
Updated 2 years ago
Existing window.opener is overwritten by window.open
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
ASSIGNED
People
(Reporter: anders, Assigned: bobowen)
References
Details
(Keywords: compat, testcase)
Attachments
(1 file)
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•22 years ago
|
||
confirming; what does NS4 do?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: compat
OS: Windows 2000 → All
Hardware: PC → All
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: desale → general
Assignee | ||
Comment 3•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → bobowencode
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•11 years ago
|
||
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)
Comment 5•11 years ago
|
||
(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•11 years ago
|
||
Boris, Jst, any feedback here, or do you recall other related bugs?
Flags: needinfo?(jst)
Flags: needinfo?(bzbarsky)
Updated•11 years ago
|
Attachment #8383052 -
Flags: review?(bugs)
Assignee | ||
Comment 7•11 years ago
|
||
(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•11 years ago
|
||
I don't think I have much to add to comment 1, past us no longer caring about compat with NS4.
Flags: needinfo?(bzbarsky)
Comment 9•11 years ago
|
||
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)
Assignee | ||
Comment 10•11 years ago
|
||
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)
![]() |
||
Comment 11•11 years ago
|
||
> 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)
![]() |
||
Updated•8 years ago
|
Updated•7 years ago
|
Flags: needinfo?(jstenback+bmo)
Comment 12•7 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•7 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?
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•