307996 2026-02-16 11:13:15 -0800 `UIHelper.immediateZoomToScale()` is very flakey 2026-02-23 11:14:11 -0800 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=214358 InRadar P2 Normal --- 1 simon.fraser webkit-unassigned ap jcheung23 lily_spiniolas simon.fraser webkit-bug-importer wenson_hsieh oldest_to_newest 2182130 0 simon.fraser 2026-02-16 11:13:15 -0800 Tests using `UIHelper.immediateZoomToScale()` are very likely flakey, e.g. bug 214358. Investigation shows that there's an IPC race which results in the scale set by `UIHelper.immediateZoomToScale` being clobbered by a scale coming from the web process, meaning that it almost always gets reset. This happens more often in release builds than debug builds. More specifically, the call to `UIHelper.immediateZoomToScale()` results in a `updateVisibleContentRects` to the web process with new scale, but this can overlap with a transaction from the web process back to the UI process with the previous scale, and `_updateScrollViewForTransaction:` uses this to clobber the new UI scale with an older scale. I think this only happens with the `immediate` version because `[_scrollView _wk_isZoomAnimating]` is false. Ideally we'd check some transaction IDs here to know that we just sent a new scale to the web process. 2184105 1 webkit-bug-importer 2026-02-23 11:14:11 -0800 <rdar://problem/171000423>