1056396 - Loading SDK into Frame Scripts and Content Workers

Status: RESOLVED DUPLICATE of bug 1070927

(Add-on SDK Graveyard :: General, enhancement)

Description

[The 8472]

I found there to be a severe impedance mismatch between the various contexts which should be used when developing an addon with SDK.

Namely i've encountered
- main addon code
- panel windows
- child process frame scripts [dealing with chrome code under e10s]
- page workers

And while not having used them myself yet I imagine a similar problem exists for sandboxes.

Only the first of those supports the module loader and thus by extension any features provided by the SDK modules.

This forces me to either write vanilla javascript in all other contexts, import 3rd party libraries and thus work with different frameworks depending on the context or forgo using most of the SDK and doing some dance around differing global objects to get code to work with and without modules.

Message-passing between those contexts would also be more convenient if both sides could share the same modules since one could simply serialize/deserialize objects from/into the same classes cloaded into both contexts.

I think e10s would also be easier to handle for future addons if they could simply elect to run some of their chrome-privileged code in a Frame Script by injecting the same modules into it.

If this is already possible some documentation how to achieve it would be helpful.
If not consider this an RFE.

Comment 1

[Dave Townsend [:mossop]]

This is actually done for security (and in some cases necessity).

Panel windows, page workers and page mods are all scripts that run with content privileges as they interact heavily with web content. We don't want to allow chrome privileged code to run there as it runs the real risk of giving web content a way to escalate and take control of the browser.

e10s frame scripts run in the content process where most of the information required to make the APIs work doesn't exist. Unless we changed most of the APIs to be completely asynchronous they wouldn't be usable in e10s frame scripts.

Comment 2

[The 8472]

> Security

Understandable, but this shouldn't prevent sharing of non-critical modules. E.g. core/heritage + require(). That alone would already allow content and chrome scripts to share the same data classes.

Trivial example:

var Rectangle = Class({initialize: function(a,b,c,d) {...}; getArea: function() {...}})

I can now send the Rectangle with its instance variables to a different context through JSON-encoded messages (boo!, not even structured clone!). But I loose all functions and have to completely re-implement them in the other context if I need them there.

I simply cannot share code that uses even the most basic aspects of the SDK.

> Panel windows

I'm using a panel window to render add-on specific controls with HTML/JS bundled in the extension. Basically as a replacement for XUL controls since the SDK provides no API for that.

It might as well run with chrome privileges for that purpose, but that's not really necessary. Just having my same custom data types available after sending them through the port would already make things easier.

>e10s frame scripts run in the content process where most of the information required to make the APIs work doesn't exist.

I'd already be happy to have require("./myLib.js") to use the same modules available + require("chrome") to have a consistent API consistency.


> Unless we changed most of the APIs to be completely asynchronous they wouldn't be usable in e10s frame scripts.

Yes. Asynchronous programming across those boundaries is difficult. I'm saying the SDK makes it even more difficult by providing several inconsistent environments which prevent code-reuse.


Shared-everything is not possible. Shared-nothing is what we have right now. Shared-basics is what I'd be happy with.

Comment 3

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I am afraid we won't be able to provide `require` in contexts like content scripts as `require` is blocking and we would not like to encourage blocking pages that add-on may be interacting with, luckily es6 modules are not that far out which we would absolutely integrate with to solve no sharing issue.

For other contexts like frame scripts we could definitely have some sharing, I have created a separate bug 1070927 to see if there is a way we could resolve it.

Comment 4

[The 8472]

I guess access to modules in frame scripts would be "good enough" since one can also access the page content from there.
Thus one could choose between content scripts without modules for simple tasks or frame scripts with modules + some more boilerplate to access the content for complex tasks.