Yes, content scripts run before the background page on browser startup. It happens because Chrome is faster than Firefox in this scenario due to prioritization of web content delivery. Even on SSD hard drive Firefox with lots of addons may start 10 times slower (several seconds) than Chrome with the same amount of similar extensions (less than a second).

It makes development of extensions less trivial, which is not an insurmountable problem usually, but the bigger problem is that this behavior introduces FOUC (for extensions that apply color themes to websites) or allows undesirable elements/scripts on the webpage that are normally removed by privacy protection extensions like uBlock/Ghostery/etc. 

On the other hand, this may not be a significant problem in case the majority of users start/restart the browser rarely. I expect this kind of statistics is available for Chromium developers so it'd be interesting if they share the numbers.

Thank you for your reply!

We run into this problem in automated tests where the browser is started via command line with a initial web page to load.

Is this behavior documented anywhere?

Why doesn't Google Chrome wait for all background scripts to be executed before it loads any web site content?


What is the recommended way to work around this? Retrying to re-connect to the background page when it fails? How long to wait before considering the background page to be not present (e.g. extension has been updated while the browser started, and so the content script trying to connect cannot connect anymore as it is orphaned)?

Chrome doesn't wait for the background pages in order to display the page faster. Because speed is what Chrome is about. I guess extensions aren't considered vital to that end.

I think you can retry via setTimeout for as long as you want when the response/result is undefined. On a fast machine it'll take a second. Just don't forget to stop when orphaned by checking a global variable isOrphaned, for example. As for the orphaned state detection, I suggest using a DOM event: dispatch it on start of the content script, then register a listener for that event. The old orphaned scripts will receive the event, detach all their listeners and die:

var isOrphaned = false;
window.dispatchEvent(new CustomEvent('orphaned' + chrome.runtime.id));
window.addEventListener('orphaned' + chrome.runtime.id, function onOrphaned() {
  window.removeEventListener('orphaned' + chrome.runtime.id, onOrphaned);
  isOrphaned = true;
  // unregister listeners, do cleanup
  // ........
});

Ok, I understand.

And how to detect orphaned state in case the extension gets disabled?
So there is no "new" content script which can send an orphaned notification to the "old" content script.
My idea for that case is to try to load a web visible script file from the extension via XmlHttpRequest, and if this fails, the extension is detected as disabled.
Usually this works, but I'm not sure if this is really reliable and that the script is always immediately "loadable" after startup even if Chrome has not executed the background script?

The orphaned script loses access to all chrome.* API except for chrome.runtime so you can simply check if chrome.storage is undefined.

@ dmnkholzl-- Could you please try the steps in comment #5 and update the results.

Thanks!

hdodda@chromium.org, this issue can be properly answered only by an extensions API developer. Can you untriage it or cc someone, maybe rdevlin?

Closing issue as Wontfix due to lack of feedback requested but not provided. If the issue still exists please open a new issue with the details requested.

Thanks..!