1811683 - SVG images in <a> tags does not render.

Status: NEW

(Core :: SVG, defect)

Description

[umitseyhan]

Attachment: firefox_UmTW3EXZB0.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. Go to my hobby project website's contact section: https://umitseyhan75.github.io/website-deneme/#contact
2. Check with chromium based browser again and see that they are there.

Actual results:

Contact links did not rendered.

Expected results:

Contact links should've been rendered.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b6d4cc392199eac68b7641fe6ce2be73a84381f6&tochange=76c1fb5130dcd9f4562826d42194ebf74ca268c8

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:TYLin, since you are the author of the regressor, bug 1340715, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Ümit, thanks for the bug report!

I am able to reproduce this on Firefox Nightly (2023-01-21). The <svg> element has width="fit-content". It doesn't render because Firefox currently calculates its intrinsic width as 0. You might find width="100%" useful to match chromium's behavior until we find a proper way to fix this bug in Firefox.

Comment 4

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Reduced testcase

Comment 5

[umitseyhan]

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #3)

Ümit, thanks for the bug report!

I am able to reproduce this on Firefox Nightly (2023-01-21). The <svg> element has width="fit-content". It doesn't render because Firefox currently calculates its intrinsic width as 0. You might find width="100%" useful to match chromium's behavior until we find a proper way to fix this bug in Firefox.

I can not remember exactly which version but this bug was not here all the time, it must be somewhere around version 103 of Firefox these svgs started to rendered as 0x0 (width x height) with fit-content value.

Comment 6

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

According to the regression range discovered by Alice0775 in comment 1, this bug is introduced in Firefox 106. Assigning this to myself to take a look.

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1811683 - Make preferred isize of SVG with fit-content value fall back to fallback intrinsic size.

This makes Firefox behave like Google Chrome.

Comment 8

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Screenshot on Chrome 112 on reduced testcase

This is a screenshot from Chrome 112 on the reduced testcase in comment 4. From the Styles Panel, it looks like Chrome ignores width="fit-content", and treat it as width="100%.

In Firefox's devtools console, there is also a warning message: Unexpected value fit-content parsing width attribute.

From the SVG2 spec 7.8. Sizing properties, it says that

See the CSS 2.1 specification for the definitions of width and height.

That is: there is no fit-content, max-content, min-content values in width or height properties in the CSS 2.1 spec.

I wonder if Firefox incorrectly honors width="fit-content" on SVG element? That is, do we parse SVG width and height attributes via the same function as CSS width and height properties?

Comment 9

[Robert Longson [:longsonr]]

On an outer SVG element we map width and height attributes to styles so yes they are parsed as CSS and this is intended.

Comment 10

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Testcase for SVG intrinsic-size keywords

There is no interop between Firefox (version 112, 2023-02-23), Google Chrome canary (version 112), and Safari Release 164 (Safari 16.4, WebKit 18616.1.2). There is no single subtest that three engines render the same way.

Comment 11

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

The reporter's testcase was changed by bug 1340715, but before the bug there's still no interop between browsers. Per comment 9, we are consistent for SVG width set from attribute and style, but Google Chrome is not on cases where parent has width:max-content. I don't feel it is reasonable to change to their behavior.

Given above, I don't see a clear way to moving forward, so I'll stop for now.

For authors, the best way to ensure the consistent size between browsers is to use fixed size or percentages for width and height on SVG elements.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #10)

Created attachment 9319526 [details]
[ ...] There is no single subtest that three engines render the same way.

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #11)

Given above, I don't see a clear way to moving forward, so I'll stop for now.

Yeah, I do see Blink/Gecko/WebKit being all substantially different on the original testcase as well as your broader testcase, so there does seem to be a distinct lack-of-interop here.

Maybe worth filing an issue for discussion with the csswg -- would you mind summing up your findings and relevant spec text in an issue there? (Does the spec seem to point to any particular browser as being consistently correct here?)