Bug 1668408 added a new mechanism for shims to register content scripts.
When Firefox restores the session on startup the shim content scripts are not injected. This may be because we don't register the content scripts early enough.

Registration happens here: https://searchfox.org/mozilla-central/rev/eecd2dd4ba630bea4ce103623a4bfb398065b64b/browser/extensions/webcompat/lib/shims.js#196

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1733370#c1

Looks like the problem isn't that we're registering the content script too late. I have just tried this with a test extension, registering the content script as early as possible. It still won't load right after startup.
The background script looks like this:

'use strict';

function registerScript() {
  browser.contentScripts.register({
    "js": [{file: "/content_scripts/contentScript.js"}],
    "matches": ["<all_urls>"],
    "allFrames": true,
    "runAt": "document_start"
  });
}

registerScript();

:mixedpuppy, do you know if Web Extensions support loading programmatically registered content scripts that early?
Is this related to Bug 1378459?

Luca probably will have a faster answer.

Changing severity to S3 because this isn't a critical issue.

If the page is being restored by session restore, then it is likely to have started loading pretty early during the browser startup.
Trying to register the content script earlier would not be enough, because it would still not be earlier than when the session restored tabs did start to load (the extensions are not loaded that earlier during the browser startup).
At that point, any dynamic content scripts registered after the page has been loaded would not be injected until we will see that page to be loading again.

I haven't looked to the webcompat shims logic yet, and so I'm not sure which strategy may better fit the current design, but using the APIs already available there should still be at a couple of options to make sure we inject the shims into the tabs where the shim is missing, e.g. these are two strategies that came to my mind at the moment:

• webcompat may use a webRequest blocking listener ([1]) to suspend those request, and then resume them after the shims's contentScripts have been registered dynamically by the webcompat background script
• or (if the shim doesn't need to be executed at document_start and can be executed later when the webpage already got to document_end or document_idle) by detecting which tabs didn't got the shim and execute it into just those tabs/frames using browser.tabs.executeScript

Paul,
let me know if this details are not yet useful enough for you to get a better picture of the underlying issue, and/or if none of the proposed ways to deal with the session restored tabs seem to fit nicely enough into webcompat shims' design, I'm definitely happy to discuss more about this with you (either asynchronously here on bugzilla, and/or synchronously over another messaging channel, e.g. Matrix or Slack, if that may help).

[1]: one added synchronously when the background script is loading, that way the listener is persisted by Firefox and on the next startup Firefox will suspend the requests that are matching the persisted webRequest listeners to let the related extension to handle it once it has been fully started