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]
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
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]
r=jst, but yeah, let's land this after branching.
*** Bug 622783 has been marked as a duplicate of this bug. ***
Surely you need changes to test_canvas.html too?
Is this something to consider for Firefox 5?
And mentioned on Firefox 5 for developers.
*** Bug 581225 has been marked as a duplicate of this bug. ***