Open Bug 1350858 Opened 7 years ago Updated 2 months 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, 1 obsolete file)

Bug 1350858 - Only allow aOpener to be non-null at the first call to SetOpenerWindow().
59 bytes, 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.
Note also bug 174349.
See Also: → 174349
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
Attachment #9384723 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: