1370635 - Theme resets to Compact Light from Compact Dark when new window is opened if the firebug developer tools theme is in use

Status: RESOLVED DUPLICATE of bug 1389939

(DevTools :: General, defect, P2)

Description

[thomas_stanley]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

Open a new Firefox window (for Disqus login for example) or move a tab from existing window


Actual results:

Compact Dark theme is changed to Compact Light


Expected results:

Theme should not be affected when opening windows

Comment 1

[thomas_stanley]

Only seems to appear in 54.0 beta version, can't reproduce on FF 53.0

Comment 2

[:Gijs (he/him)]

I can't reproduce on either 54 or 55. Can you check on a clean profile? Is e10s on or off? Does the same thing happen if you open a new window with just "open new window" (cmd-N shortcut) ?

Comment 3

[thomas_stanley]

Using open new window function (cmd-N) or File -> New Window produces the same results.  I logged into a different user account on the Mac and the bug disappears, seems to be specific to my user account/profile.  E10s is enabled on both user accounts/profiles.

Comment 4

[:Gijs (he/him)]

(In reply to thomas_stanley from comment #3)
> Using open new window function (cmd-N) or File -> New Window produces the
> same results.  I logged into a different user account on the Mac and the bug
> disappears, seems to be specific to my user account/profile.  E10s is
> enabled on both user accounts/profiles.

Can you try Firefox's safe mode (Help > restart with add-ons disabled) inside Firefox and see if this makes it go away? Even if the problem requires an add-on to reproduce it might be a Firefox bug, but we'll need to find a way for other folks to reproduce if we want to fix it.

Comment 5

[thomas_stanley]

Restarted in Safe Mode and theme was reset to Compact Light when opening.  I switched manually back to Compact Dark and then used a cmd-N and the theme reset, same with File -> New Window (tested w/ New Private Window and same results).

Comment 6

[:Gijs (he/him)]

Brian, do you have any idea what else to try to figure out why this doesn't reproduce everywhere, or what's causing the bugginess?

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to :Gijs from comment #6)
> Brian, do you have any idea what else to try to figure out why this doesn't
> reproduce everywhere, or what's causing the bugginess?

I can't think of anything in particular that would be causing this.  I can think of two things to might help debug:

1) The main difference between this and other lightweight themes is that we have some bidirectional syncing between this and the `devtools.theme` pref. If the devtools.theme pref changes, then we also switch the compact theme here: https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/devtools-browser.js#166-182.  While if the compact theme changes, then we switch the devtools.theme pref here: https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/devtools-browser.js#213-224. So I'd be curious to see the value of both lightweightThemes.selectedThemeID and devtools.theme prefs before and after the new window is opened.
2) I wonder if other lightweight themes get reset as well  So in the primary window if you go to Customize Mode -> Themes -> Pastel Gradient than exit customize mode, does opening a new window change the LWT (either removing it or switching to Compact Light)?

Comment 8

[Gianluca]

(In reply to Brian Grinstead [:bgrins] from comment #7)
> 1) The main difference between this and other lightweight themes is that we
> have some bidirectional syncing between this and the `devtools.theme` pref.
> If the devtools.theme pref changes, then we also switch the compact theme
> here:
> https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/
> devtools-browser.js#166-182.  While if the compact theme changes, then we
> switch the devtools.theme pref here:
> https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/
> devtools-browser.js#213-224. So I'd be curious to see the value of both
> lightweightThemes.selectedThemeID and devtools.theme prefs before and after
> the new window is opened.

Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Safe mode, and e10s are on.

Before (cmd-N):
lightweightThemes.selectedThemeID;[e-mail]
devtools.theme;firebug

After (cmd-N):
lightweightThemes.selectedThemeID;[e-mail]
devtools.theme;firebug

I wonder if the comment and the code are in sync here (https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/devtools-browser.js#158-175). Could it be that a devtoolsTheme == "firebug" could have caused the issue, and has already been removed ?

Comment 9

[:Gijs (he/him)]

comment 8 is in the right direction, I think. Specifically, AFAICT we normalize the firebug theme to be equivalent to the light theme here: https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/devtools/client/framework/devtools-browser.js#145-148

but not when syncing in the other direction, here: https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/devtools/client/framework/devtools-browser.js#205-216

so when opening a new window, or starting the browser, the syncing from the devtools pref to the lwtheme switches to a light lwtheme, but when switching to the dark lwtheme, we don't change the devtools pref because we check if it's set to 'light', and don't consider 'firebug' a 'light' version.

Allowing to mix and match light devtools and dark Firefox themes (or vice versa) without the bidirectional sync is bug 1380703. See also bug 1379778 which I think weakens the case for the bidirectional sync here.

Comment 10

[LucileDT]

I have the exact same problem :( I'm on a different OS though, do I need to open a new bug report?

-----------
Scenario 1:
-----------
- Open Firefox
- Go to Menu > Add ons > Appearance
- Activate the Compact light theme
- Activate the compact dark theme
- Close Firefox
- Open Firefox

Current behaviour:
- Firefox opens with Compact dark theme
- The theme switch on Compact light theme under my eyes without any action from me

-----------
Scenario 2:
-----------
- Open Firefox
- Go to Menu > Add ons > Appearance
- Activate the Compact light theme
- Activate the compact dark theme
- Open a new Firefox page 

Current behaviour:
- The new page opens with Compact dark theme
- The theme switch on Compact light theme under my eyes without any action from me

-------------------
Useful information:
-------------------
- If I restart Firefox in Safe mode, the behaviour is the same
- I have Firebug installed

Comment 11

[:Gijs (he/him)]

(In reply to LucileDT from comment #10)
> I have the exact same problem :( I'm on a different OS though, do I need to
> open a new bug report?

No, we're well aware of this issue - thank you!

Comment 12

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0

Hello,

I have tested your issue on latest Firefox release (55.0.2 x64), latest Nightly build (20170823100553) and managed to reproduce it in a different way on Windows 10, Ubuntu 14.04 and Mac OS 10.12.6.

Steps to reproduce:

1. Open Firefox
2. Go to Menu > Add ons > Appearance
3. Activate the Compact light theme
4. Activate the Compact dark theme
5. Click Shift + F2

Current behavior:
- Firefox opens with Compact dark theme
- The theme switches on Compact light theme after clicking Shift + F2


Last good revision: 449c8d0f859e22bc4d6237bec3804e056e9e0402
First bad revision: d33c5f14a37df560a9e399f2cdc09465a9340f15 
Pushlog (from regression range): https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=449c8d0f859e22bc4d6237bec3804e056e9e0402&tochange=d33c5f14a37df560a9e399f2cdc09465a9340f15

Hey :bgrins, can you take a look at this?

Comment 13

[:Gijs (he/him)]

This is being fixed in bug 1389939.

Comment 14

[Ethan Tseng [:ethan]]

Mirror the status of bug 1389939.

One caveat, bug 1389939 said both 56 and 57 were affected and verified fixed.
However, this bug said 56 was unaffected.