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 12998 - Some attributes are not overridable with 'var' in browsers. See
Summary: Some attributes are not overridable with 'var' in browsers. See http://softwa...
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:
Reported: 2011-06-20 06:38 UTC by contributor
Modified: 2012-04-20 17:15 UTC (History)
7 users (show)

See Also:


Description contributor 2011-06-20 06:38:39 UTC

Some attributes are not overridable with 'var' in browsers. See

Posted from: by
User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.131 Version/11.11
Comment 1 Simon Pieters 2011-06-20 06:41:46 UTC
log: window
log: navigator
log: location
log: window
log: document
log: navigator
log: location

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

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
Comment 2 Simon Pieters 2011-06-20 06:44:20 UTC
Also see
Comment 3 Cameron McCormack 2011-06-20 07:05:36 UTC
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.)
Comment 4 Simon Pieters 2011-06-20 08:38:27 UTC

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

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

log: Non-configurable: hash, host, hostname, href, pathname, port, protocol, search
log: Normal: reload, toString, valueOf, replace, assign
Comment 5 Simon Pieters 2011-06-20 08:47:11 UTC

Firefox and Opera override location there. Chrome does not.
Comment 6 Ian 'Hixie' Hickson 2011-06-24 00:34:40 UTC
What does this translate to in the IDL?
Comment 7 Cameron McCormack 2011-06-24 00:42:58 UTC
Bug 11267 has a proposal for a [NonConfigurable] extended attribute that you can put on readonly IDL attributes.
Comment 8 Michael[tm] Smith 2011-08-04 05:13:07 UTC
mass-move component to LC1
Comment 9 Ian 'Hixie' Hickson 2011-08-13 01:43:24 UTC
So... what, do I just mark all the attributes in comment 1 as [NonConfigurable]? How does this relate to [Replaceable]?
Comment 10 Cameron McCormack 2011-08-13 02:09:44 UTC
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.
Comment 11 Cameron McCormack 2011-08-13 02:13:40 UTC
(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
Comment 12 Ian 'Hixie' Hickson 2011-09-21 20:01:01 UTC
Ok, I'll mark the following as [Unforgeable]:

(That's the common subset in comment 1, it seems.)
Comment 13 Simon Pieters 2011-09-22 14:14:52 UTC
IIRC Flash uses something like


as part of its "origin" security checks, so 'top' should be unforgeable in order to keep Flash security in check.
Comment 14 Ian 'Hixie' Hickson 2011-09-22 23:50:05 UTC
How does Firefox avoid Flash's origin checks getting owned?
Comment 15 Ian 'Hixie' Hickson 2011-09-22 23:51:40 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: Accepted
Change Description: see diff given below
Rationale: see comment 12 and comment 13.
Comment 16 contributor 2011-09-22 23:54:00 UTC
Checked in as WHATWG revision r6569.
Check-in comment: Mark some Window properties [Unforgeable].
Comment 17 Boris Zbarsky 2012-04-20 17:15:36 UTC
> How does Firefox avoid Flash's origin checks getting owned?


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