For an add-on I’m currently writing I need to do things with content pages that are not possible from a WebExtension content script.
Because it is not (yet) possible to write WebExtension Experiment APIs for content scripts, I use an experiment API from the background script that creates process/frame scripts which in turn load my original content script with the extended functionality I need.
So for everything works surprisingly well, with one major problem:
I can’t map the tabs the frame scripts are attached to the tabIds of the WebExtension context.
What I found is that the mapping is done in the TabManagerhere.
But:
// This file provides some useful code for the |tabs| and |windows|
// modules. All of the code is installed on |global|, which is a scope
// shared among the different ext-*.js scripts.
Is there a way to access that global context or get the TabManager in any other way?
@The_8472 was doing some work on this he might have a soluton, he’s a regular on IRC -
I have tried writing a hybrid extension recently and ran into the issue of translating internal identifiers (tab/window/request IDs) into their bootstrapped equivalents. I think if i whack the web-ext internals hard enough the information might fall out somewhere…
I found a pretty hackish way to get the tabIds from a frame script.
Here is what I did, should anybody else need this:
1.) check that the current document.URL matches <all_urls> (but is not amo)
2.) set a callback on the unwrapped contentWindow
3.) use nsIDOMWindowUtilss suppressEventHandling and suspendTimeouts to pause the page
4.) use a tiny content_script to asynchronously get its own tabId from the background page and call the callback
5.) delete the callback and resume the renderer
Thus all happens before the first script on the page had a chance to load, so the page won’t notice that it was abused this way.