This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given an object defined by IDL, and a property name, I need to know if the property name matches a property that is defined by IDL or if it is a property the developer made up. This is important for https://github.com/annevk/html-cross-origin-objects/blob/master/Location.md. The plan is to get rid of [Unforgeable] for Location and instead lie about configurability. However, to do that effectively we need to know whether the property is IDL-defined.
https://github.com/annevk/html-cross-origin-objects is the new place.
If the input is a platform object implementing a given interface, then I'm assuming we want to return true for: * non-static operations, attributes and constants defined on the interface * "toString", if a stringifier is present * "toJSON", if a serializer is present * "valueOf" * @@iterator, "get", "keys", "values", etc. from iterable/maplike/setlike declarations (not relevant here, but should be present for completeness) Is that all? I guess you should handle "valueOf" on your end since we just want to prevent it from overriding the standard prototype-inherited one.
I'm not clear why this needs to exist. The set of properties defined for Location is finite. Why not just code that into the algorithm?
Part of the reason I am uncomfortable with creating this as a general-purpose mechanism is that IDL methods and properties should strive to be as indistinguishable from normal ones as possible. Special case interfaces may need to keep a list of properties that should not be modified, for security purposes, but it shouldn't be a general distinction available to all specifications and for all interfaces.
Domenic, keeping the list in HTML is problematic since HTML does not have the exhaustive list (at least not without inspecting IDL). They would easily get out of sync. However, I'm wondering now if perhaps Location can use the same overrides that WindowProxy uses for this. Where [[GetOwnProperty]] always sets [[Configurable]] to true and [[DefineOwnProperty]] throws if [[Configurable]] is false. Boris, what do you think?
> However, I'm wondering now if perhaps Location can use the same overrides that > WindowProxy uses for this. Note that the WindowProxy overrides are not necessarily web-compatible. See https://bugzilla.mozilla.org/show_bug.cgi?id=1197958 That said, we could try the same thing for Location, sure. It just seems like a extra risk (though still less than for WindowProxy, but since we've just established that the risk for WindowProxy is "we know it breaks some sites" that's a pretty low bar). The benefit of only doing the weirdness for the IDL-defined props is that it minimizes risk: no one is defining properties with those names on Location objects, because those properties are already non-configurable on Location objects.
Okay, let's just stick to whatever IDL defines then. And I guess I can inline it and we should just update it whenever IDL adds something or we add something to Location. If this is only needed for Location it does not make much sense to have an abstract operation for it. I would still appreciate some guidance what should be included beyond the members listed in the interface. Is this correct for Location? * toString * toJSON * valueOf * @@toPrimitive (per bug 29183) There's also bug 27361 which we'd need to tackle in some way. Also, currently IDL defines [Unforgeable] for interfaces, but as far as I can tell that's only for Location, and we're going to stop using it for Location as it breaks ECMAScript invariants. That is something that can be cleaned up once this is wrapped up.
If we stop using [Unforgeable] however, HTML will need to define toJSON, valueOf, and @@toPrimitive... Not sure if that's desirable and if that can even be done using the current IDL setup. So perhaps to get those defined we need some different kind of keyword?
You can define toJSON and valueOf using current IDL syntax, I believe, though if they're non-enumerable we may need an extended attribute for that. Which we may want anyway, really. For @@toPrimitive we'd need some IDL syntax to have symbol-named stuff....
Okay, the [Unforgeable] stuff is now bug 29383. Also, in https://github.com/annevk/html-cross-origin-objects/issues/20 bz suggested prose that could be used for "IDL-defined property", rather than having to do an enumeration.