369891 - Canvas fails to adapt its width to a parent XUL box

Status: NEW

(Core :: Layout, defect, P3)

Description

[Josep del Rio]

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.

Comment 1

[Josep del Rio]

Attachment: Test (that fails) for Canvas element

Comment 2

[Josep del Rio]

Attachment: Test (works) with a xul image element

Comment 3

[Josep del Rio]

Attachment: Test (works) with a HTML image element

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did this work correctly in Firefox 2?

Comment 6

[Josep del Rio]

> 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?

Comment 7

[Josep del Rio]

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".

Comment 8

[Josep del Rio]

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.

Comment 9

[Joe Drew (not getting mail)]

It's not clear what part Canvas has to play in the sizing; let's put this in layout and see what happens.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information