When a RemoteTexture wait is too long, there are the following choices.

[1] Wait until RemoteTexture ready
[2] Quit the wait and resume WebRender rendering.

[1] causes the UI freeze. Then we need to chooser [2].

The too long wait stops to update Firefox window rendring. It looks like UI freeze. It is not good.
Changing async RemoteTexture to sync RemoteTexture could decrease the problem from a Firefox window freeze to a Tab freeze.

When the wait has ended, we want to update WebRender rendering.
WebRender shows previous rendering. WebRender has a next ResultMsg::PublishDocument message.
With the message WebRender could update Window UI. But RemoteTexture is not ready yet.
In this case, there is no other way but to use the previous RemoteTexture.
Then gecko requires the following

• Changing setting from async RemoteTexture to sync RemoteTexture.
• Request repaint to all content processes. + It could be done by calling BrowserChild::SchedulePaint()

Repaint updates the RemoteTexture to sync one.

Do you have a test case for this scenario? If not, can we make one?

I do not have a test. I am going to create the test.

If Bug 1828088 works, this bug fix is not necessary.