| Summary: | [macOS] Fixed elements can flicker on a page that is busy doing layout | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> | ||||
| Component: | Scrolling | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | koivisto, simon.fraser, zalan | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
Seen on macOS, reproduces in shipping Safari. I think what's happening is that the main thread can be busy running JS etc, allowing a commit on the main thread with a very stale position for the fixed layer. Meanwhile, the scrolling thread has moved ahead, and is continually pushing the layer to its correct position. The fix is to allow the scrolling tree to have the final say on layer positions, so post-flush, traverse the scrolling tree on the main thread and have it set positions based on the scrolling thread's scroll position. Still not sure what's happening here. I have verified that the state of the layer tree as set by the scrolling thread is always correct (logging CALayer positions). We may have a race between main thread commits setting layer positions, and the scrolling tree doing so. We don't really have any protection against CACommit racing. Does not reproduce with UI-side compositing and some applyScrollingTreeLayerPositions() work, so does seem to be caused by CACommit racing. I saw in traces that CACommits in main thread and scrolling thread are overlapping. |
Created attachment 363817 [details] Testcase Fixed bars can flicker to incorrect positions on a page that is busy doing layout.