Bug 198609 – WebKit doesn't resize SVG element in response to viewBox change (with height specified and width unspecified)

• Component: SVG
• Status: RESOLVED FIXED

[Daniel Holbert]

STR:
1. Load https://jsfiddle.net/g75rmhz6/
2. Click the button

EXPECTED RESULTS:
The bordered SVG element should shrink to 100x100, so that only green is visible inside of it (no red).

ACTUAL RESULTS:
The bordered SVG element stays the same size. Its contents move around, but its size doesn't change to account for its new aspect ratio (from which its rendered width was derived in the first place).  Red is still visible.


Note: if I open Safari's devtools, then that triggers a relayout and fixes the rendering.

I'm testing with Safari 12 on Mojave.
Chrome version of this bug (Chrome is also affected): https://bugs.chromium.org/p/chromium/issues/detail?id=971647

Firefox has a broader version of the same bug (tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1556511 ), but I'm landing a patch for it, which includes a WPT test (tentatively called "svg/coordinate-systems/outer-svg-intrinsic-size-001.html"), and Chrome & probably-Safari currently fails the last chunk of that WPT test due to this bug

[Radar WebKit Bug Importer]

<rdar://problem/51486522>

[Said Abou-Hallawa]

When dynamically changing the viewBox attribute of the <svg> element, RenderSVGRoot::layout() calls updateLogicalWidth() and updateLogicalHeight(). The current values of RenderBox::m_frameRect, RenderBox::m_minPreferredLogicalWidth and RenderBox::m_maxPreferredLogicalWidth, which were calculated with the previous viewBox value, affect the calculation of the new width and height. If the values of these members are set to their initial values in this case, the bug is fixed.

[Ahmad Saleem]

I am able to reproduce this bug in Safari 15.5 / Safari Technical Preview 148 on macOS 12.4 using JSFiddle mentioned in Description.

It is only failure currently for Safari in below WPT test suite:

https://wpt.fyi/results/svg/coordinate-systems/outer-svg-intrinsic-size-001.html?label=master&label=experimental&aligned

[Ahmad Saleem]

It did fix by adding below:

setNeedsLayoutIfNeededAfterIntrinsicSizeChange();

^ After below line of code:

https://github.com/WebKit/WebKit/blob/e17c2153ab908a5821a2b72ee9fe7856b98aac12/Source/WebCore/rendering/svg/LegacyRenderSVGRoot.cpp#L179

^ It will fix in Legacy SVG Engine.

_____________________

For LBSE, it is here:

https://github.com/WebKit/WebKit/blob/e17c2153ab908a5821a2b72ee9fe7856b98aac12/Source/WebCore/rendering/svg/RenderSVGRoot.cpp#L194

_____________

It fixed this testcase from Comment 0 and also WPT testcase.

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #4)
> It did fix by adding below:
> 
> setNeedsLayoutIfNeededAfterIntrinsicSizeChange();
> 
> ^ After below line of code:
> 
> https://github.com/WebKit/WebKit/blob/
> e17c2153ab908a5821a2b72ee9fe7856b98aac12/Source/WebCore/rendering/svg/
> LegacyRenderSVGRoot.cpp#L179
> 
> ^ It will fix in Legacy SVG Engine.
> 
> _____________________
> 
> For LBSE, it is here:
> 
> https://github.com/WebKit/WebKit/blob/
> e17c2153ab908a5821a2b72ee9fe7856b98aac12/Source/WebCore/rendering/svg/
> RenderSVGRoot.cpp#L194
> 
> _____________
> 
> It fixed this testcase from Comment 0 and also WPT testcase.

PR https://github.com/WebKit/WebKit/pull/14145

[Ahmad Saleem]

I am not able to reproduce this bug in Safari 17.2.1 (Private Window).

@Karl - is it reproducible for you?

[Karl Dubost]

Created attachment 469214 [details]
rendering in safari, firefox, chrome

I can reproduce the issue in STP 184,
but not in Firefox Nightly and Chrome Canary.

[Daniel Holbert]

For what it's worth, 17.2.1 looks good to me too, like Ahmad.

I can still repro in Safari 17.0 (tested via BrowserStack) 
I can *not* reproduce in Safari 17.2.1 (tested locally).  i.e. 17.2.1 gives me expected-results, no red after I click the button.

I don't have DevTools open, either. (As noted in comment 0, DevTools causes the bug to not manifest.)

I don't have STP handy to test. Not sure if Karl's observation here means this regressed there, or if something else is going on.

[Ahmad Saleem]

(In reply to Karl Dubost from comment #7)
> Created attachment 469214 [details]
> rendering in safari, firefox, chrome
> 
> I can reproduce the issue in STP 184,
> but not in Firefox Nightly and Chrome Canary.

Thanks mate! Yes - it is reproducible for me in STP185 as well.

So it regressed again or somehow not reproducible on Safari 17.2.1. :-(

[Ahmad Saleem]

(In reply to Daniel Holbert from comment #8)
> For what it's worth, 17.2.1 looks good to me too, like Ahmad.
> 
> I can still repro in Safari 17.0 (tested via BrowserStack) 
> I can *not* reproduce in Safari 17.2.1 (tested locally).  i.e. 17.2.1 gives
> me expected-results, no red after I click the button.
> 
> I don't have DevTools open, either. (As noted in comment 0, DevTools causes
> the bug to not manifest.)
> 
> I don't have STP handy to test. Not sure if Karl's observation here means
> this regressed there, or if something else is going on.

Thanks @Daniel for confirming. Appreciate it!

[Karl Dubost]

oh it's weirder.

1. Load the testcase https://jsfiddle.net/g75rmhz6/
2. Click on the button, it adjusts as a white, green, red area same length
3. put the computer to sleep
4. Screen goes black
5. Reactivate the screen

Result:
This time the green square has the right size 0_0

[Ahmad Saleem]

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

[EWS]

Committed 298321@main (89c1b8e055c7): <https://commits.webkit.org/298321@main>

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