transaction should either take DOMStringList or DOMStringList needs to be iterable

[rniwa]

transaction method on IDBDatabase takes a DOMString or a sequence<DOMString> but DOMStringList is not iterable.

The consequence of this is that, you can’t call transaction() with the return value of objectStoreNames method. This is not Web incompatible as far as I know.

[inexorabletash]

In the past I think this was covered by WebIDL accepting anything with length and indexed properties for sequence arguments, which DOMStringList satisfied. I believe that changed?

Anyway, @rniwa is correct about the use case and I think Blink even has tests for this. (I'm on my phone at the moment.) so we should fix in spec-land somehow, either making DOMStringList iterable or changing the method.

[inexorabletash]

@aliams, @wanderview - do you have a preference between:

• Make DOMStringList have iterable<DOMString>; or
• Make transaction()'s signature be transaction((DOMString or sequence<DOMString> or DOMStringList) and add logic for DOMStringList in the method algorithm

The former is more consistent with other platform types and with our eventual hope to replace it with FrozenArrayWithContains<DOMString> (or whatever), but does add more to a deprecated type.

The latter is a more scoped change.

I'm pretty sure Blink internally still checks for length and indexed properties, as previously specified in WebIDL, but either approach is likely to be web-compatible.

[inexorabletash]

@beidson too - same question as previous comment.

[aliams]

Considering the goal to eventually remove DOMStringList, I'd say we should go with option 1 so that we're not adding extra logic to handle DOMStringList that will just need to be removed later. I'm not as worried about making DOMStringList iterable because it will get us one step closer to how developers will use a FrozenArray.

[inexorabletash]

FYI @domenic @annevk

[annevk]

Yeah, making DOMStringList iterable seems like the way to go, even if we have to keep it.

[annevk]

My preference would be to fix this as a follow-up commit to whatwg/html#2192 with corresponding WPT changes.

[inexorabletash]

sgtm.

I have a blink CL I haven't landed because I didn't want to have the "it's a deprecated API we're trying to remove, why are we adding to it?" fight.

[inexorabletash]

Spec-wise, we should decide on what to "domintro" for iterable<>. I notice that DOMTokenList's docs don't mention the methods that get bolted on.

[annevk]

Hmm good point. domintro should probably mention all. I wonder if we can get some domintro automation into bikeshed to make things a little less tedious.

[inexorabletash]

Turns out this is moot. Per WebIDL

If the interface has any of the following:

• ...
• an indexed property getter and an integer-typed attribute named “length”
• ...

then a property must exist whose name is the @@iterator symbol...

TIL Blink and Gecko already implement this. Wheee!

Blink tosses DOMStringList into the union but that's an implementation detail - the spec is fine.

[annevk]

I think adding iterable<> might still be worth it, especially if user agents have codegen for it, but not really a priority.

[inexorabletash]

Agreed. I have a local patch for Blink; if it appeared in the spec I'd go through our "intent" process to ship it, but not a priority to push for it.