1958433 - [meta] Reduce time until geckoview.xhtml chrome-document-loaded notification during applink startup

Status: NEW

(Core :: Performance Engineering, task)

Description

[Markus Stange [:mstange]]

One of the milestones during applink startup (bug 1945906) is marked by the time at which the chrome-document-loaded notification for geckoview.xhtml fires.

This bug is a tracking bug for any fixes which reduce the time between this point and the previous milestone. The previous milestone is the beginning of GeckoViewSupport::Open, bug 1958039.
Profile for the things that happen between the two milestones: https://share.firefox.dev/4jrKHMF

Here's how the chrome-document-loaded notification fits into the startup process:

• GeckoViewSupport::Open does a bunch of initialization work, https://share.firefox.dev/4jh07Dd :
  • GfxInfo::EnsureInitialized (under gfxPlatform::Init), spends time loading GL in the parent (bug 1925116)
  • gfxPlatformFontList::InitFontList (under gfxPlatform::Init)
  • UA stylesheet parsing, under Document::CreatePresShell
• At the end, GeckoViewSupport::Open initiates the load of geckoview.xhtml
• Loading geckoview.html is done via nsJARChannel::AsyncOpen. This involves many main thread round trips: nsJarChannel::ContinueOpenLocalFile, nsPipeInputStream AsyncWaitCallback for the stream copier, nsAsyncRedirectVerifyHelper, onRedirectVerifyCallback (via runLater in WebRequest.sys.mjs), nsAsyncVerifyRedirectCallbackEvent, two RedirectToRealChannel promises, and another nsPipeInputStream AsyncWaitCallback (from DocumentLoadListener::ResumeSuspendedChannel).
• Once the document for geckoview.xhtml is created, we start loading geckoview.js.
• Loading geckoview.js is also done via nsJARChannel::AsyncOpen. This involves more main thread round trips: nsJarChannel::ContinueOpenLocalFile, nsPipeInputStream AsyncWaitCallback for the stream copier, and a NotifyOffThreadScriptCompletedTask.
• Once geckoview.js has loaded, we fire the DOMContentLoaded event for geckoview.xhtml. This calls the startup() function in geckoview.js.
• During startup(), the <browser> constructor causes the initialization of a content process, bug 1958065.
• After the DOMContentLoaded event, we get ready to fire the load event for geckoview.xhtml. This does a main thread roundtrip via a TitleChangeEvent runnable.
• Just before we fire the actual load event, we fire the chrome-document-loaded notification.

The chrome-document-loaded notification gets translated into a call to OnGeckoViewReady by nsAppShell. This calls GeckoSession::Window.onReady, which flushes mNativeQueue. mNativeQueue contains an entry for GeckoView:LoadUri.

So the chrome-document-loaded is what kicks off the actual load of the applink URL, by flushing the queued GeckoView:LoadUri entry from the GeckoSession.

To make the chrome-document-loaded notification fire earlier, we need to reduce the delays of the runnables involved in the loading of geckoview.xhtml and geckoview.js. This can be done by reducing the number of runnables needed, by changing the priority of the runnables, and by reducing the duration for which the main thread is blocked by other work (bug 1958410).

On the Fenix side, GeckoEngineSession.loadUrl needs to be called early enough that it doesn't delay the point at which Gecko sees GeckoView:LoadUri. At the moment it's called early enough, i.e. it's called before "chrome-document-loaded" fires, so the bottleneck is currently on the Gecko side.