Bug 1258465 - Only nsIWebBrowserFocus->activate a TabChild once it has composited

So one of my concerns is that we’re over-optimizing for the test here because my current patch notifies the TabChild that we’ve composited based on the MozAfterPaint event firing. This isn’t exactly cheating, but moving it to after MozAfterPaint fires has no purpose except for improving our test score; otherwise, we’d move it to where we queue the MozAfterPaint event to fire.

I should talk to somebody about that because we’re going to score more poorly with e10s despite us presenting to the user at the same time or even faster, because we’ll be blocked on firing the MozAfterPaint event which tpaint.html is waiting for to stop its stopwatch.

One of the problems that mstange brought up is that we’re breaking the assumption that any focus events sent after the activate will go to the right things because we haven’t necessarily actually activated yet.

One idea: Can we increase the priority of the sync IME message so that we can get an answer ASAP and get to painting?

Answer: Not really - the message is already at prio(urgent). :/