Bug 307996
| Summary: | `UIHelper.immediateZoomToScale()` is very flakey | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, jcheung23, lily_spiniolas, simon.fraser, webkit-bug-importer, wenson_hsieh |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=214358 | ||
Simon Fraser (smfr)
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/171000423>