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 () 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
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).
: 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