Firefox
log: window
log: navigator
log: location
log: window
log: document
log: navigator
log: location

Chrome
log: top
log: window
log: location
log: document threw TypeError: const 'document' has already been declared
log: webkitNotifications
log: sessionStorage
log: webkitIndexedDB
log: applicationCache
log: pageXOffset
log: webkitStorageInfo
log: localStorage
log: defaultstatus
log: styleMedia

Opera
log: devicePixelRatio
log: document
log: frameElement
log: localStorage
log: location
log: outerHeight
log: outerWidth
log: parent
log: screenX
log: screenY
log: self
log: sessionStorage
log: top
log: window

Also see http://www.w3.org/Bugs/Public/show_bug.cgi?id=11267

I would those readonly attributes in Opera and Chrome to become overridable once properties for IDL attributes are moved to the prototype as accessor properties.

(I think it doesn't matter here, but note that doing `eval("var x")` is different from `var x` in ES5, as the former creates properties that are configurable while the latter creates them non-configurable.)

Also http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1037

Firefox
doesn't like messing with the location prototype at all (Location.prototype[x] also throws)

Chrome
log: Non-configurable: replace, origin, assign, pathname, host, hostname, port, search, hash, reload, href, protocol
log: Normal: getParameter

Opera
log: Non-configurable: hash, host, hostname, href, pathname, port, protocol, search
log: Normal: reload, toString, valueOf, replace, assign

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1038

Firefox and Opera override location there. Chrome does not.

What does this translate to in the IDL?

Bug 11267 has a proposal for a [NonConfigurable] extended attribute that you can put on readonly IDL attributes.

mass-move component to LC1

So... what, do I just mark all the attributes in comment 1 as [NonConfigurable]? How does this relate to [Replaceable]?

If the goal is to make these properties not overridable with "var", then you wouldn't want to make them [Replaceable].  It sounds like putting [Unforgeable] on the IDL attributes whose properties you want to be non-configurable and non-overridable on the object itself is the thing to do.  (I renamed [NonConfigurable] to [Unforgeable] to reflect its purpose better, since the effect is also to make [[DefineOwnProperty]] on the object itself to refuse to create a property with the given name.)

I haven't done the testing myself, so I won't on which specific IDL attributes need this.

(In reply to comment #10)
> I haven't done the testing myself, so I won't on which specific IDL attributes
> need this.

*won't comment

Ok, I'll mark the following as [Unforgeable]:
  Window.window
  Window.location
  Window.document

(That's the common subset in comment 1, it seems.)

IIRC Flash uses something like

javascript:top.location.href

as part of its "origin" security checks, so 'top' should be unforgeable in order to keep Flash security in check.

How does Firefox avoid Flash's origin checks getting owned?

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: Accepted
Change Description: see diff given below
Rationale: see comment 12 and comment 13.

Checked in as WHATWG revision r6569.
Check-in comment: Mark some Window properties [Unforgeable].
http://html5.org/tools/web-apps-tracker?from=6568&to=6569

> How does Firefox avoid Flash's origin checks getting owned?

Recently, https://wiki.mozilla.org/NPAPI:DocumentOrigin

I don't recall seeing "top" in the javascript that Flash used to evaluate, but I'll see if I can double-check.