This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Is there any class that supports indexed getters that also has a member that could be mistaken for an indexed getter? Because that seems to be the only reason why we wouldn't return a property descriptor for undefined here. And the fact that we don't return a property descriptor for undefined here actually creates a bug for the Window object, since its named properties are looked up in a different algorithm on a different object. Having said that, this bug will go away since we'll most likely move indexed property lookup to the window proxy object so the Window object can become an "ordinary" object.
> Because that seems to be the only reason why we wouldn't return a property > descriptor for undefined here. You mean at the point where we set ignoreNamedProps to true in http://heycam.github.io/webidl/#getownproperty-guts step 1.3? It's possible that this predates the change to make [[DefineOwnProperty]] just disallow adding indexed-looking props, assuming it ever allowed it. So back then you could have expandos with integer names and those were supposed to get picked up via step 3. That said, I guess someone _could_ in theory define an unforgeable thing named "_1" (in the IDL) on an interface with indexed props. That seems silly and we should not support it. So I think you're right that we could just return here if we wanted to, though it should be equivalent to fall through, since we know step 3 won't find anything. Note that we do still need the ignoreNamedProps thing in general, for [[Set]] to work right.
Given that [[Set]] needs this setting the variable there is actually shorter than returning the correct property descriptor.