1218095 - Negative value for count argument for all CharacterData's methods should throw

Status: RESOLVED INVALID

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

Description

[Arkadiusz Michalski (Spirit)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

IDL definition https://dom.spec.whatwg.org/#characterdata:
DOMString substringData(unsigned long offset, unsigned long count);
void deleteData(unsigned long offset, unsigned long count);
void replaceData(unsigned long offset, unsigned long count, DOMString data;

So offset and count have the same type, but I see this behaviour when passing negative value:
- IE11 and Opera(Presto) throw for both (offset and count)
- Firefox and Chrome throw only for offset (but not for count)

I don't see any special distinction between this two arguments in actual DOM's prose, so what is going here? 

BWT, from older specs (DOM2/DOM3) we have this:
INDEX_SIZE_ERR: Raised if the specified offset is negative or greater than the number of 16-bit units in data, or if the specified count is negative.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So the relevant two testcases are:

  document.createTextNode("abc").deleteData(-1, 1)

and

  document.createTextNode("abc").deleteData(0, -1)

Let's walk through these carefully.

For the first one, the argument is unsigned long, -1 is passed for the offset, so the value that comes out on the other side after IDL argument processing ix 0xFFFFFFFF.  This then calls https://dom.spec.whatwg.org/#concept-CD-replace with that offset, 1 for count, and empty string for data.  So offset is 0xFFFFFFFF, length is 3, step 2 of the algorithm throws an exception.

For the second one, we're passing 0 for the offset, and 0xFFFFFFFF for the count.  Step 2 of the algorithm doesn't throw, since 0 < 3.  Step 3 of the algorithm does the equivalent of:

  count = min(count, length - offset)

which in this case sets count to 3.  So in fact the prose handling of too-large offset and count is _quite_ different.  As far as I can tell, Firefox and Chrome are implementing the spec correctly here.

> BWT, from older specs (DOM2/DOM3) we have this:

Ah, yes, DOM2/3, which didn't really define a processing model... But in any case, looking at DOM3 we have deleteData taking unsigned long for both arguments and the prose says to throw if offset is too big, while clamping count to the available length.  The same prose says to throw if either one is negative, as you note, but in practice the processing model browsers implemented coerces the input to "unsigned long" before doing the prose, so they can never be negative.

Comment 2

[Arkadiusz Michalski (Spirit)]

Thx, I missing conversion -1 to 0xFFFFFFFF, so now understand why for example DOMTokenList.item(-1) return null. Boris can you give me some reference to Web IDL where exactly can I read about this conversion (I should focus on binding type or Interface object [[Call]] method)?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Generally the type conversions in IDL are given in subsections of http://heycam.github.io/webidl/#es-type-mapping and in this particular case the relevant bit is <http://heycam.github.io/webidl/#es-unsigned-long>.  There are some rare cases (e.g. assignment to an enum-typed attribute) that don't invoke these algorithms, though....  The right general entrypoint for this case (method call) is http://heycam.github.io/webidl/#es-operations which ends up doing "Let <operation, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm." which ends up finding only one overload and hence skips steps 10 and 11 and 13 and converts all the arguments in step 14, which is what lands us in <http://heycam.github.io/webidl/#es-unsigned-long>.

In any case, per http://heycam.github.io/webidl/#es-unsigned-long since we don't have [EnforceRange] or [Clamp], we do "Set x to ToUint32(x)", which invokes http://people.mozilla.org/~jorendorff/es6-draft.html#sec-touint32 (or <http://www.ecma-international.org/ecma-262/6.0/#sec-touint32> as you prefer), which is what does the conversion of -1 to 0xFFFFFFFF.

Comment 4

[Arkadiusz Michalski (Spirit)]

Wielkie dzięki za tak dokładne wyjaśnienie, teraz wszystko jest bardziej zrozumiałe.

Comment 5

[Arkadiusz Michalski (Spirit)]

Upsss... english please:
Big thanks for being so thorough explanation, now everything is more understandable.