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)
Developer Documentation Graveyard
Add-ons
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 | ||
Updated•8 years ago
|
Assignee: nobody → wbamberg
Updated•8 years ago
|
tracking-e10s:
--- → +
Updated•8 years ago
|
Blocks: e10s-addons
Assignee | ||
Comment 1•8 years ago
|
||
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)
Comment 2•8 years ago
|
||
(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)
Assignee | ||
Comment 3•8 years ago
|
||
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.
Description
•