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.

Testcase:

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

  file2: <script>
           alert(window.opener);
           window.opener = null;
           alert(window.opener);
         </script>

Er, that test doesn't test what I want to test.  This one does:

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

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

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.

Yeah, this needs to be settable to null.  Browsers differ on whether the null value persists across navigations, as I recall.

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.

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.

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).

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:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

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.

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.
http://html5.org/tools/web-apps-tracker?from=5905&to=5906

How compatible is making this non-replaceable?

mass-move component to LC1