579843 - Removing or disabling theme syncs, but doesn't apply to current window

Status: NEW

(Toolkit :: Add-ons Manager, defect, P3)

Description

[ahoza]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Build Identifier: 

When switching back to default theme on Client A and syncing, previously wore theme remains displayed in the client's B browser. 

Reproducible: Always

Steps to Reproduce:
Prerequisites: Two machines (client A and Client B) already setup on the same Weave account. For each client; Sync Preferences > Browser Sync > Minefield Will: is set to "Sync Everything" and "Merge sync data with sync data" for Manage Account-> Reset sync 

Environment
Client A: Win7(32), Mozilla/5.0 (Windows; Intel Mac OS X 10.6; en-US;
rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Client B: Mac 10.6, Mozilla/5.0 (Macintosh; Windows NT 6.1; en-US; rv:2.0b2pre)
Gecko/20100718 Minefield/4.0b2pre
Firefox Sync: 1.4.1

1. Install two personas on Client A, set one as default and sync.
2. Sync Client B. Enabled theme on Client A is enabled now on Client B as well.
3. Enable default theme on Client A and sync.
4. Sync Client B. 

Actual Results:  
Theme from step b is still displayed in browser window but in Addons Manager->Themes for the corresponding theme, "Enable" button is available. After restarting browser, Default theme is enabled.

Expected Results:  
Default theme should be enabled on Client B and displayed in the browser.

Comment 3

[Richard Newman [:rnewman]]

Removing regression keyword, because... well, it's probably not.

Comment 4

[Mike Connor [:mconnor]]

Yeah... we should just fix Fx5 to watch those prefs and do the right thing, not do it ourselves in the sync engine.  We couldn't do that while the add-on existed, but there's no reason to do this the hard way anymore.

Comment 5

[Allison Naaktgeboren :ally]

is this still an issue?

Comment 6

[Tracy Walker [:tracy]]

yes, still exists.

Comment 7

[Richard Newman [:rnewman]]

See comment 4.

Comment 9

[Tiziana Sellitto [:tiziana]]

I'm looking at old "good first bugs" not touched for a while. As for comment 6 it seems to be still valid.
Richard, do you think this bug could become a mentored bug? Perhaps this will catch somebody's attention.

Comment 10

[Richard Newman [:rnewman]]

As far as I know it's still valid, but it would be worth re-verifying -- it's been over a year.

Yes, this could be a mentored bug. It *probably* is a small fix: watch the right pref. I don't know who the right mentor is, alas.

Comment 11

[Tiziana Sellitto [:tiziana]]

I've re-verified it and the problem still occurs.

Comment 12

[Richard Newman [:rnewman]]

Guessing that all of these are affected. (Please correct if not!)

Comment 15

[Mike Hoye [:mhoye]]

Shopping around for a mentor for this. If this is still relevant in firefox-accounts-land, Dao, feel like taking that on?

Comment 16

[Dão Gottwald [:dao]]

I don't know if this bug is still relevant, why this bug would be happening (i.e. where exactly the code is broken), or that this qualifies as a good first bug...

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:robwu, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 19

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.