Closed Bug 565180 Opened 15 years ago Closed 6 years ago

New Extension Manager Breaks Jetpack Prototype

Categories

(Mozilla Labs :: Jetpack Prototype, defect)

Product:
Mozilla Labs
Component:
Jetpack Prototype
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INACTIVE

People

(Reporter: zpao, Unassigned)

Details

This one is going to be harder to fix...

The new extension manager broke the old APIs and so there are a couple things that break in the prototype. Unfortunately, it looks like it will take more work than it's really worth to fix it - so much is written expecting sync, but the new API is async.

I think they're all in http://hg.mozilla.org/labs/jetpack/file/eefc5d542c5a/extension/modules/setup.js

Specifically getExtensionDirectory() and version().
getExtensionDirectory can be faked synchronously. Getting the addon version can't.

I'm filing this so we have something to point to when it's brought up. I don't expect it to be fixed, but I'm sure a patch would at least be looked at.
Since I know one of the main reasons some folks use the prototype is for the Bugzilla jetpack, do you know where the source code for it is?  Since it's mostly a page-mod, it seems like it shouldn't be too hard to build it as a rebootless extension with the Jetpack SDK.
Here's the source for the bugzilla tweaks jetpack:

http://hg.mozilla.org/users/jnightingale_mozilla.com/jetpacks/file/tip/bugzilla-tweaks.js

Here's the list of jetpack functionality that I use in that jetpack:

1. pagemod
2. jetpack.menu for context menu modification (which is basically broken since forever!)
3. jetpack.clipboard, which doesn't matter since it's used by the context menu code which is broken anyways)
4. directly access the preferences service and the cookie manager service using XPCOM.

If all of the above is currently possible, I'm willing to spend some time to try to make things work with the Jetpack SDK (assuming that the addons it creates can be used on both trunk and 3.6).
Note to self: possible fix (yes yes yes, it sucks, etc.)

http://hg.mozilla.org/labs/weave/file/afa5fc3ea849/modules/ext/Sync.js#l85
Sweet! Yup, the extensions it makes are usable on both, and once the patch for bug 562819 lands, the extensions will be rebootless on trunk and still work on 3.6 (i.e., be "rebootfull").

While pagemods haven't landed, or even started development afaik, as an actual Jetpack API, I've written some basic functionality into my personal repo that I can help you with. XPCOM is also accessible, so your preferences/cookie access should work fine, so long as you remove any observers, etc. when the unload event fires (otherwise there will be leaks when the extension is used in rebootless mode).
(In reply to comment #4)
> Sweet! Yup, the extensions it makes are usable on both, and once the patch for
> bug 562819 lands, the extensions will be rebootless on trunk and still work on
> 3.6 (i.e., be "rebootfull").

Does that mean that I have to wait for the 0.4 release, or my extension would just magically be rebootless when I recompile it with the 0.4 SDK?

> While pagemods haven't landed, or even started development afaik, as an actual
> Jetpack API, I've written some basic functionality into my personal repo that I
> can help you with.

Great!  Do you have any docs/samples/whatever on how to use them?

> XPCOM is also accessible, so your preferences/cookie access
> should work fine,

Sweet.  Will we always have access to XPCOM APIs, or will it go away at some point?

> so long as you remove any observers, etc. when the unload
> event fires (otherwise there will be leaks when the extension is used in
> rebootless mode).

I don't use any such stuff for now, so that's not an issue.

About the menu API, is the Jetpack SDK context-menu API usable right now?

Also, I guess I could simulate jetpack.clipboard using XPCOM calls.
Ping?
(In reply to comment #5)
> (In reply to comment #4)
> > Sweet! Yup, the extensions it makes are usable on both, and once the patch for
> > bug 562819 lands, the extensions will be rebootless on trunk and still work on
> > 3.6 (i.e., be "rebootfull").
> 
> Does that mean that I have to wait for the 0.4 release, or my extension would
> just magically be rebootless when I recompile it with the 0.4 SDK?

Yep, it will magically become rebootless--but that just makes it even more important that you unload your custom XPCOM access when the unload signal is sent, or else you will cause leaks when the user disables/uninstalls your extension without rebooting.

> Great!  Do you have any docs/samples/whatever on how to use them?

Yep, the easiest thing to look at would probably be my facebook acquaintances addon, which replaces every occurrence of "friend" in facebook with "acquaintance":

  http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/file/19c89cb9463b/packages/facebook-acquaintances/lib/main.js

It uses a module called persistent-page-mod:

  http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/file/19c89cb9463b/packages/facebook-acquaintances/lib/persistent-page-mod.js

In combination with the 'tab-browser' module, which is in the latest trunk of the jetpack SDK:

  http://hg.mozilla.org/labs/jetpack-sdk/file/f529ef2acd12/packages/jetpack-core/lib/tab-browser.js

I'm not sure if it's in the latest stable release but you should be able to just copy over the module and one or two of its dependencies if not.

> > XPCOM is also accessible, so your preferences/cookie access
> > should work fine,
> 
> Sweet.  Will we always have access to XPCOM APIs, or will it go away at some
> point?

Once we securitize Jetpack, we will still provide a way for creating "drivers" that expose some subset of chrome functionality to jetpacks; these will need to be reviewed much more closely than sandboxed jetpack code, of course, but it will be possible. The easiest way to plan for this for now is just to encapsulate all your XPCOM-accessing functionality into its own module (or multiple modules, e.g. one for cookies and one for prefs) that expose an XPCOM-free interface.

> About the menu API, is the Jetpack SDK context-menu API usable right now?

It should be, now that my ridiculous mis-commit of a WIP patch was backed out by zpao.

> Also, I guess I could simulate jetpack.clipboard using XPCOM calls.

Yeah--even more awesome would be if you put it into a module that could be redistributed and even added to the core! :)
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Sweet! Yup, the extensions it makes are usable on both, and once the patch for
> > > bug 562819 lands, the extensions will be rebootless on trunk and still work on
> > > 3.6 (i.e., be "rebootfull").
> > 
> > Does that mean that I have to wait for the 0.4 release, or my extension would
> > just magically be rebootless when I recompile it with the 0.4 SDK?
> 
> Yep, it will magically become rebootless--but that just makes it even more

Cool!

> important that you unload your custom XPCOM access when the unload signal is
> sent, or else you will cause leaks when the user disables/uninstalls your
> extension without rebooting.

OK, I'll keep this in mind.

> > > XPCOM is also accessible, so your preferences/cookie access
> > > should work fine,
> > 
> > Sweet.  Will we always have access to XPCOM APIs, or will it go away at some
> > point?
> 
> Once we securitize Jetpack, we will still provide a way for creating "drivers"
> that expose some subset of chrome functionality to jetpacks; these will need to
> be reviewed much more closely than sandboxed jetpack code, of course, but it
> will be possible. The easiest way to plan for this for now is just to
> encapsulate all your XPCOM-accessing functionality into its own module (or
> multiple modules, e.g. one for cookies and one for prefs) that expose an
> XPCOM-free interface.

Makes sense.

> > About the menu API, is the Jetpack SDK context-menu API usable right now?
> 
> It should be, now that my ridiculous mis-commit of a WIP patch was backed out
> by zpao.
> 
> > Also, I guess I could simulate jetpack.clipboard using XPCOM calls.
> 
> Yeah--even more awesome would be if you put it into a module that could be
> redistributed and even added to the core! :)

Interesting.  So, I took a look at https://wiki.mozilla.org/Labs/Jetpack/JEP/10 and it seems that it's now obsolete, but is not going to be replaced by anything.  Should I still use that as a document of how the module should behave?
Sure, I think that is fine.
Closing all inactive bugs in Mozilla labs :: *
Please reopen if this are still relevant.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.