Created attachment 470110 [details] minimal reduced example Hello WebKit community. Since this is my first interaction here I'm taking an opportunity to say "hi". I came across specific styles that make text disappear when toggled. Please see the reduced example attached as disappearing-menu-entry.html. As far as I was able to investigate this phenomenon it happens due to max/min widths of text being unavailable in `RenderBlockFlow::computeInlinePreferredLogicalWidths()` during layout calculation after style update. This layout used to work in previous versions of WebKit (up to WPE 2.40.x) and regressed after introduction of https://commits.webkit.org/262914@main which added `renderText->resetMinMaxWidth()` callt in `RenderBlockFlow::tryComputePreferredWidthsUsingModernPath()`; This `resetMinMaxWidth()` is called shortly before the erroneous invocation of `computeInlinePreferredLogicalWidths()`. REPRODUCTION Steps: - open disappearing-menu-entry.html - press right arrow once (or tap once anywhere on page on screen device) Expected outcome: - "All Channels" turns grey and remains visible Actual outcome: - "All Channels" disappears Further steps: - press right arrow (or tap) again, now "HD & Ultra HD" should turn grey but disappears instead MITIGATION Quickly toggling one of layout-impacting CSS properties (e.g. setting "padding-top: 0px" and then reverting it to "1px" after 1ms) mitigates the issue. The text that disappeared becomes visible again. VERSION Initially I observed this issue in WPE 2.42.5 on a Set-Top Box however it seems to be reproducible in all flavors of WebKit on pretty much every platform. I can certainly reproduce it in: - WPE 2.42.5 - Epiphany 42.4 (based on WebKit 2.42.5) on Ubuntu 22.04 - Safari 16.4 (12615.26.11.23) on macOS Ventura 13.3.1 - current main branch (SHA: c7ee831c38599255e3ae78a2b28b71968615107f) built locally for PC (Linux, WPE flavor) Other engines appear to handle such layout correctly, issue is _not_ reproducible in: - Chromium 121.0.6167.164 (Brave: Version 1.62.162) - Firefox 122.0.1 FIX (PROPOSAL?) Internally we applied rather simplistic countermeasure - added ad-hoc recalculation of text min/max widths if they are missing at the crucial spot. Please see the attached 0001-IFC-Recalculate-text-min-max-logical-width-if-missin.patch. I admit I don't fully understand the intention behind introduction of that resetMinMaxWidth(). Surely there were legitimate reasons so I left that bit intact. I wonder if the proposed change is headed in the right direction and if not what would be a better alternative. I'm happy to raise a PR if there is initial agreement about the approach.
Created attachment 470111 [details] fix proposal
Created attachment 470118 [details] Test reduction
<rdar://problem/123913666>
Created attachment 470121 [details] [fast-cq]Patch
Committed 275605@main (6b7ffb51bcb3): <https://commits.webkit.org/275605@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 470121 [details].