"attribute getter" steps skip security checks on namespaces

[tabatkins]

The attribute getter algo can be called with an interface or a namespace. However, step 1.1.2 only checks if the object is an interface; if it is, it does some security checks, and actually grabs the IDL value, so step 1.1.3 can invoke the getter steps for the attribute on it.

A namespace will fail that check, meaning "idlObject" is left as null (set in step 1.1.1), and then 1.1.3 invokes the getter steps for the namespace's attribute on null. This'll break spec algos that expect the [=this=] value to actually be the namespace object the attribute is defined on.

Is this intentional? Are namespaces not intended to be able to carry any internal state that an attribute getter might look at? (And intended to be accessible cross-origin, since the security check is bypassed? Well, I suppose getting the namespace object from Window in the first place would fail, since none of the allowed cross-origin properties are namespaces.) If so, would you mind if I PR'd some editorial fixes that make it clear this is intentional rather than it just being a behavior that falls out of the algo?

[domenic]

Are namespaces not intended to be able to carry any internal state that an attribute getter might look at?

Exactly.

If so, would you mind if I PR'd some editorial fixes that make it clear this is intentional rather than it just being a behavior that falls out of the algo?

Seems like a great idea.