522188 - lightweight theme install doesn't "stick"

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Will Roberts [:bws42]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre

1. Go to http://www.getpersonas.com
2. Install a persona.
3. Hover over another persona, it should change as expected.
4. Mouse away from the persona, it should revert to the persona installed in #1.
5. Install a new persona, it should change as expected.
6. Hover over any persona, then move away, the theme will revert to persona installed in #1 instead of #5.

The Theme manager (UI) thinks that the correct persona is installed (see attached pic).

Reproducible: Always

Comment 1

[Will Roberts [:bws42]]

Attachment: shot showing the theme UI versus the actual UI

I did not investigate a regression range since the functionality is so new.

Comment 2

[[not reading bugmail]]

I noticed this too, but only happened if I was also running GetPersonas Addon which takes ownership before LWThemes in Theme manager.  Are you running GetPersonas too?  And if so, try uninstalling that and checking STR.

Comment 3

[Will Roberts [:bws42]]

I have never installed the personas add-on. This also happens on my Linux x64 machine at work so I'm setting the platform to All.

Comment 4

[Dão Gottwald [:dao]]

Likely a regression from bug 516013.

Comment 5

[Dão Gottwald [:dao]]

Ah, I fixed that locally but apparently that's not the version I attached in the bug and landed.

Comment 6

[Dão Gottwald [:dao]]

Attachment: patch

I also tried and failed to manually evict the cache entries for the local files...

Comment 7

[Dave Townsend [:mossop]]

I think this is an over-complicated fix. nsIXULChromeRegistry.reloadChrome might do the job on its own. Alternately wouldn't it be simpler to keep everything as-is but append the theme ID on the end of the url rather than storing a hash?

Comment 8

[Dão Gottwald [:dao]]

(In reply to comment #7)
> nsIXULChromeRegistry.reloadChrome might do the job on its own.

I can try that.

> Alternately wouldn't it be simpler to keep
> everything as-is but append the theme ID on the end of the url rather than
> storing a hash?

This would reload the image when opening a new window.

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #8)
> > Alternately wouldn't it be simpler to keep
> > everything as-is but append the theme ID on the end of the url rather than
> > storing a hash?
> 
> This would reload the image when opening a new window.

Why? The theme ID never changes

Comment 10

[Dão Gottwald [:dao]]

Oh, yeah, the id. I was thinking of moving Date.now() there.

Comment 11

[Dão Gottwald [:dao]]

reloadChrome appears to be completely broken...

Comment 12

[Dão Gottwald [:dao]]

I tried sending the chrome-flush-caches notification myself, but that doesn't affect these images.

Comment 13

[Dão Gottwald [:dao]]

Attachment: alternative patch

This works, but it means that we won't reload the images when installing the same theme again with potential changes to the images.

Comment 15

[Tony Chung [:tchung]]

This seems to be fixed for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b5pre) Gecko/20091202 Namoroka/3.6b5pre 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091202 Minefield/3.7a1pre.  

i havent seen any lightweight themes not "stick" lately.  If you still experience this, please reopen and list repro steps.  Thanks.