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
<rdar://problem/51486522>
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.
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
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.
(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
I am not able to reproduce this bug in Safari 17.2.1 (Private Window). @Karl - is it reproducible for you?
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.
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.
(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. :-(
(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!
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