968541 - When upgrading bootstrapped add-ons, XUL icons are not updated

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Peter J. Sloetjes]

Attachment: RestartlessRestart_red.xpi

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140127194636

Steps to reproduce:

I created several bootstrapped extensions that occasionally contained a modified icon set for their XUL toolbar buttons or other widgets.


Actual results:

Upon upgrading the extensions, these icons were not updated.


Expected results:

All resources should be reloaded upon installation.

I created "RestartlessRestart_red.xpi" (with all icons in red instead of black), which for testing may be installed after installing the default "RestartlessRestart.xpi" (see AMO).

P.S. If this bug is known to occur for certain configuration settings, please let me know which.

Comment 1

[Peter J. Sloetjes]

Attachment: RestartlessRestart_black.xpi

This is the unmodified version of "RestartlessRestart.xpi", to be used for testing in combination with "RestartlessRestart_red.xpi".

Comment 2

[:Gijs (out for now; he/him)]

I'm not sure where this belongs, but it's almost certainly not Widgets/XUL. It's more likely to be either an add-on manager bug (which would be Toolkit > Add-on Manager), component manager (Core... somewhere?) or networking/images/jar (also all in Core). I'm marking this as Fx General for now - I'll try to find time to investigate this later today or this week, but I'm a bit backlogged after a week's holiday...

Comment 3

[Peter J. Sloetjes]

It's probably an image caching/updating bug. Most often, it will lead to wrong or absent icons, but it can also lead to toolbar buttons that display a potentially very large image sprite (e.g. when switching to a non-sprite image for which a -moz-image-rect rule is no longer needed).

Please note that I am not sure whether this bug occurs in the case of automatic upgrades, perhaps I can devise a test for that. If upgrades always occur at the start of a session, then users don't experience this bug and only developers are affected.

Comment 4

[Peter J. Sloetjes]

This issue does also occur when an update is forced via the Add-ons Manager, so users are not immune to it. Also, developers cannot prevent this issue by setting 'nglayout.debug.disable_xul_cache' to 'true'.

Comment 5

[:Gijs (out for now; he/him)]

Actually, I don't think I have time to look at this in the near future, with 29 so near release and the number of pressing issues there so high, and the fact this has clearly been broken for a while (perhaps even since bootstrapped add-ons were first introduced). However, I think this should be in the backlog - it's a serious issue with bootstrapped add-ons and can lead to confusing bugs. The testcase should make it easy to look at this in more detail, and find a better home for it if it's not a fx frontend bug (which is reasonably likely) and then to get it fixed.

Comment 6

[Peter J. Sloetjes]

Yeah, let's find a better home for this issue, where it can age, and live forever.
Why wasn't this issue fixed immediately when bootstrapped add-ons were introduced?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

(In reply to Peter J. Sloetjes from comment #6)
> Yeah, let's find a better home for this issue, where it can age, and live
> forever.
> Why wasn't this issue fixed immediately when bootstrapped add-ons were
> introduced?

It's possible that it's a recent regression. Perhaps you'd care to help us find a regression range?

Comment 8

[Peter J. Sloetjes]

This problem is present in Firefox ESR10 & ESR17 as well. As far as I know, it extends back to version 4.0 (if you will trust my memory). It is probably one of those loose ends from what is mentioned as "The part about stale caches after an add-on update presents a painful problem." in "http://starkravingfinkle.org/blog/2011/01/restartless-add-ons-more-resources/". 

Now we know the regression range, we might also want to know its extent. Please provide us with a test case which clarifies whether this problem is absent or present with current SDK-based add-ons.

Comment 9

[Mark Banner (:standard8)]

Support for legacy add-ons has now been removed, and we've moved to WebExtensions, if this is still an issue there, please file a new bug.