Closed Bug 1521882 Opened 5 years ago Closed 2 years ago

SVG without width/height specified has different intrinsic-sizing behavior in Chrome vs Firefox (e.g. in a float or in flexbox)

Categories

(Core :: Layout, enhancement, P3)

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1340715
Webcompat Priority revisit
Tracking Status
firefox66 --- affected

People

(Reporter: twisniewski, Unassigned)

References

Details

(Keywords: parity-chrome, Whiteboard: [webcompat][layout:backlog])

Attachments

(2 files)

Attached file testcase 1

In the attached testcase, Chrome will size the SVG to the width of the text below it, while Firefox seems to fit it to the window's width. This can cause SVG icons in flex layouts to be huge in Firefox, as seen in a PayPal page in https://webcompat.com/issues/24694

Flags: webcompat?
Keywords: parity-chrome
Summary: SVG in a without width/height specified in a flexbox behaves differently in Chrome and Firefox → SVG without width/height specified in a flexbox behaves differently in Chrome and Firefox

This isn't really flex-dependent -- it's just a question of what the max-content width of the SVG content is here.

One way to find that out is to use flexbox; another way is to wrap it in a float, as I've done here. (And this version shows the rendering difference as well.)

Attachment #9038313 - Attachment description: test.html → testcase 1
Component: Layout: Flexbox → Layout
Summary: SVG without width/height specified in a flexbox behaves differently in Chrome and Firefox → SVG without width/height specified has different intrinsic-sizing behaviorin Chrome vs Firefox (e.g. in a float or in flexbox)
Summary: SVG without width/height specified has different intrinsic-sizing behaviorin Chrome vs Firefox (e.g. in a float or in flexbox) → SVG without width/height specified has different intrinsic-sizing behavior in Chrome vs Firefox (e.g. in a float or in flexbox)
Priority: -- → P3

Blink is probably not taking the SVG into consideration when calculating intrinsic size for an unsized SVG, which is probably the right behavior.

Actually our behavior is more buggy than that. If you add a width property via style editor then remove it, the box can be in arbitrary size.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Assignee: nobody → miket
Webcompat Priority: ? → ---
Flags: webcompat?
See Also: → 1607081
Assignee: miketaylr+bz → nobody
Webcompat Priority: --- → P2
Whiteboard: [webcompat] → [webcompat][layout:backlog]

While investigating this, I found some related bugs.

Bug 1340715 is about SVGOuterSVGFrame::GetPrefISize may depend on previous layout results, which resonates with comment 2.

dholbert wrote a bunch of tests for SVG having intrinsic ratio but no intrinsic size in bug 1638937, which may be helpful while fixing SVG's intrinsic size.

See Also: → 1638937, 1340715

Another instance of this https://webcompat.com/issues/67325
on the CBS website.

See Also: → 1732780
See Also: → 1651754
See Also: → 1688968
Webcompat Priority: P2 → revisit

I think this may be a dupe of bug 1651754 (or vice-versa).

With the patch in Bug 1340715, Firefox now behaves like Chrome for SVG without width/height specified.

I didn't check all the webcompat reports, but at least both testcase 1 & 2 and https://webcompat.com/issues/109334 looks good on 106.0a1 (2022-09-01).

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Blocks: 1835343
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: