How to pass information to content script when it is attached?

Add-ons Development
#1

Latest Nightlies are no longer capable of communication between add-on script and content-script before the page readystate is complete.

There’s also no one confirming wether or not this change has been intentional and if it will stay like this, or if it is a bug that needs to be corrected.

As such (and seeing how mozilla has been making lots of terrible decisions lately) I am assuming that this is here to stay and I am trying to find an alternate method of passing information when the content-script is attached, but I can’t find anything that works other than completely dropping the pageMod api and use a different method of attaching content-scripts to pages to avoid the issue completely, which as far as I could find it is extremely more complicated than pageMod.

I already tried the self.port, self.port.on and worker.postMessage apis, all only work too late.

I also tried contentScriptOptions, which works except they are static (don’t understand why this has been made static intentionally since it would make the pageMod api a far easier api to work with if it was dynamic). Any change to the settings will never have any effect unless the pageMod is destroyed, page is reloaded (including all affected tabs) and then attach the pageMod with the updated static options, or restart the browser entirely. This is not a working solution.

Are there any other ways of communicating with the content script before the pages’ readystate is complete?

#2

What about loading in a framescript? You can communicate with your addon anytime you want with those:

#3

Not a good option, it is on its road to deprecation and the effort to make it work would be better applied to creating my custom pageMod.

Fortunately I think I am managing to “patch” around the problem and seems to be loading faster in the page than before, but I still am not sure about the memory impact it could be having so further tests are required.

Basically I am using two pageMods, one is static and the other is linked to the first, but the second one contains the contentScriptFile and contentScriptOptions which are updated whenever a content script attaches to a page, the only way to do this is for the second pageMod to be destroyed and created again. This way I don’t need to rely on communications during first run and the script loads sooner in the page (some times too soon, occasionally it runs before documentElement even exists/is available).

I still don’t know if the Nightly problem is intentional or not, would save a lot of time and work if it was going to be fixed.

#4

Whoa no way, are you sure about the deprecation? They just brought out framescripts in prep for e10s.

#5

It is built on XPCOM which has been announced as targeted for deprecation, unless I am getting this all wrong:

Deprecation of XUL, XPCOM, and the permissive add-on model

https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity.

https://wiki.mozilla.org/WebExtensions/FAQ#Why_are_these_big_changes_needed.3F

#6

Ah I thought specifically that framescripts were marked deprecated. I see what you mean now.

#7

Just an update in case anyone needs it, the previous method works well with Nightly, not so much in Stable so I am currently trying to make my own pageMod to see if I can work around the problem.

#8

I’ve managed to work around the problem for now by using pageMod together with tab.attach. Basically pageMod only loads the add-on stylesheet, and just the stylesheet, as usual. This one never had any problems. Now the reason why I still use pageMod is for the contentScriptWhen: start, I couldn’t find anything else that could replicate this, the closest I found was the tabs.on("ready", callback) but it was still too late (only firing after the entire document has been parsed and before any resources load)

pageMod onAttach callback returns a worker and it is with this worker that I attach the script with via

worker.tab.attach({
    contentScriptFile: "./pathToScript.js",
    contentScriptOptions: {scriptSettings: settings}
})

This works perfectly, even better than before because I can now use “dynamic” contentScriptOptions since it is built new every time the script attaches to the pages, I can use updated values for this field each time it attaches and (now that I can use them without being stuck with the same options until the browser restarts) the contentscript can run faster than before since it is attached with the options, unlike before where it had to attach and then wait for the add-on script to send the settings before running.

On the other hand I still don’t know if the problem that made me come up with this method is a bug or intentional, however now I am less worried about having the add-on broken if they don’t fix the problem.

Can’t say anything about the other add-ons that are unaware of this and might break if this problem ships to stable, but if my solution works for them too then all the better.

#9

I see you spreading this FUD everywhere.

Unless you can provide a direct quote with words ‘framescript’ and ‘deprecate’ in a single sentence would you please stop?

And no, XPCOM !== framescript.

#10

I am sorry, but what did I do to deserve this kind of response? I clearly added “unless I am getting this all wrong”.

And as far as I know, this has been the only time I said this.

#11

Additionally, the linked page suggested as a solution to my 1 month old issue by Noitidart shows that the nsIFrameScriptLoader (which he referred as framescript and so did I as a result) is an XPCOM interface, the navigation trail itself already shows that:

XPCOM > XPCOM reference > XPCOM Interface Reference > nsIFrameScriptLoader

and as I linked before XPCOM will be deprecated along with XUL and the permissive add-on model.

Deprecation of XUL, XPCOM, and the permissive add-on model

All the comments I made were in response to information that was provided and more was included, and this is as far as I can see the only time this subject has been discussed by me so I don’t understand where your “I see you spreading this FUD everywhere” comes from.

I would appreciate if you could provide something to support your claims instead of attacking me as if I was doing something intentionally wrong, especially where else have I “spread this FUD everywhere”, otherwise your entire conversation is absolutely false.

#12

Who knows what Mozilla might do., but if you’re worried about frame scripts being deprecated then you need to be developing entirely using WEAPI or high-level SDK APIs. A frame script is no more an XPCOM object than window or content. Both have XPCOM interface definitions, but both are eminently usable without doing XPCOM stuff. In time though, Mozilla does intend to drop access to all that low level stuff, but they may provide high level wrappers around some of it so you can do the same things without getting dirt under your nails. They are already working to make their most important addons work purely through the high level APIs.

BTW, nsIFrameScriptLoader isn’t a frame script. It is a defined interface of a message manager. A frame script is just a script that is loaded with a particular set of privileges and a particular context within a content window, although the frame script global does implement several XPCOM interfaces :slight_smile: