Bug 199236 – Safari is not scaling SVGs with Command+/- zoom when font-size: is used

• Component: SVG
• Status: REOPENED

[Tom]

I've found that SVGs don't scale in Safari the way they do in the other modern browsers when font-size is specified. It's as if Safari treats font-size on SVGs as an absolute size that cannot be changed. Other browsers don't behave this way, so I assume it's a bug? 

Where this becomes a big problem is with things like Font Awesome, which now offers SVG instead of fonts for it's icon sets. 

Here is a demonstration: https://jsfiddle.net/winzig/3k6x91ha/1/

If you use Command+ and Command- to zoom in and out, the text scales as appropriate, the third home icon does as well (an SVG without font-size set) but the first two SVG icons don't scale no matter what. If you load the same page in Chrome/Firefox/Edge, it works as expected. 

I opened a bug report with Apple a while back (October) that is now in the new feedback system as FB5992037.

[Tom]

Note: I've seen this issue on Safari 11, 12 and the latest technology preview.

[Radar WebKit Bug Importer]

<rdar://problem/52471025>

[Dean Jackson]

It seems that RenderBox::computeReplacedLogicalHeightUsing gets a logical height that reflects the inherited font-size, not the one calculated after applying the page zoom.

[Dean Jackson]

StyleBoxData has different values for m_height in the element with font-size inherit vs nothing.

[Dean Jackson]

When we're calculating the font-size, we go through BuilderState::setFontSize, which looks at useSVGZoomRules()

// SVG handles zooming in a different way compared to CSS. The whole document is scaled instead
// of each individual length value in the render style / tree. CSSPrimitiveValue::computeLength*()
// multiplies each resolved length with the zoom multiplier - so for SVG we need to disable that.
// Though all CSS values that can be applied to outermost <svg> elements (width/height/border/padding...)
// need to respect the scaling. RenderBox (the parent class of RenderSVGRoot) grabs values like
// width/height/border/padding/... from the RenderStyle -> for SVG these values would never scale,
// if we'd pass a 1.0 zoom factor everyhwere. So we only pass a zoom factor of 1.0 for specific
// properties that are NOT allowed to scale within a zoomed SVG document (letter/word-spacing/font-size).
bool BuilderState::useSVGZoomRules() const
{
    return is<SVGElement>(element());
}

[Tom]

Still happening in Safari 14...

This is still happening in Safari 16.4

A workaround is to wrap the <svg> in a <span> and apply the font-size style to the span and the width/height 1em style to the svg.

[Fujii Hironori]

Created attachment 472399 [details]
test case

[Fujii Hironori]

Created attachment 472400 [details]
WIP patch

[Fujii Hironori]

Pull request: https://github.com/WebKit/WebKit/pull/33020

[Fujii Hironori]

Created attachment 472402 [details]
test of foreignObject

[Fujii Hironori]

Created attachment 472690 [details]
PerformanceTestsResults (Needs to adjust localPath)

This is a result of "run-perf-tests --release --repeat=3".

base:    daf9470
patched: 9294b29

There is no performance regressions.

[EWS]

Committed 284310@main (4e612c4d529b): <https://commits.webkit.org/284310@main>

Reviewed commits have been landed. Closing PR #33020 and removing active labels.

[Fujii Hironori]

*** Bug 279041 has been marked as a duplicate of this bug. ***

[WebKit Commit Bot]

Re-opened since this is blocked by bug 283990

[Tom]

What's the status of this issue in terms of getting the fix shipped? 

Back in September it appears that the commit landed, but then December 3 it says it was re-opened due to 283990 blocked it, but that bug appears to be closed/resolved now, so what is holding this patch up? Thanks!

[Fujii Hironori]

Yes, 287302@main reverted the fix. No one is actively working on this bug.