Jetpack SDK does not support packed extension installation

RESOLVED FIXED in 0.8

Status

Add-on SDK
General
--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

({dogfood, regression})

unspecified
dogfood, regression
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [AOMTestday])

Attachments

(3 attachments)

(Assignee)

Description

8 years ago
I get this on the error console when installing the add-on:

Warning: WARN addons.xpi: Exception running bootstrap method startup on jid0-qBnIpLfDFa4LpdrjhAC6vBqN20Q@jetpack: Error opening input stream (invalid filename?)
(Assignee)

Updated

8 years ago
blocking2.0: --- → ?
(Assignee)

Comment 1

8 years ago
I'm on a nightly from http://hg.mozilla.org/mozilla-central/rev/f38ef1080bfe
(Assignee)

Comment 2

8 years ago
I was trying to install from a local file
(Assignee)

Comment 3

8 years ago
Created attachment 476349 [details]
Add-on
(Assignee)

Comment 4

8 years ago
I seem to get the same thing when I try to install the add-on from this bug as well.
(Assignee)

Updated

8 years ago
Keywords: regression
(Assignee)

Comment 5

8 years ago
I get the exact same error when I try to install Bugzilla Tweaks from https://addons.mozilla.org/af/firefox/addon/187588/
Severity: normal → major
Keywords: dogfood
(Assignee)

Comment 6

8 years ago
I think this should block beta7, as we're advertizing it as a beta for add-on developers to test their add-ons against.
Ehsan, I cannot see this problem with todays build on my OS X and WinXP box. Are there some steps you have to do for preparation? Can you test with a fresh profile?
Whiteboard: [AOMTestday]
So the story here is that the current (and the currently-about-to-go-into-RC) Jetpack SDK does not support the packaged form of extension installation that we added by default in bug 533038. This is arguably an issue of needing to update extensions to support it and so normally I wouldn't say we'd block the release on it, but since we also own Jetpack and there is currently no solution there it is worthy of some consideration.We have some options on Firefox's side:We could just back out bug 533038. It's possible there are other regressions lurking from that but it really is needed to help us keep startup time down and not destroy developers with excessive caching.We could flip the switch to unpack all extensions for now or just for restartless extensions. This loses us real world testing though and also makes a bit of a lie of us saying the developers should test their extensions against b7 if we ever plan to flip it back to not unpacking in a later beta.We also have options on Jetpack's side:The SDK is probably fixable to support the packaged form, the couple of problems I could see at a swift glance are fairly easily fixable.The SDK could also, for now, just include em:unpack in the install.rdf to always unpack its extensions and then fix that later on.I believe that in the long run we're better off not making any changes to Firefox and getting a fix into the next SDK which is currently slated for release at end of next week. It may mean a short period where Jetpack developers can't get their add-ons to work in Firefox 4.0b7, but the Jetpack SDK is still considered to be in alpha and my understanding is that it is currently known to be broken in some ways on current nightlies anyway.
Blocks: 533038
OS: Mac OS X → All
Hardware: x86 → All
Summary: Installing a jetpack-based add-on fails → Jetpack SDK does not support packed extension installation
Whiteboard: [AOMTestday]
Whiteboard: [AOMTestday]
Making the SDK set em:unpack for the SDK 0.8 release happening next week seems like the best short term solution.  We can then fix the issues preventing SDK-based addons from working when packaged and remove that flag in a future release.
(Assignee)

Comment 10

8 years ago
(In reply to comment #9)
> Making the SDK set em:unpack for the SDK 0.8 release happening next week seems
> like the best short term solution.  We can then fix the issues preventing
> SDK-based addons from working when packaged and remove that flag in a future
> release.

Adding <em:unpack>false</em:unpack> to the install.rdf file doesn't seem to help.
(In reply to comment #10)
> (In reply to comment #9)
> > Making the SDK set em:unpack for the SDK 0.8 release happening next week seems
> > like the best short term solution.  We can then fix the issues preventing
> > SDK-based addons from working when packaged and remove that flag in a future
> > release.
> 
> Adding <em:unpack>false</em:unpack> to the install.rdf file doesn't seem to
> help.

You want <em:unpack>true</em:unpack>
I spoke with Johnathan and he agrees that this is something best fixed on Jetpack's side for now so moving over there.
blocking2.0: ? → -
Component: Add-ons Manager → Jetpack SDK
Product: Toolkit → Mozilla Labs
QA Contact: add-ons.manager → jetpack-sdk
Target Milestone: --- → 0.8
Blocks: 596524
(Assignee)

Comment 13

8 years ago
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Making the SDK set em:unpack for the SDK 0.8 release happening next week seems
> > > like the best short term solution.  We can then fix the issues preventing
> > > SDK-based addons from working when packaged and remove that flag in a future
> > > release.
> > 
> > Adding <em:unpack>false</em:unpack> to the install.rdf file doesn't seem to
> > help.
> 
> You want <em:unpack>true</em:unpack>

Right!
(Assignee)

Comment 14

8 years ago
Created attachment 476404 [details] [diff] [review]
Patch (v1)

This solves the problem for me.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #476404 - Flags: review?(myk)
Created attachment 476406 [details] [diff] [review]
mockup of support for packaged installs

So people don't have to redo my work so far, these are the two places I saw that get broken by the packaged install and rough untested ideas of how to fix them.
Comment on attachment 476404 [details] [diff] [review]
Patch (v1)

This looks great, r=myk; just asking Atul for feedback to get a second opinion on this approach to fixing the problem in the short term.

Also, I'm pretty sure packages/nsjetpack/components/install.rdf doesn't need this fix; Atul, is that right?
Attachment #476404 - Flags: review?(myk)
Attachment #476404 - Flags: review+
Attachment #476404 - Flags: feedback?(avarma)
(Assignee)

Comment 17

8 years ago
(In reply to comment #16)
> Also, I'm pretty sure packages/nsjetpack/components/install.rdf doesn't need
> this fix; Atul, is that right?

The comments in that file say that it's not a real install.rdf, that's why I didn't bother changing it.  :-)

Comment 18

8 years ago
Comment on attachment 476404 [details] [diff] [review]
Patch (v1)

Looks good--and that's correct, Myk, the other install.rdf in the nsjetpack package doesn't need to be updated.
Attachment #476404 - Flags: feedback?(avarma) → feedback+
(Assignee)

Comment 19

8 years ago
http://hg.mozilla.org/labs/jetpack-sdk/rev/0754e897a883
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 20

8 years ago
Is there a follow up bug to fix jetpack to handle things properly without unpacking? em:unpack is not recommended when it can be avoided as it's slower for startup.
Yup, I filed bug 597595 on the longer-term fix.
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.