Closed Bug 1290283 Opened 8 years ago Closed 8 years ago

Setting input.maxLength to an invalid string should throw, not just set maxLength to 0.

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: wisniewskit, Assigned: wisniewskit)

References

Details

Right now, setting an input/textarea's maxLength to a non-integer string does not throw an exception, it simply sets maxLength to 0. This seems to be because the WebIDL bindings process the value with ValueToPrimitive<uint64_t>, which returns 0 for invalid strings well before they're sent to SetMaxLength where a check is made on whether to throw an exception.

However, Chrome throws in this case, and the spec seems to imply that JS type coercion should not be a part of this process. Indeed, the minLength/maxLength web platform tests expect that setting maxLength to "" should result in it not being set, rather than being set to 0 (also that test is only currently passing by fluke right now, because UpdateTooLongValidityState isn't actually doing anything).

However, I'm not 100% sure what the correct thing to do here is. It would be simple enough to change maxLength into a DOMString in the WebIDL, and then work from there (as we're doing for other properties like min/max), but perhaps this implies that the generated binding code is causing other such bugs, and should be tweaked instead?
Flags: needinfo?(bzbarsky)
Actually, disregard... I was running into a different exception in Chrome then I thought I was. Upon further examination, Chrome and Edge also set the maxLength to 0 when it's set to a non-integer string, so this is not a compat issue.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(bzbarsky)
Resolution: --- → INVALID
For what it's worth, this is all per spec.  The HTML spec's IDL for textarea has:

   attribute long maxLength;

On assignment of a JS value to this attribute, the IDL spec says to do http://heycam.github.io/webidl/#es-to-long which will convert "" to 0.  This will then pass the "number must be non-negative" check in the maxLength setter and there will be no exception.

The generated binding code is just implementing what the IDL spec says to do; that's its goal.  ;)
You need to log in before you can comment on or make changes to this bug.