With browser-side navigation enabled, navigations in new foreground tabs are considered to have started in the background.
clamy explains:
"""
the background/foreground issue seems to be due to the ordering of calls in chrome/browser/ui/browser_navigator.cc when we create a new tab. What happens is:
- we first create a WebContents and ask it to navigate (https://cs.chromium.org/chromium/src/chrome/browser/ui/browser_navigator.cc?type=cs&l=557). This result in the creation of a NavigationHandle, so we fire DidStartNavigation. In the current architecture, we fire DidStartNavigation after receiving a DidStartProvisionalLoad.
- then we insert the WebContents in the tab strip (https://cs.chromium.org/chromium/src/chrome/browser/ui/browser_navigator.cc?type=cs&l=589). This fires WebContentsImpl::WasShown.
"""
This is a change in behavior from before PlzNavigate. This causes page load metrics to incorrectly consider these page loads to have started in the background, which skews all of Chrome's page load metrics (PageLoad.* in UMA).
Nasko proposes fixing this by exposing the WebContents CreationParams to interested WebContentsObservers:
"""
We create the WebContents and immediately after attach all TabHelpers. We have the creation parameters, which indicate the disposition of the new tab. What if we were to pass these parameters to the construction of TabHelpers. Then your TabHelper can check the disposition and calculate the initial visibility state - current tab and new foreground tab will be visible, while new background tab will be invisible.
"""
We should implement Nasko's suggestion and pass the CreateParams on to the MetricsWebContentsObserver, which keeps track of fg/bg state for page load metrics.
Nasko notes that we won't have the CreateParams in all places where a WebContents is passed to TabHelpers, so we should wrap in base::Optional<> and provide the CreateParams where they are available.
Comment 1 by bmcquade@chromium.org
, May 25 2017