Closed Bug 586126 Opened 10 years ago Closed 3 years ago
Most unsigned longs in HTML IDLs are implemented as longs
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
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?
Canvas is long in WebKit as well: <http://trac.webkit.org/browser/trunk/WebCore/html/HTMLCanvasElement.idl>
(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").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
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 826738
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: 7 years ago → 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.