DOMStringList has been removed from DOM

[inexorabletash]

Imported from https://www.w3.org/Bugs/Public/show_bug.cgi?id=28067

Relevant bits:

• Adding Array.prototype.contains to ECMAScript is not Web-compatible; ES7 proposes Array.prototoype.includes instead which is nice but not helpful here
• Web IDL has grown FrozenArray<> which is what newfangled specs would use
• Recent public-script-coord thread https://lists.w3.org/Archives/Public/public-script-coord/2015AprJun/0060.html suggests:
  • Let's gather metrics and see what we are forced to maintain - contains, item, both or neither - on each usage of DOMStringList
  • If necessary, let's add something to WebIDL like FrozenArrayWithContains<>

[inexorabletash]

Latest stats:

• item from Location: 0.225% timeline
• contains from IndexedDB: 0.045% timeline
• item from IndexedDB: 0% timeline
• contains from Location: 0.0001% timeline

cc: @foolip @bzbarsky

I guess the next step would be to try implementing the equivalent of FrozenArrayWithContains<> - an array subclass with contains() added which is frozen - ship it, see if it sticks, and then push that into WebIDL.

[foolip]

item on Location does not look promising. If DOMStringList cannot be purged entirely from the platform, is it worthwhile trying to get rid of it from IndexedDB alone?

Given what location.ancestorOrigins is for, it is plausible that almost all of the usage comes from a single origin, so if one could fine out what it is it might be possible to drive down the usage of that enough to eliminate DOMStringList.

[inexorabletash]

We should do an HTTPArchive search; I did one for .contains() and there were many different libraries using it. I did not do one for items but that's possible.

[sicking]

I think there are definitely advantages to returning "real" Array objects over "array like" DOM objects. It's nice to be able to use any of the Array functions that developers are familiar with.

[inexorabletash]

FWIW: 409 hits in HTTPArchive (Alexa Top 10,000, feb 1 2016 crawl) for "ancestorOrigins.item". Just eyeballing the results, unique scripts from liverail.com (249), ad-srv.net (30), redintelligence.net (12) are a big chunk, and then with a variety of script URLs: doubleclick.net (22), googlesyndication.com(13) performgroup.com (11), facebook.com (7) and lots of one-offs.

[foolip]

Hmm, so it's not just one or two big users. Maybe a FrozenArrayWithItem<>?

[inexorabletash]

Yeah, as @sicking has said in the past I think FrozenArrayWithContains<> and FrozenArrayWithItem<> which are real array subclasses are the least-bad path forward here. Again, based on previous discussion, I think we need one implementation to "prove" this approach is web-compatible then we can push these into WebIDL/specs.

I don't know what that entails implementation-wise in Blink, and I haven't thought at all about what other questions this raises (is the subclass's constructor exposed on the global? is instance.constructor callable w/o throwing by user script? etc)

[foolip]

Yeah, seems worth trying. It would probably be web compatible to just have normal arrays (not subclasses) where item or contains is added to the instance directly, if that could be simpler to implement.

[inexorabletash]

For the spec for now (especially for "2.0") I'm tempted to just define DOMStringList in the IDB spec so it does have a definition, and add a note to implementers encouraging experimenting with returning real arrays with contains() added.

Given that this is shipping in all major browsers and the usage remains high, pretending it doesn't exist in lieu of a documented, shipping alternative is not helpful.

(But I don't want to discourage anyone from pursuing FrozenArrayWithContains<> on the spec/impl/experiment front, it's just non-trivial and not a priority for me)

[inexorabletash]

We can rip it out, but as a straw man I added a definition. I'll keep this issue open, though.

[inexorabletash]

And to @beidson's question in #128 - no new usages in 2.0.

[zcorpan]

In httparchive:

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(body, r'\.\s*(objectStore|index)Names\s*\.\s*contains\s*\(') AS match
FROM [httparchive:har.2016_11_01_chrome_requests_bodies]
) WHERE match != "null"

3,558 rows. All of the matches are objectStore.

GitHub search:

https://github.com/search?l=JavaScript&q="objectStoreNames.contains"+NOT+test&ref=searchresults&type=Code&utf8=✓
3,200 results.

https://github.com/search?l=JavaScript&q="indexNames.contains"+NOT+test&ref=searchresults&type=Code&utf8=✓
798 results.

[annevk]

whatwg/html#2192 moves DOMStringList into HTML.

[inexorabletash]

... and it's landed, so this turns into "Remove DOMStringList definition from IndexedDB"

[inexorabletash]

#136