980563 - Align DOMStringList and FileList more with Array

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We're hoping to deprecate both DOMStringList and FileList and replace them with normal JS Arrays (possibly frozen ones).

As a first step to this it would be great to do the following:

* Remove the .item function from both DOMStringList and FileList
  Does our webidl implementation allow name-less getters? We still want
  mylist[5] to work, but not mylist.item(5).
* Add .has() as an alias for .contains(). And possibly add a warning whenever
  .contains() is used.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Does our webidl implementation allow name-less getters?

Yes.

Can we just nuke contains?  Do other UAs implement it?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

.contains() appears to be implemented in Webkit/Blink

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/DOMStringList.idl&q=DOMStringList.idl&sq=package:^chromium$%20file:^src/third_party/WebKit/Source/core/

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, and which APIs do they use DOMStringList in?

Comment 4

[(no longer active)]

(In reply to comment #3)
> OK, and which APIs do they use DOMStringList in?

$ git grep DOMStringList | grep \.idl
Source/bindings/tests/idls/TestObject.idl:247:    [RaisesException] DOMStringList domStringListFunction(DOMStringList values);
Source/core/core.gypi:60:            'dom/DOMStringList.idl',
Source/core/dom/DOMStringList.idl:27:] interface DOMStringList {
Source/core/frame/Location.idl:54:    readonly attribute DOMStringList ancestorOrigins;
Source/modules/indexeddb/IDBDatabase.idl:32:    readonly attribute DOMStringList objectStoreNames;
Source/modules/indexeddb/IDBDatabase.idl:41:    [CallWith=ExecutionContext, RaisesException] IDBTransaction transaction(DOMStringList storeNames, [Default=NullString] optional DOMString mode);
Source/modules/indexeddb/IDBObjectStore.idl:30:    readonly attribute DOMStringList indexNames;

That is, Location.ancestorOrigins, IDBDatabase.objectStoreNames, as the first argument to IDBDatabase.transaction, and IDBObjectStore.indexNames.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  Location.ancestorOrigins is only implemented in Chrome, afaik, and is very new.  So changing that to return an ES array or just removing contains() from it would not be a problem compat-wise.

IDBDatabase.objectStoreNames and IDBObjectStore.indexNames we also implement as DOMStringList.  Do people depend on using contains() there?  Jonas has been talking about switching those to arrays, so I assumed that wasn't an issue.

The argument use case certainly doesn't depend on contains() (and for us it's a sequence argument, not a DOMStringList object).

So it seems like we can just remove contains() if the IDB use cases don't depend on it.  It'd be pretty sad if we had to keep DOMStringList around just because of IDB, though.  :(

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I have no idea if people depend on .contains() in IDB. Sadly I had forgotten that DOMStringList has a .contains function, which was why I was hopeful that we could get rid of DOMStringList in favor of Array.

However IDB is fairly new, and the places where DOMStringList is used (as return value) is fairly edge-casey. So I think it's worth a shot to drop/deprecate .contains() there.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, worksforme.  Ms2ger, are you doing this, or should I?

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Doesn't look like it's going to be me.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think we can WONTFIX this as-is. The .contains() function is used on the web and can't be removed. Even on DOMStringLists returned from IDB.

There's quite a lot of usage of .item() on the web. Not sure if that applies to the array-like objects returned from the APIs discussed here, but most likely they are.

If we're to ever be able to replace DOMStringList, FileList or other array-like APIs with actual Arrays, we'll have to return Array subclasses which have an .item() function, and where appropriate a .contains() function.