1270568 - Percentage-constrained SVG elements in Flexbox containers render at different sizes on repaint

Status: VERIFIED DUPLICATE of bug 1340715

(Core :: Layout, defect)

Description

[nchase]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Steps to reproduce:

See example here: http://codepen.io/nchase/pen/pyqKGd

Here are the steps:

1. Create outermost <div>, set `display: flex;`
2. Create <div> inside
3. Create <div> inside, set `width: 75%` in CSS
4. Create <svg> inside, set `width: 100%` in CSS
5. Set an arbitrary property on the <svg> that will trigger a repaint (in the example above, I set a transparent 1px border on the svg)


Actual results:

If you repeatedly repaint, notice that the SVG gets smaller and smaller (by a factor of whatever the containing element's size is set to – 0.75 in this case) 


Expected results:

The SVG should stay the same size after a repaint

Comment 1

[Loic]

Attachment: 1270568.html

Comment 2

[Loic]

What do I need to do with the testcase?

Comment 3

[nchase]

Hi Loic, if you force a minor repaint (e.g. by adding/removing border), notice that the SVG resizes by a factor equal to the percentage of the outer div whose dimensions are modified. Let me know if there's anything I can add or clarify, will have a computer in a few hours.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: hover & un-hover the SVG

Posting an interactive version of the testcase, which you can try out by hovering the SVG (which temporarily changes the border-width).

[--> obsoleting the previous version, which wasn't directly testable due to having a "//" comment which disabled the CSS that was supposed to be toggleable. This new testcase is based on that one.]

Comment 6

[Daniel Holbert [:dholbert]]

[canceling needinfo, as my attached testcase demonstrates the bug.]

EXPECTED RESULTS: Hovering & un-hovering should restore the original rendering.
ACTUAL RESULTS: Hovering & un-hovering produces a progressively smaller SVG rendering.

Comment 7

[nchase]

I have noticed that this bug still exists in Firefox 57 and is reproducible via the same procedure. Is there any appetite to fix this bug?

Comment 8

[Daniel Holbert [:dholbert]]

This is fixed in Nightly now, I think via bug 1340715.

Comment 9

[Daniel Holbert [:dholbert]]

Confirmed that this was essentially bug 1340715, though we also needed the fix for bug 1790167.

I confirmed that using testcase 1

• Nightly 2022-08-31 is "bad" (SVG initially large, gets progressively smaller as you hover/un-hover)
• On 09-01 early morning, bug 1340715's fix hits mozilla-central.
• Nightly 2022-09-01 (first build w/ that fix) is a new kind of bad - the SVG renders as 0-size, which I think is bug 1790167.
• Nightly 2022-09-11 has that same 0-size bad rendering.
• Then bug 1790167's fix hits mozilla-central.
• Nightly 2022-09-12 and newer render the SVG properly -- at a visible size with no persistent growing or shrinking on hover/unhover cycles.