Closed Bug 1243035 Opened 8 years ago Closed 8 years ago

Document how to register custom protocols in e10s Firefox

Categories

(Developer Documentation Graveyard :: Add-ons, defect)

defect
Not set
normal

Tracking

(e10s+)

RESOLVED FIXED
Tracking Status
e10s + ---

People

(Reporter: wbamberg, Assigned: wbamberg)

References

Details

Any add-on which registers a custom protocol, on e10s, has to register the custom protocol in the child content process, if the custom protocol is registered only in the chrome process, no iframes or tabs will be able to load any resource from the custom procotol.

For an addon-sdk extensions, the solution seems to be pretty simple:

- register the custom protocol in the child process using the "remoteRequire" helper, e.g.:

var customProtocol = require("./my-custom-protocol");
// support custom protocol on e10s
var { remoteRequire, useRemoteProcesses } = require('sdk/remote/parent');
if (useRemoteProcesses) {
    remoteRequire('./lib/my-custom-protocol');
}

This will need updates in a couple of places:

* the problem: custom protocol handlers must be registered in the content process. this is not an SDK-specific thing, but a general problem for any extension (or even, for any privileged code). As such it feels to me like it belongs in https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts, which is already an attempt to catalogue all the random things that used to work in chrome code, but won't any more. For instance, it seems to fit well with things like https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#nsIContentPolicy.

* the (SDK) solution: use remoteRequire to load your code in the content process: this is an SDK-specific solution to a whole range of e10s problems, including custom protocol handlers (but also, I guess, content policies?). As such, we should document this technique in https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK. In this page, we should:
  * discuss this class of problem (that if you register things that the content process needs to use, like protocol handlers or content policies, then this will break in e10s)
  * point people at https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts for specific instances of this problem - SDK users doing advanced stuff should certainly be reviewing this page.
  * point people at https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/remote_parent for the solution.
Assignee: nobody → wbamberg
tracking-e10s: --- → +
So I've done a couple of things here:

* added a note in https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#nsIProtocolHandler

* substantially revised https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK. Functionally, the main change in here is that we're no longer recommending that people using the SDK should use the message manager/frame scripts directly, but instead should either use content scripts (if all they need is access to content) or use remote/parent (if they need to do something like register a custom protocol handler or a content policy). I've also added a simple walkthrough example of using remote/parent to get content policies working under e10s in an SDK add-on.

Please let me know what you think!
Flags: needinfo?(lgreco)
(In reply to Will Bamberg [:wbamberg] from comment #1)
> So I've done a couple of things here:
> 
> * added a note in
> https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/
> Limitations_of_chrome_scripts#nsIProtocolHandler
> 
> * substantially revised
> https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/
> Multiprocess_Firefox_and_the_SDK. Functionally, the main change in here is
> that we're no longer recommending that people using the SDK should use the
> message manager/frame scripts directly, but instead should either use
> content scripts (if all they need is access to content) or use remote/parent
> (if they need to do something like register a custom protocol handler or a
> content policy). I've also added a simple walkthrough example of using
> remote/parent to get content policies working under e10s in an SDK add-on.
> 
> Please let me know what you think!

The new version of this pages looks great and makes easier to find this informations, thanks!

In the "Multiprocess_Firefox_and_the_SDK" doc page, Can a new example with the "remote/parent" and "platform/xpcom" applied to the custom protocol handler be helpful?

it is something documented in the wild (e.g. [1], [2]) but I didn't found any example of registering a custom protocol from an Addon SDK addon.

[1]: http://stackoverflow.com/questions/24917460/nsiprotocol-example-unclear
[2]: http://stackoverflow.com/questions/21082162/firefox-addon-sdk-loading-addon-file-into-iframe
Flags: needinfo?(lgreco) → needinfo?(wbamberg)
I'm not against having an example using remote/parent with a custom protocol handler. But as long as the general approach is the same as in my example (content policy), then I don’t think it’s necessary.

(Put another way: there are many XPCOM APIs that an SDK add-on could be using, through require("chrome") that would break in this way under e10s. Although it would be nice to document them all, I don’t think it’s a priority for me to do so.)

So I'm closing this bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(wbamberg)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.