It was disabled in bug 629197, and gal seems to really like the idea of removing it altogether.
This seems like a good deed in light of our linking-libxul-troubles. Myk, did you guys decide whether you ever want this kind of service? (I remember we talked about jetpack using a document-like execution environment, which this service isn't so suitable for).
Created attachment 582884 [details] [diff] [review]
bholley, ejpbruel, and I chatted about this on IRC today.
The upshot: it's fine to remove the jetpack service, since the Jetpack project has puts its e10s efforts on hold, and if/when we do pick up that project again, it doesn't seem likely that we'll use jetpack processes to implement out-of-process addons, as we were leaning toward using content processes anyway.
If we change our minds, we can always retrieve the code from the repository history.
Does this need to be announced somewhere?
The jetpack service has been disabled (hard, at the C++ level, without config switch) for 9 month. I don't think anyone cares.
(In reply to Ms2ger from comment #4)
> Does this need to be announced somewhere?
Maybe update https://developer.mozilla.org/en/Jetpack_Processes or somewhere around there that this is no longer available at all?
There are a number of old Jetpack add-ons still using this service.
Jeff, you might want to contact these developers.
How would they be using it if it hasn't been compiling as part of FF for 9 months?
They're most likely broken, but they will still install in Firefox 10 and above because they have Firefox 4 compatibility.
Those add-ons are using pre-1.0 SDK code, IMO this is another case where we will need to contact developers direectly, but also unfortunately also a case where the SDK apis may have changed.
Further, I honestly think we should do the following:
* Identify the affected add-ons
* make them incompatible with Firefox 10
* contact the authors and explain what we did, why, and encourage them to re-pack with 1.5