1575419 - Too many sync PCompositorBridge::Msg_FlushRendering during window opening with CoreAnimation turned on

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Markus Stange [:mstange]]

Turning on CoreAnimation causes browser_startup_syncIPC.js to fail, see this try push:

sync IPC PCompositorBridge::Msg_FlushRendering 1 more times than expected before handling user events

I can see two main thread paints when a window opens. The first one is expected, but the second one is not. The second one is triggered with a call to markLayerForDisplay because the vibrancy region has changed, which happens during the WillPaintWindow() call in nsChildView::HandleMainThreadCATransaction(). So we're triggering another layer display while we are inside a layer display handler. This is unnecessary and we can just add guards to avoid it.

A try push will confirm whether this change actually fixes the test.

Comment 1

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=162a559c8fd388578507f6d5f66b71708c219636

Comment 2

[Markus Stange [:mstange]]

Attachment: Bug 1575419 - Don't allow triggering another main thread paint from within a main thread paint. r=mattwoodrow

This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().

Comment 3

[Markus Stange [:mstange]]

Green!

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0aa0dd2f418b
Don't allow triggering another main thread paint from within a main thread paint. r=mattwoodrow

Comment 5

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/0aa0dd2f418b