12998 2011-06-20 06:38:39 +0000 Some attributes are not overridable with 'var' in browsers. See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1035 2012-04-20 17:15:36 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#window P3 normal --- 1 contributor ian bzbarsky cam ian mike public-html-admin public-html-wg-issue-tracking zcorpan public-html-bugzilla oldest_to_newest 49889 0 contributor 2011-06-20 06:38:39 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/browsers.html Multipage: http://www.whatwg.org/C#window Complete: http://www.whatwg.org/c#window Comment: Some attributes are not overridable with 'var' in browsers. See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1035 Posted from: 85.227.159.4 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.131 Version/11.11 49890 1 zcorpan 2011-06-20 06:41:46 +0000 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 49891 2 zcorpan 2011-06-20 06:44:20 +0000 Also see http://www.w3.org/Bugs/Public/show_bug.cgi?id=11267 49897 3 cam 2011-06-20 07:05:36 +0000 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.) 49903 4 zcorpan 2011-06-20 08:38:27 +0000 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 49905 5 zcorpan 2011-06-20 08:47:11 +0000 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1038 Firefox and Opera override location there. Chrome does not. 50202 6 ian 2011-06-24 00:34:40 +0000 What does this translate to in the IDL? 50205 7 cam 2011-06-24 00:42:58 +0000 Bug 11267 has a proposal for a [NonConfigurable] extended attribute that you can put on readonly IDL attributes. 53359 8 mike 2011-08-04 05:13:07 +0000 mass-move component to LC1 54853 9 ian 2011-08-13 01:43:24 +0000 So... what, do I just mark all the attributes in comment 1 as [NonConfigurable]? How does this relate to [Replaceable]? 54855 10 cam 2011-08-13 02:09:44 +0000 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. 54858 11 cam 2011-08-13 02:13:40 +0000 (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 57097 12 ian 2011-09-21 20:01:01 +0000 Ok, I'll mark the following as [Unforgeable]: Window.window Window.location Window.document (That's the common subset in comment 1, it seems.) 57153 13 zcorpan 2011-09-22 14:14:52 +0000 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. 57210 14 ian 2011-09-22 23:50:05 +0000 How does Firefox avoid Flash's origin checks getting owned? 57211 15 ian 2011-09-22 23:51:40 +0000 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. 57212 16 contributor 2011-09-22 23:54:00 +0000 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 66902 17 bzbarsky 2012-04-20 17:15:36 +0000 > 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.