Closed Bug 645627 Opened 11 years ago Closed 11 years ago
.rdf needs <em:unpack>true</em:unpack> in order to use window icons
(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 . 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.  http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsBaseWidget.cpp?rev=8618a149ea2e&mark=1198,1207#1177
Attachment #522306 - Flags: review?
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+
Checked in. http://hg.mozilla.org/chatzilla/rev/29509afe3bf8 Thanks!
Status: NEW → RESOLVED
Closed: 11 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.
(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.