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.

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

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)

I guess I'd be fine with that too.  For our internal use we may end up sticking this in the IDL, of course....

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.

See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12998

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? :)

(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

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

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

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?

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

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