11267 2010-11-08 23:22:02 +0000 Add a [NonConfigurable] extended attribute 2011-06-27 01:26:22 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED FIXED P2 normal --- 1 cam cam allen bzbarsky jonas jwalden+w3 mike public-script-coord public-webapps-bugzilla oldest_to_newest 42290 0 cam 2010-11-08 23:22:02 +0000 Certain properties, such as document and location on Window, may need to be non-configurable for security reasons. If in general we have read only IDL attributes exposed as configurable accessor properties with only a getter, then we would need [NonConfigurable] or similar to make the property non-configurable. 49875 1 cam 2011-06-20 02:42:48 +0000 It's not clear to me that properties like this would really need to be non-configurable, in fact. If someone can clearly demonstrate that they do, please reopen. 49880 2 bzbarsky 2011-06-20 04:14:39 +0000 NPAPI plug-ins commonly determine the location of the document (which affects what they will let it do and their same-origin checks) by loading the URI "javascript:window.location" via NPAPI and then examining the resulting string. While it's desirable to add hooks to NPAPI to ask for this information directly, there is an existing installed base of plug-ins where this needs to keep working... 49883 3 jonas 2011-06-20 05:21:37 +0000 But do we really need WebIDL support for this? You can always describe things in prose if it's just a one-off (especially one that we long term would like to see go away) 49884 4 bzbarsky 2011-06-20 05:41:53 +0000 I guess I'd be fine with that too. For our internal use we may end up sticking this in the IDL, of course.... 49892 5 cam 2011-06-20 06:46:26 +0000 Is there a list of which properties would require this, beyond document and location? If it's just a couple like this, defined only on Window, maybe overriding Web IDL in prose is indeed simpler. 49894 6 zcorpan 2011-06-20 06:53:24 +0000 See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12998 49901 7 cam 2011-06-20 08:25:35 +0000 If plugins are evaluating window.location, I guess we need to prevent own properties of the Window object from being defined with the name "location", as well as prevent redefinition of it on Window.prototype? What about when an <iframe name=location> is in the document? :) 49908 8 allen 2011-06-20 09:43:02 +0000 (In reply to comment #7) > If plugins are evaluating window.location, I guess we need to prevent own > properties of the Window object from being defined with the name "location", as > well as prevent redefinition of it on Window.prototype? What about when an > <iframe name=location> is in the document? :) The best way to prevent the creation of such a property is to predefine a non-configurable own 'location' on all Window objects. The method would be the same as the one that would be inherited from Window.prototype 49917 9 bzbarsky 2011-06-20 15:01:48 +0000 > I guess we need to prevent own properties of the Window object from being > defined with the name "location", as well as prevent redefinition of it on > Window.prototype? In Gecko, 'location' is a non-configurable own property on the window. > What about when an <iframe name=location> is in the document? This case can be buggy in Gecko right now, but that's just an internal Gecko bug. 50203 10 cam 2011-06-24 00:36:54 +0000 I've come around to the idea that this should be specified in Web IDL. Proposal: make interface A { [NonConfigurable] readonly attribute Type name; }; mean that there is no property "name" on A.prototype, but there is an own non-configurable property "name" on every A instance. (We'll work under the assumption that the proxies will support this.) 50206 11 jonas 2011-06-24 01:55:46 +0000 Sorry to bikeshed, but isn't the bigger effect that [NonConfigureable] has the fact that it moves the property from the prototype to the leaf object? If so, wouldn't something like [LeafProperty] or [ObjectProperty] be a better name? Also, what happens for if something has [NonConfigureable] (or [LeafProperty] or [ObjectProperty] or whatever) but isn't marked as readonly? Is that invalid IDL or does that have some meaning? 50207 12 cam 2011-06-24 02:24:58 +0000 (In reply to comment #11) > Sorry to bikeshed, but isn't the bigger effect that [NonConfigureable] has the > fact that it moves the property from the prototype to the leaf object? If so, > wouldn't something like [LeafProperty] or [ObjectProperty] be a better name? It's a fair point. I was thinking of [Unforgeable] or something along those lines. > Also, what happens for if something has [NonConfigureable] (or [LeafProperty] > or [ObjectProperty] or whatever) but isn't marked as readonly? Is that invalid > IDL or does that have some meaning? I'd make it invalid IDL. 50351 13 cam 2011-06-27 01:26:22 +0000 I added [Unforgeable], which causes properties corresponding to readonly attributes to non-configurable and to go on the object itself rather than the prototype. http://dev.w3.org/2006/webapi/WebIDL/#Unforgeable http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.318;r2=1.319;f=h