Bug 198609 - WebKit doesn't resize SVG element in response to viewBox change (with height specified and width unspecified)
Summary: WebKit doesn't resize SVG element in response to viewBox change (with height ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: Safari 12
Hardware: Unspecified macOS 10.14
: P2 Normal
Assignee: Nobody
URL:
Keywords: FromImplementor, InRadar
Depends on:
Blocks:
 
Reported: 2019-06-06 07:07 PDT by Daniel Holbert
Modified: 2023-12-26 23:41 PST (History)
11 users (show)

See Also:


Attachments
rendering in safari, firefox, chrome (219.71 KB, image/png)
2023-12-26 15:26 PST, Karl Dubost
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Holbert 2019-06-06 07:07:33 PDT
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
Comment 1 Radar WebKit Bug Importer 2019-06-06 09:31:50 PDT
<rdar://problem/51486522>
Comment 2 Said Abou-Hallawa 2019-06-06 11:12:45 PDT
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.
Comment 3 Ahmad Saleem 2022-07-14 13:39:50 PDT
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
Comment 4 Ahmad Saleem 2023-05-20 04:51:43 PDT
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.
Comment 5 Ahmad Saleem 2023-05-20 05:04:37 PDT
(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
Comment 6 Ahmad Saleem 2023-12-26 05:21:27 PST
I am not able to reproduce this bug in Safari 17.2.1 (Private Window).

@Karl - is it reproducible for you?
Comment 7 Karl Dubost 2023-12-26 15:26:15 PST
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.
Comment 8 Daniel Holbert 2023-12-26 15:34:38 PST
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.
Comment 9 Ahmad Saleem 2023-12-26 20:07:46 PST
(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. :-(
Comment 10 Ahmad Saleem 2023-12-26 20:08:04 PST
(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!
Comment 11 Karl Dubost 2023-12-26 23:41:38 PST
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