Open Bug 1350858 Opened 8 years ago Updated 2 years ago

window.opener returns the wrong browsing context after window.open(url, '_parent')

Categories

(Core :: DOM: Navigation, enhancement, P3)

Product:
Core
Component:
DOM: Navigation
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox55 --- affected

People

(Reporter: zcorpan, Unassigned)

References

Details

(Keywords: dev-doc-needed)

Attachments

(1 file)

Bug 1350858 - Only allow aOpener to be non-null at the first call to SetOpenerWindow().
(deleted), text/x-review-board-request
bzbarsky
: review-
Details
See https://github.com/w3c/web-platform-tests/pull/5150 test case /html/browsers/windows/browsing-context-names/browsing-context-choose-parent-003.html > There's also an interesting difference in browser behavior WRT > choose-browsing-context-parent-003.html. > > According to the spec [1]: > >> The opener IDL attribute on the Window object, on getting, must return the >> WindowProxy object of the browsing context **from which the current browsing >> context was created** (its opener browsing context) > > (emphasis mine) > > Safari and Chrome are both steadfastly retaining a browsing context's original > opener, even if another browsing context later opens a different document into > that context/window. FireFox, however, will replace the window.opener of the > _parent context with the window that invokes .open (assuming the opener isn't > disowned, etc.). > > I have two hunches here: Firefox's behavior is the errant one and this is > likely going to affect more than just the named _parent context. But I'm not > 100% certain on the former. > > [1] > https://html.spec.whatwg.org/#navigating-auxiliary-browsing-contexts-in-the-dom So Gecko changes window.opener but other browsers do not, and the spec does not say to do that, as far as I can tell.
Samael might have ideas of how to deal with this?
Flags: needinfo?(sawang)
What does Edge do? This is an extremely long-standing behavior, and I'm pretty worried about compat fallout from changing it, so would like to be _very_ sure that we want to change it before we do so.
Flags: needinfo?(sawang)
In particular, the description of Chrome's and Safari's behavior in the Github PR is _not_ correct. Simple testcase: <!DOCTYPE html> <input type="button" onclick="alert(opener)" value="check opener"> <input type="button" onclick="window.open(location.href, '_self')" value="do open"> If you load that, cllick "check opener", then click "do open", then click "check opener" you will get null alerted the first time and a non-null thing alerted the second time.
Comment on attachment 8864794 [details] Bug 1350858 - Only allow aOpener to be non-null at the first call to SetOpenerWindow(). https://reviewboard.mozilla.org/r/136474/#review139732 Per comments, this doesn't give us behavior compatible with Blink or WebKit or ourselves and may well not be web-compatible...
Attachment #8864794 - Flags: review?(bzbarsky) → review-
(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #4) > What does Edge do? > > This is an extremely long-standing behavior, and I'm pretty worried about > compat fallout from changing it, so would like to be _very_ sure that we > want to change it before we do so. Followed your explanation on https://github.com/whatwg/html/issues/2636 now I understand the behaviors are still confusing and unclear across different browsers. Until there's a conclusion in the spec issue we probably shouldn't make any change here.
Flags: needinfo?(sawang)
Assignee: sawang → nobody
Priority: -- → P3
Component: DOM: Core & HTML → DOM: Navigation
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: