Without WebRender, switching to a tab which is expensive to paint works like this: - The user initiates the tab switch from the "old tab" to the "new tab". - We activate the DocShell of the target tab in its content process. - The tab switcher is still displaying the old tab, not yet the new tab. - The new tab paints its contents. - If painting takes to long, the tab switcher might "switch" to the new tab and display a loading spinner. The <browser> of the new tab is still invisible. - The tab sends its layer tree to the compositor. - The compositor receives the layer tree. - It sends an CompositorBridge::LayersUpdated IPC message. - On the main thread of the parent process, that message is received. This triggers a call to TabParent::ObserveLayerUpdate, which dispatches a "MozLayerTreeReady" event on the tab's <browser> element in the parent process. - Once the "MozLayerTreeReady" event has been received by the tab switcher, it completes the tab switch and makes the <browser> of the tab visible. With WebRender, it currently works very similarly. The CompositorBridge::LayersUpdated IPC message is triggered inside WebRenderBridgeParent::RecvSetDisplayList after SetDisplayList and ScheduleGenerateFrame have been called. Once WebRender can start rendering expensive scenes asynchronously (bug 1425510), we should make the following modifications to the WebRender behavior: - If a new display list is received, we should kick off the required CPU rendering tasks for that display list. - We should wait before sending the CompositorBridge::LayersUpdated IPC message until those CPU tasks have completed. This will ensure that the tab switcher keeps the previous tab (or the loading spinner) shown until painting of the new tab is completed and the new scene can be displayed without jank.