Bug 270343 – Text disappears due to unknown max/min width after style change

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Bartosz Moczulski]

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.

[Bartosz Moczulski]

Created attachment 470111 [details]
fix proposal

[alan]

Created attachment 470118 [details]
Test reduction

[Radar WebKit Bug Importer]

<rdar://problem/123913666>

[alan]

Created attachment 470121 [details]
[fast-cq]Patch

[EWS]

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].