[webkit-changes] [WebKit/WebKit] 3fe5ba: Ignore willCommitLayerTree and commitLayerTreeNotT...

[Gerald Squelart]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3fe5ba4547a3ece6a1ab059a583e183b06e6da54
      https://github.com/WebKit/WebKit/commit/3fe5ba4547a3ece6a1ab059a583e183b06e6da54
  Author: Gerald Squelart <g_squelart at apple.com>
  Date:   2023-07-30 (Sun, 30 Jul 2023)

  Changed paths:
    M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
    M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in
    M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
    M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm

  Log Message:
  -----------
  Ignore willCommitLayerTree and commitLayerTreeNotTriggered when reordered 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