Clarify that window and document named getters return the same object every time, not a different one

[ayg]

This seems to match behavior in UAs. Is this actually specified either way right now, or is it just ambiguous? I don't see where the spec says if it should be the same object or a new one.

[domenic]

I guess you are talking about the HTMLCollection case. Otherwise it is indeed specific as it returns specific objects in the DOM tree, which always maintain their identity over time.

There exists some text for this for e.g. getElementsByName:

When the method is invoked on a Document object again with the same argument, the user agent may return the same as the object returned by the earlier call. In other cases, a new NodeList object must be returned.

But I guess it did not makes its way to the named getters.

I wonder whether we want to have a tighter requirement that you must always return the same value. I wonder if that's even true in implementations though, e.g. maybe they clear their map of name -> HTMLCollections every once in a while (such as on heavy document mutation).

[ayg]

In Gecko right now we don't particularly match the spec at all, but insofar as we do, we have a single list that's allocated once for the document when it's first needed and never deallocated. I think we should either spec that it's always the same value or always a new one -- I don't think UAs should be allowed to sometimes return a new one if they feel like it.

[annevk]

@ayg we tried to fight pretty hard for that with getelementsByName() and friends, but unfortunately WebKit and co didn't care. Perhaps we can revisit that now though.

[ayg]

Well, I can see that implementations might want to not make unnecessary copies but also not be forced to keep references to an unlimited quantity of objects around forever. Especially for something like getElementsByName(), you could imagine some code might call it thousands of times in a loop with the same value (perhaps for a microbenchmark), so you don't want to make a new copy each time. While other code might call it thousands of times in a loop with different values, so you don't want to keep them all around.

It's probably easier to optimize returning a new copy each time, because copies can be made reasonably cheap if they share the underlying list. But it's probably not as nice for authors to have lots of non-equal but completely interchangeable objects floating around.

What's WebKit "and co"? Just WebKit, or other UAs also? At the end of the day, we could leave this undefined if UAs really don't want to be constrained. It wouldn't be the end of the world in terms of interop. But always better to have it specced.

[annevk]

At the time it was just WebKit, but now it might include Chromium and maybe even Gecko for performance reasons (if the others do it it's hard not to follow).

[annevk]

Probably worth keeping https://bugzilla.mozilla.org/show_bug.cgi?id=1010241 and https://bugzilla.mozilla.org/show_bug.cgi?id=903572 in mind when testing this.