Closed Bug 645627 Opened 12 years ago Closed 12 years ago

install.rdf needs <em:unpack>true</em:unpack> in order to use window icons


(Other Applications :: ChatZilla, defect)

Not set


(Not tracked)



(Reporter: Mook, Assigned: Mook)




(Whiteboard: [cz-0.9.87])


(1 file)

580 bytes, patch
: review+
Details | Diff | Splinter Review
Attached patch add em:unpackSplinter Review
(See linked MDC documentation)

install.rdf needs a new <em:unpack> setting in order to make sure the exntension gets unpacked (rather than left as a compressed .xpi).  This is only necessary because window icons don't work unless they're flat files, see [1].

This should have no backward-compatibility impact (since older platform versions will ignore the setting).  This may have startup impact (since theoretically, unpacked extensions take longer to load), but not more so than Gecko < 2.0.

Attachment #522306 - Flags: review?
Attachment #522306 - Flags: review? → review?(silver)
Comment on attachment 522306 [details] [diff] [review]
add em:unpack

Looks good, plus AMO is saying "add-on meets criteria that would indicate performance issues if <em:unpack> is not set to true" (although is entirely neglects to explain what those criteria are).
Attachment #522306 - Flags: review?(silver) → review+
Assignee: rginda → mook.moz+mozbz
Checked in. Thanks!
Closed: 12 years ago
Resolution: --- → FIXED
Note that 1) this makes performance worse and 2) we explicitely tried to not do this on SeaMonkey - and I think the new way of installing built-in add-ons with copying from the app dir to the profile also doesn't unpack, even if the add-on says so.
Performance of what (I'd guess installation)? AMO is claiming performance (unspecified) would be improved (I'd guess runtime).

I'd much rather take a performance hit to get useful features back. :P
Well, in theory we'd have more files to read, so startup will be slower.  Except that there are two things of relevance not in the jar - the JS component (which should hopefully be fastloaded), and the icons (which we can't stick in a zip file, see, err, this bug).  The rest in the jar, but even that shouldn't matter since it would be in the startup cache for the majority of the time.

I would argue that installing the addon without unpacking would be a bug, since in that case any addons with binary components would not work, rather than the ChatZilla case of just missing an icon.  (And if the icon loading gets fixed, it will then need to decompress that zip file in memory to find the icon to load... and completely ignoring the rest of the archive)
SeaMonkey can't install it unpacked in the in-app delivered method, as toolkit doesn't support unpacking add-ons when copying them from distribution/extensions/ to the profile. Just as a note.
Is there a bug for that?
(In reply to comment #7)
> Is there a bug for that?

No idea.
Blocks: 664309
Whiteboard: [cz-0.9.87]
(In reply to comment #8)
> (In reply to comment #7)
> > Is there a bug for that?
> No idea.

bug 664309
You need to log in before you can comment on or make changes to this bug.