[LegacyUnenumerableNamedProperties] extended attribute appears on a interface that supports named properties, it indicates that all the interface’s named properties are unenumerable."
Implementing this should also help clean up the bindings code: some getters/setters have [NotEnumerable], which does not make sense for indexed properties and which should be replaced by [LegacyUnenumerableNamedProperties] (in the interface declaration) for named properties.
I think this is going to be M63 material given M62 is close to branching and should already be in feature freeze mode.
The infrastructure required to support [LUNP] has landed, but nothing is currently using it yet. Converting existing IDLs as suggested in comments #1 and #2 depends on https://bugs.chromium.org/p/v8/issues/detail?id=6627 being fixed again after its CLs were reverted.
@Raphael, the asymmetry between Object.keys()/Object.values() for the Storage interface will be fixed in this issue?
localStorage.setItem(0, 0)
Object.getOwnPropertyDescriptor(localStorage,0).enumerable // false
Object.keys(localStorage).length //1
Object.values(localStorage).length // 0
Correction: it's possible that either my commit from comment #6 or the V8 changes from bug that was blocking this one have fixed your issue. I've tried content_shell with Chromium master and got the right values from localStorage.
Hmm, it looks like numeric keys are still buggy. In any case, this is unrelated to [LegacyUnenumerableNamedProperties], so can you file a separate bug and CC me there?
> can you file a separate bug and CC me there?
Actually, I've got a fix here. I'll reference bug 719703 instead, as it's an edge case for the change I added in comment #6.
Comment 1 by lunalu@chromium.org
, Mar 24 2017