Bug 44980
| Summary: | setAttribute() followed by getAttribute() on select.size does not return the same thing | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Aryeh Gregor <ayg> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Minor | CC: | ahmad.saleem792, ap, bfulgham, jkjiang, rniwa, tabatkins |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Aryeh Gregor
Test case:
<!doctype html>
<script>
var el = document.createElement("select");
el.setAttribute("size", "-2147483649");
alert(el.getAttribute("size"));
</script>
Safari 5 on XP and Chrome dev on Ubuntu both alert "0". Firefox nightly, IE8, and Opera 10.60 all alert "foo". The WebKit behavior is not expected.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Is this the right test case? I don't see where "foo" could come from.
Aryeh Gregor
Sorry, my bad:
<!doctype html>
<script>
var el = document.createElement("select");
el.setAttribute("size", "foo");
alert(el.getAttribute("size"));
</script>
My original test case set it to a number because it was testing something else, but in the context of the bug I thought it was clearer to set it to "foo" so it was clearly not number-related. Except I forgot to update the posted test-case. :)
Jacky Jiang
This should be an invalid bug? Seems we shouldn't set the size of the select element to string. As the HTML 5 specification shows :
The size attribute gives the number of options to show to the user. The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero. If the multiple attribute is present, then the size attribute's default value is 4. If the multiple attribute is absent, then the size attribute's default value is 1.
http://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#attr-select-size
4.10.9 The select element
Not sure how Firefox can show the string value which seem isn't correct according to the specification.
Tab Atkins
(In reply to comment #3)
> This should be an invalid bug? Seems we shouldn't set the size of the select element to string. As the HTML 5 specification shows :
> The size attribute gives the number of options to show to the user. The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero. If the multiple attribute is present, then the size attribute's default value is 4. If the multiple attribute is absent, then the size attribute's default value is 1.
> http://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#attr-select-size
> 4.10.9 The select element
> Not sure how Firefox can show the string value which seem isn't correct according to the specification.
I think I agree. That text requires the attribute value to be parsed as a number, which should return 0 if passed "foo". As well, the IDL attribute is defined as an unsigned long, so it shouldn't be capable of storing a string.
Alexey Proskuryakov
> The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero.
This is a document conformance requirement, not an engine one. Nothing should prevent setting content attributes with setAttribute (and indeed, even setAttribute("multiple", "foo") works in WebKit).
Tangentially related, current spec text is different from what is quoted in comment 3. The IDL attribute's value no longer magically changes to 1 or 4 depending on whether "multiple" is set.
Tab Atkins
(In reply to comment #5)
> > The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero.
>
> This is a document conformance requirement, not an engine one. Nothing should prevent setting content attributes with setAttribute (and indeed, even setAttribute("multiple", "foo") works in WebKit).
Oh, whoops, indeed. I had missed that the value gotten back out was from the attribute, not the property.
In that case, yes, we should be returning "foo". It's an authoring error to set such a value, but nothing wrong on our part. We just parse it as an integer when mirroring it into the size property.
> Tangentially related, current spec text is different from what is quoted in comment 3. The IDL attribute's value no longer magically changes to 1 or 4 depending on whether "multiple" is set.
Yes, always read the WHATWG version of the spec, as it's more up-to-date: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-select-size
Ahmad Saleem
I took test case from Comment 02 and changed it into JSFiddle:
Link - https://jsfiddle.net/rzqtv14w/show
All browsers (Safari 15.6, Chrome Canary 106 and Firefox Nightly 105) are returning "foo" as dialog - isn't it what was expected output from Comment 0. I think this was fixed along the way and can be marked as "RESOLVED FIXED". Thanks!
Ryosuke Niwa
Oh, this test needs to be done with the specific value: -2147483649. All browsers return this value -> config changed.