This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11839 - window.opener needs to be writable, not readonly (as it is in Gecko, Chrome, IE)
Summary: window.opener needs to be writable, not readonly (as it is in Gecko, Chrome, IE)
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on: 11844
  Show dependency treegraph
Reported: 2011-01-23 02:27 UTC by contributor
Modified: 2011-08-04 05:15 UTC (History)
11 users (show)

See Also:


Description contributor 2011-01-23 02:27:32 UTC

window.opener needs to be writable, not readonly

Posted from:
Comment 1 Boris Zbarsky 2011-01-23 02:29:56 UTC
In particular, Gecko allows setting it to null, and web pages rely on this.  So does Safari, Chrome, Opera, and IE.  I haven't tested what other values it can be set to; Gecko doesn't allow any values other than null for unprivileged scripts.


  file1: <div onclick="'file2.html')">click me</div>

  file2: <script>
           window.opener = null;
Comment 2 Boris Zbarsky 2011-01-23 02:37:42 UTC
Er, that test doesn't test what I want to test.  This one does:

file1.html: <div onclick="'file2.html')">click me</div>

file2.html: <script>
              window.opener = null;
              window.location.href = "file3";

file3.html: <script>alert(window.opener);</script>

This alerts "[object DOMWindow]" twice in Safari, "[object DOMWindow]" and then "null" in Chrome, "[object Window]" and then "null" in Gecko, "[object Window]" twice in Opera, "[object]" and "null" in IE.

So it looks like the property is just replaceable in Opera and Safari, but is both replaceable _and_ writable in Gecko, IE, and Chrome.

Cameron is cced because once this property is writable WebIDL needs to define what it means for a property to be both writable _and_ replaceable.
Comment 3 Adam Barth 2011-01-26 05:40:09 UTC
Yeah, this needs to be settable to null.  Browsers differ on whether the null value persists across navigations, as I recall.
Comment 4 Boris Zbarsky 2011-01-26 05:43:24 UTC
Well, it's settable to null for the current page given existing spec text (because it's replaceable, so writing to it shadows the property).

I suppose I could write a testcase that grabs the getter off the prototype after setting to null and calls it on the window, etc... but I'm not sure browsers' ES5 support is far enough along to make that sane.

So in the meantime, a simple way to tell apart replacement and assignment seems to be navigation.
Comment 5 Adam Barth 2011-01-26 05:51:22 UTC
My understanding is that opener resists being set to random values, but I could be mistaken.  It's been a while since I studied it.
Comment 6 Boris Zbarsky 2011-01-26 05:54:48 UTC
Yeah, the only value it needs to allow setting to is null.  But that needs to persist across navigations, imo (which it does in Chrome, Gecko, and IE).
Comment 7 Ian 'Hixie' Hickson 2011-02-18 22:45:52 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Partially Accepted
Change Description: see diff given below
Rationale: Wow, there's little interop on this. WebKit lets you set it to anything, Firefox throws if you set it to a non-Window and ignores setting it to a Window, IE lets you set it to anything but changes it's value to an Error object...

Anyway I've made it a mutable non-replaceable attribute except that the only value it can take is null, all other Window values are ignored and all other values cause a TypeError in WebIDL. nulls neuter the browsing context so that any Window objects in that browsing context, including past ones, will start returning null instead.
Comment 8 contributor 2011-02-18 22:46:24 UTC
Checked in as WHATWG revision r5906.
Check-in comment: Change how window.opener works to allow it to be set to 'null' and have that persist past page load.
Comment 9 Boris Zbarsky 2011-03-10 02:15:21 UTC
How compatible is making this non-replaceable?
Comment 10 Michael[tm] Smith 2011-08-04 05:15:40 UTC
mass-move component to LC1