Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ignore willCommitLayerTree and commitLayerTreeNotTriggered when reord…
…ered after a commitLayerTree https://bugs.webkit.org/show_bug.cgi?id=259632 rdar://110498860 Reviewed by Matt Woodrow. The normal sequence of RemoteLayerTreeDrawingAreaProxy messages should normally be: willCommit(1) commit(1) notTriggered(next commit 2) willCommit(2) commit(2) ... However this could be disrupted by RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState, which waits for the first commit message and runs it immediately! This could lead to handling them in this order: willCommit(1) commit(1) **commit(2)** notTriggered(next commit 2) willCommit(2) ... The main issue is that the notTriggered(next commit 2) handler pauses further display refresh callbacks, which would normally have been restarted by the later-sent commit(2), so the rendering doesn't get updated anymore. In some applications like Mail, this may result in blank email bodies. The solution here is to detect such re-orderings, and produce the same effects as if they had run in the expected order. Details below: * Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in: Add `nextCommitTransactionID` to CommitLayerTreeNotTriggered, to know which commit they should precede (and hence which commit should come after). * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::displayDidRefresh): Send the next commit transaction ID with CommitLayerTreeNotTriggered. * Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: Record the last processed CommitLayerTree transaction ID. * Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeNotTriggered): If this message's next-to-commit transaction ID is lower than or equal to the last-received committed transaction ID, this means that the commit was reordered and handled before this not-triggered, so nothing should be done here; especially, display-refresh callbacks should not be paused, and the scrolling update should happen in the upcoming not-triggered that corresponds to the last-received commit. This should be rare, so a log message is appropriate to expose this event. (WebKit::RemoteLayerTreeDrawingAreaProxy::willCommitLayerTree): Similar to the message above, if the will-commit transaction ID is not smaller than the last-received committed transaction ID, it means that this message was reordered and can be ignored. Its effect would have already been handled by the commit message (see below.) (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeTransaction): Update the last processed transaction ID. Also, if the pending transaction ID is lower than this commit's transaction ID, it means this message is being preemptively handled sooner, so the will-commit effect is simulated by updating the pending transaction ID now -- the already sent will-commit will be ignored later on. Canonical link: https://commits.webkit.org/266421@main
- Loading branch information