Closed Bug 586126 Opened 14 years ago Closed 7 years ago

Most unsigned longs in HTML IDLs are implemented as longs

Categories

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

defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: ayg, Unassigned)

References

Details

(Keywords: html5)

For instance, in dom/interfaces/html/nsIDOMHTMLCanvasElement.idl, width and height are long instead of unsigned long:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element

In dom/interfaces/html/nsIDOMHTMLImageElement.idl, hspace and vspace are long instead of unsigned long:

http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#dom-iframe-marginwidth

Etc.  In fact, there are only four attributes total in that whole directory that are unsigned longs in Gecko's IDLs:

$ grep "unsigned long[^)]*;" dom/interfaces/html/*Element.idl
dom/interfaces/html/nsIDOMHTMLInputElement.idl:           attribute unsigned long         size;
dom/interfaces/html/nsIDOMHTMLSelectElement.idl:           attribute unsigned long         length;
dom/interfaces/html/nsIDOMHTMLVideoElement.idl:  readonly attribute unsigned long videoWidth;
dom/interfaces/html/nsIDOMHTMLVideoElement.idl:  readonly attribute unsigned long videoHeight;
> In dom/interfaces/html/nsIDOMHTMLImageElement.idl, hspace and vspace are long
> instead of unsigned long:

Yes, that's what they are in the DOM 2 HTML specification too, which is what the IDL is from.  Is there a reason HTML5 changed that, exactly?  Seems like a gratuitous change to me...
Version: Other Branch → Trunk
Severity: normal → minor
Keywords: html5
I've filed bugs on HTML5 for at least some of those.
For reference:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10345

I put a full list there of all the discrepancies that my tests picked up.  <canvas> height/width is still a Firefox bug, though, right?  Or should that be changed in the spec too?
(In reply to comment #4)
> Canvas is long in WebKit as well:
> <http://trac.webkit.org/browser/trunk/WebCore/html/HTMLCanvasElement.idl>

Test case:

<!doctype html>
<script>
    var el = document.createElement("canvas");
    el.setAttribute("width", "-2");
    alert(el.width);
</script>

IE9PP4 and Safari 5 alert -2, Firefox 4.0b3 alerts 0, Chrome dev and Opera 10.60 alert 300.  The spec agrees with Chrome dev and Opera 10.60.  This is what makes the most sense, since

<!doctype html>
<canvas width=-2></canvas>
<script>
    var context = document.getElementsByTagName("canvas")[0].getContext("2d");
    context.fillStyle = "green";
    context.fillRect(0, 0, 300, 300);
</script>

does actually draw a rectangle in Firefox (as well as Chrome and Opera, but not IE9 or Safari), so the width is effectively 300 and that's what it makes sense to return.  So I think this is a Firefox bug, not a spec bug.
Comment 5 is not really about this bug.
This bug is (or at least was) about long attributes in some .idl files.
That's what comment 5 is about, no?  This .idl file defines canvas width/height as long, when the spec says unsigned long:

http://hg.mozilla.org/mozilla-central/file/4bc4033139c8/dom/interfaces/html/nsIDOMHTMLCanvasElement.idl#l53

Comment 5 is why I think this is a bug in Firefox and not the spec.
The spec bug was closed WONTFIX a few days ago:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10345#c11
OS: Linux → Windows Server 2003
Component: DOM → DOM: Core & HTML
OS: Windows Server 2003 → All
Hardware: x86 → All
Depends on: 610212
Depends on: 630889
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
The duplicate status seems a bit unclear here.
Marking this bug as depending on bug 826738. If bug 826738 fixes it, we will mark this bug as fixed.
Status: RESOLVED → REOPENED
Depends on: 826738
Resolution: DUPLICATE → ---
I'm pretty sure this is fixed now.  Someone can reopen if it's not.
Status: REOPENED → RESOLVED
Closed: 11 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.