I was looking at the LayerTreeHostProxyTestCommitWaitsForActivationMFBA test and I realized we are allowing main frames while a frame that is waiting for activation before DidCommit is active.

This is really contrary to the point of waiting for activation so I wonder if this is actually on purpose.

First, the method is LayerTreeHost::SetNextCommitWaitsForActivation. It should really be SetNextDidCommitWaitsForActivation.. it wants the commit done notification to be delayed.

If we start a new beginmainframe in the meantime, that means it will come out of order with the last frame's DidCommit.

The reason for waiting for activation is for example if a client has only a double buffered TextureLayer, so it gives one to the compositor and says we need to wait for activation. This guarantees that cc will activatate and return the previous texture to it (we return things before DidCommit), before the main thread becomes unblocked.

How are we doing a main frame then if the main thread is supposed to be blocked until activation? It would cause the above example client to possibly start mutating the texture that is currently on the active tree when it should not be.

I would expect a must-wait-for-activation to keep the main thread blocked (that was the intention) so it should be impossible to do a new main frame while in that state.