Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2e0ec50936e2c9a299cc9383043d06425d61ac1a
https://github.com/WebKit/WebKit/commit/2e0ec50936e2c9a299cc9383043d06425d61ac1a
Author: Chris Dumez <[email protected]>
Date: 2026-07-15 (Wed, 15 Jul 2026)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ShrinkToFit.mm
Log Message:
-----------
[macOS] TestWebKitAPI.WebKit.ViewScaleFactorAfterShrinkToFit is constant
failure on safari-7625-branch
https://bugs.webkit.org/show_bug.cgi?id=319407
rdar://182233814
Reviewed by Abrar Rahman Protyasha and Aditya Keerthi.
The ViewScaleFactorAfterShrinkToFit test added in 314774@main is flaky and
fails on some bots with "Expected: ([webView _viewScale]) < (1.0), actual:
1 vs 1", meaning the cached view scale was still the default 1.0 when
checked.
The test used a single JavaScript round-trip (document.body.clientWidth) as
an indirect signal that the WebProcess-side auto-scale had completed and
been reported to the UIProcess. However, that sequence is asynchronous with
respect to navigation and JavaScript execution: the WebProcess scales the
view during a compositing flush (DrawingArea::scaleViewToFitDocumentIfNeeded)
and only then sends ViewScaleFactorDidChange back to the UIProcess. Since the
IPC is not ordered against the JavaScript reply, on some bots [webView
_viewScale] was read before the scale factor update arrived.
Poll the actual condition under test with Util::waitFor() instead of relying
on an unrelated round-trip as a proxy for completion.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ShrinkToFit.mm:
(TEST(WebKit, ViewScaleFactorAfterShrinkToFit)):
Canonical link: https://commits.webkit.org/317274@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
