Making Location.ancestorOrigins a FrozenArray is not Web-Compatible

[cdumez]

https://html.spec.whatwg.org/#the-location-interface:dom-location-reload

[Unforgeable, SameObject] readonly attribute FrozenArray<USVString> ancestorOrigins;

Using a FrozenArray instead of a DOMStringList here does not seem to be Web-Compatible. It breaks notifications on Google.com: If you have notifications to view and you click on the notifications area, they do not show.

Google.com uses the following JS code:
(c = c.location.ancestorOrigins) && 0 < c.length && (c = c.item(0), !/\/plus.google.com$/.test(c) && Vaa.test(c) && 1 == ne && (this.M5a.orig = c));

Error: “Exception with thrown value: TypeError: c.item is not a function. (In 'c.item(0)', 'c.item' is undefined)”
-> c.item() works on a DOMStringList but not on a JS Array.

Note that Google Chrome is still using a DOMStringList. We had switched to a FrozenArray in WebKit but we will have to revert to a DOMStringList.

[cdumez]

@domenic @rniwa

[domenic]

Wow, thanks for taking the bullet and finding that for us. This speaks to the need for FrozenArrayWithItemAndContains, which we've contemplated for a while, but probably we should just switch back to DOMStringList for now? Dang, I thought we'd confined that to IndexedDB.

[cdumez]

FYI, reverting in WebKit via https://bugs.webkit.org/show_bug.cgi?id=165872

[annevk]

Rather than FrozenArrayWithItemAndContains should we just admit defeat and add DOMStringList back as a thing? (And just say folks ought not to use it, like we do for NodeList.)

[domenic]

Yeah, that's probably easier. It's not as good for authors, since they can't use any array methods (e.g. forEach). But it's not the most important rough edge in the platform to fix, I guess.