997 bytes, application/vnd.mozilla.xul+xml
719 bytes, application/vnd.mozilla.xul+xml
722 bytes, application/vnd.mozilla.xul+xml
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2) Gecko/20070206 GranParadiso/3.0a2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2) Gecko/2007020617 GranParadiso/3.0a2 When a "Canvas" element with "-moz-box-flex: 1" style is placed inside a XUL "box", and the new box width is smaller than the Canvas width, the width of the box will be forced to be the same as the width of the Canvas. A similar problem existed previous versions, but setting the "max-width" and the "max-height" properties solved the problem, but not in this new version. Reproducible: Always Steps to Reproduce: I'll be attaching 3 test cases: one with a canvas element, one with a xul box and one with a HTML image. Open the XUL page and hit the "Shrink" button. Actual Results: In the case that the nested element is a canvas element, pressing the "Shrink" button will only change the box's height, and leaves the width untouched, deforming the rendered image. Expected Results: It should work like the XUL and HTML image case: the rendered image should keep it's aspect ratio. This test should be performed on Firefox 3 alpha 2 with default theme, since it uses the chrome://browser/skin/monitor.png image for test purposes. Change that URL reference to one for an existing image if you want to try it in a different theme or version. Oversized canvas in a XUL box is an important feature for my extension (Firefox Showcase), since it's a useful way to avoid repeated thumbnail repaints.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9? → blocking1.9+
Whoops, sorry; I misunderstood the bug. I'm not sure how the box-block interaction looks like there, it's entirely possible something was missed.
Flags: blocking1.9+ → blocking1.9-
Did this work correctly in Firefox 2?
> Did this work correctly in Firefox 2? In Firefox 2, it was height that failed to adapt under normal circumstances. However, forcing a maximum height through CSS or XUL attribute on the parent box did the trick. It would make sense that the layout works like the image, right?
One piece of information that may be helpful: if the size is forced by CSS on the canvas that is inside the XUL box, the box will get the right size, but not the canvas (the box right side will be under the canvas), which width will be still the same as the "internal width".
Today I tested Firefox 3 Alpha 6, and the behavior of this bug has changed. This can be easily verified with the tests I uploaded: - "Test (that fails) for Canvas element": The Canvas now fails by both sides, horizontal and vertical, so clicking the button has no effect. - "Test (works) with a xul image element": No change, works as it should. - "Test (works) with a HTML image element": It worked, but now it fails to adapt the height of the image.
Summary: Canvas fails to adapt it's width to a parent XUL box → Canvas fails to adapt its width to a parent XUL box
It's not clear what part Canvas has to play in the sizing; let's put this in layout and see what happens.
Component: Canvas: 2D → Layout
QA Contact: canvas.2d → layout
You need to log in before you can comment on or make changes to this bug.