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

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[:Mook]

Attachment: add em:unpack

(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.

[1] http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsBaseWidget.cpp?rev=8618a149ea2e&mark=1198,1207#1177

Comment 1

[James Ross]

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).

Comment 2

[:Mook]

Checked in. http://hg.mozilla.org/chatzilla/rev/29509afe3bf8 Thanks!

Comment 3

[Robert Kaiser]

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.

Comment 4

[James Ross]

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

Comment 5

[:Mook]

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)

Comment 6

[Robert Kaiser]

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.

Comment 7

[James Ross]

Is there a bug for that?

Comment 8

[Robert Kaiser]

(In reply to comment #7)
> Is there a bug for that?

No idea.

Comment 9

[Tony Mechelynck [:tonymec]]

(In reply to comment #8)
> (In reply to comment #7)
> > Is there a bug for that?
> 
> No idea.

bug 664309