Those attributes are declared as long instead of unsigned long in the IDL and the reflection isn't correct.
Created attachment 488745 [details] [diff] [review] Patch v1 Should we push that in Gecko 2.0 even if it changes the IDL?
Unless there's something not listed in the bug, I don't think this is worth breaking API freeze for. I know that several binary extensions use nsIDOMHTMLCanvasElement.
(In reply to comment #2) > Unless there's something not listed in the bug, I don't think this is worth > breaking API freeze for. I know that several binary extensions use > nsIDOMHTMLCanvasElement. We might be one of the last "modern browsers" to have canvas.width and canvas.height to not default correctly and we are failing some tests in HTML5 Test Suite because of that. But I agree I do not see a reason big enough to break compatibility. In another hand, I really don't see how moving from long to unsigned long might break something (it would be insane to set a negative value to a width or a height).
I figured we'd never actually get negative values, so that's not my concern. We're already past API-freeze for Firefox 4, which means that IDL changes are not allowed except by very special exception.
Comment on attachment 488745 [details] [diff] [review] Patch v1 r=jst, but yeah, let's land this after branching.
Surely you need changes to test_canvas.html too?
Is this something to consider for Firefox 5?
Updated documentation: https://developer.mozilla.org/en/HTML/Element/canvas And mentioned on Firefox 5 for developers.