Closed Bug 586118 Opened 14 years ago Closed 14 years ago

Unsigned longs for reflected attributes do not treat out-of-range values correctly

Categories

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

x86
Linux
defect
Not set
minor

Tracking

()

RESOLVED INVALID

People

(Reporter: ayg, Unassigned)

References

Details

(Keywords: html5)

Tested in Firefox 4.0b2.  According to HTML5,

"""
If a reflecting IDL attribute is an unsigned integer type (unsigned long) then, on getting, the content attribute must be parsed according to the rules for parsing non-negative integers, and if that is successful, and the value is in the range of the IDL attribute's type, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or 0 if there is no default value.
"""
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflecting-content-attributes-in-idl-attributes

According to WebIDL,

"The unsigned long type is an unsigned integer type that has values in the range [0, 4294967295]."
http://dev.w3.org/2006/webapi/WebIDL/#idl-unsigned-long

HTML5 defines (for instance) input.size as an unsigned long.  From the above, I would expect the following to alert 3000000000:

data:text/html,<!doctype html>
<input size=3000000000>
<script>
alert(document.getElementsByTagName("input")[0].size);
</script>

However, it alerts 0.  WebKit also alerts 0; Opera alerts 2147483647.
Summary: Unsigned longs in IDLs do not treat out-of-range values correctly (WebIDL) → Unsigned longs in IDLs do not treat out-of-range values correctly
> HTML5 defines (for instance) input.size as an unsigned long.

We store all integer-reflecting attributes as signed 32-bit integers.  Hence the observed behavior; 3000000000 parses as a negative 32-bit integer due to overflow and gets clamped to 0.

If you had a number that was actually out of range of unsigned 32-bit integers, you would get other odd behavior, obviously.

I'm not entirely sure how much we want to support this, actually; it would require a significant rework of attribute storage (and some slowdown or extra memory usage) for what seems like not much benefit.  Should see what other implementors think.
Severity: normal → minor
Keywords: html5
Summary: Unsigned longs in IDLs do not treat out-of-range values correctly → Unsigned longs for reflected attributes do not treat out-of-range values correctly
Version: Other Branch → Trunk
Based on the test-case I gave, it seems like no browser is actually able to store values bigger than a signed int can hold here.  Safari 5 alerts 0 as well as Chrome dev, IE8 alerts 2147483647.  Given that, it looks like WebIDL should redefine unsigned long to have a range of [0, 2147483647], and maybe similar changes for related attributes.  Do you agree?  Should the ranges of anything else in WebIDL change as well?
Unsigned long is used for things other than stuff that maps content attributes, no?
Hmm, guess so.  So instead, should there be a note in HTML5 saying that unsigned longs have to treat anything above 2147483647 as out of range?
I have no idea.  What problem are you trying to solve?
I'm trying to solve the problem that the spec doesn't match the implementations.  Everyone says we want tests for HTML5, so I picked something at random (reflection) and am writing some tests: <http://aryeh.name/tests/reflection.html>.  When tests fail, I try to figure out if it's a spec bug or implementation bug, and file accordingly.  Since this now seems like a spec bug, I should probably file there, but since we were already discussing it, I thought I should ask your opinion on what change is needed, since you'd know better than me.

Actually, in this case I should have realized that all browsers fail this test and filed a spec bug rather than browser bug to start with, as I did in several other cases.  Don't know why I didn't.  I've now filed <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10352>.  I assume that in cases where all other browsers do match the spec and Gecko doesn't, I should continue to file bugs against Gecko, even if they're minor.
Yes, of course.

Even if browsers all don't match the spec, for corner cases like this it might be worth changing the browsers, maybe.  Worth bringing up on the mailing list on a case by case basis...  Sometimes the change is easy; sometimes not.
Spec bug <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10352> was fixed, and now matches Gecko's behavior as far as I can tell.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.