Closed Bug 1549075 Opened 7 months ago Closed 6 months ago

Nightly 68.0a1 (2019-05-04) is broken: Address bar not functioning, about:newtab blank

Categories

(Firefox :: General, defect, P1, blocker)

68 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox68 blocking fixed

People

(Reporter: flod, Assigned: aswan)

References

(Regression)

Details

(Keywords: dogfood, regression, Whiteboard: cert2019)

Attachments

(5 files, 2 obsolete files)

Work-around

While the bug is fixed, removing addonStartup.json.lz4 from your profile should fix the problem

Original bug

I've managed to updated my nightly to 68.0a1 (2019-05-04) (64 bit)

Build config points to
Built from https://hg.mozilla.org/mozilla-central/rev/9419be649effc5bc67eb3d6fce1db46caa7fae7e

Address bar is completely broken, console has

Error: Something tried to use the search service before it's been properly intialized. Please examine the stack trace to figure out what and where to fix it:
_ensureInitialized@resource://gre/modules/SearchService.jsm:709:15
get defaultEngine@resource://gre/modules/SearchService.jsm:2264:10
_getUrlMetaData@resource:///modules/UrlbarValueFormatter.jsm:111:35
_formatURL@resource:///modules/UrlbarValueFormatter.jsm:196:28
update@resource:///modules/UrlbarValueFormatter.jsm:64:12
formatValue@resource:///modules/UrlbarInput.jsm:252:27
_on_blur@resource:///modules/UrlbarInput.jsm:1272:10
handleEvent@resource:///modules/UrlbarInput.jsm:305:23
_adjustFocusBeforeTabSwitch@chrome://browser/content/tabbrowser.js:1150:32
updateDisplay@resource:///modules/AsyncTabSwitcher.jsm:415:23
postActions@resource:///modules/AsyncTabSwitcher.jsm:618:10
queueUnload@resource:///modules/AsyncTabSwitcher.jsm:1026:10
requestTab@resource:///modules/AsyncTabSwitcher.jsm:1015:10
updateCurrentBrowser@chrome://browser/content/tabbrowser.js:922:29
_setupEventListeners/<@chrome://browser/content/tabbrowser.js:4519:14
set selectedIndex@chrome://global/content/elements/tabbox.js:192:12
set selectedPanel@chrome://global/content/elements/tabbox.js:206:5
set_selectedIndex@chrome://global/content/bindings/tabbox.xml:177:15
set_selectedItem@chrome://global/content/bindings/tabbox.xml:202:39
_selectNewTab@chrome://global/content/bindings/tabbox.xml:296:11
onxblmousedown@chrome://global/content/bindings/tabbox.xml:446:27

Default themes are disabled, context menu show all elements. And there's probably more broken.

I'm seeing this on macOS, not sure if other platforms are broken too.

Nightly updates are disabled for this.

:jlorenzo is seeing the same on macOS en-US.

This is interesting: a new profile seems to be working fine with the same Nightly.

For what's it's worth, removing addonStartup.json.lz4 from the profile let me start Nightly as normal.

Attached file addonStartup.json.lz4

Attaching the file here, in case it's helpful for someone to debug.

(In reply to Francesco Lodolo [:flod] from comment #3)

For what's it's worth, removing addonStartup.json.lz4 from the profile let me start Nightly as normal.

Confirmed, thanks! (Nightly 20190504100003 de_DE rev 9419be649effc5bc67eb3d6fce1db46caa7fae7e on Debian Testing.)

Attached file search.json.mozlz4
Has Regression Range: --- → no
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Nightly 68.0a1 (2019-05-04) is broken: no theme, address bar not functioning → [nightly updates disabled] Nightly 68.0a1 (2019-05-04) is broken: no theme, address bar not functioning

I'm running 20190502095227 on macOS en-US and don't see the problem.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=03166449953fbcaaf6c66d2c3b358319781a0e52&tochange=9419be649effc5bc67eb3d6fce1db46caa7fae7e

Checking last builds manually:

mozregression --repo mozilla-central --launch c68ff92fe54c75338c3a937bc6c4e615d9b1d45a --profile /tmp/test-profile
=> just to get a profile folder

mozregression --repo mozilla-central --launch eb5b01e0b309d50231f2412721353b1183aff117 --profile /tmp/test-profile
=> reused profile is good

mozregression --repo mozilla-central --launch e9bfe907b847e08e7fe89e12e6d86aa6115c99d9 --profile /tmp/test-profile
=> reused profile is bad (about:newtab has empty tiles + awesome bar does not work)

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eb5b01e0b309d50231f2412721353b1183aff117&tochange=e9bfe907b847e08e7fe89e12e6d86aa6115c99d9

Using a profile made with e9bfe907b847e08e7fe89e12e6d86aa6115c99d9 with previous build eb5b01e0b309d50231f2412721353b1183aff117 is likewise broken.

Has Regression Range: no → yes
Regressed by: 1549010

So, some STR:

  1. Run Firefox for a while. Go to about:preferences and tell Firefox to open your session from last time. Go to a few web sites.
  2. Shut down Firefox.
  3. Bump the DB_SCHEMA number in toolkit/mozapps/extensions/internal/XPIProvider.jsm by one value
  4. Rebuild, and restart, using the same profile as used in (1)
  5. Type something into the URL bar

ER:

The URL bar dropdown should appear and display search suggestions, as well as the search icons at the bottom.

AR:

The URL bar panel never appears.

Using the STR in comment 10, I can reproduce this reliably on Nightly, but cannot reproduce it on Release or Beta. This seems to be related to the OpenSearch-to-WebExtensions work in bug 1486820.

Regressed by: 1486820

My STR are a little simpler:

  1. Start Firefox with a clean profile. Wait a few second and exit.
  2. Bump the DB_SCHEMA and rebuild.
  3. Restart Firefox with the same profile.

The new tab page will have empty top-sites.

The issue seems to be a deadlock, while initializing the search service we detect that the cache is outdated and rebuild causing us to reinstall the built-in add-ons: https://searchfox.org/mozilla-central/source/toolkit/components/search/SearchService.jsm#1111

Which then gets to here which waits on the search service to initialize: https://searchfox.org/mozilla-central/source/browser/components/extensions/parent/ext-chrome-settings-overrides.js#343

Here's a stack for the deadlock:

addSearchEngine@chrome://browser/content/parent/ext-chrome-settings-overrides.js:344:24
processSearchProviderManifestEntry@chrome://browser/content/parent/ext-chrome-settings-overrides.js:285:16
onManifestEntry@chrome://browser/content/parent/ext-chrome-settings-overrides.js:242:14
async*asyncEmitManifestEntry@resource://gre/modules/ExtensionCommon.jsm:1421:18
async*runManifest@resource://gre/modules/Extension.jsm:1770:31
startup@resource://gre/modules/Extension.jsm:1983:14
async*startup@resource://gre/modules/Extension.jsm:1319:27
callBootstrapMethod@resource://gre/modules/addons/XPIProvider.jsm:1742:33
startup@resource://gre/modules/addons/XPIProvider.jsm:1841:32
_install@resource://gre/modules/addons/XPIProvider.jsm:1914:18
async*update@resource://gre/modules/addons/XPIProvider.jsm:1986:17
async*_activateAddon@resource://gre/modules/addons/XPIInstall.jsm:3802:54
async*installBuiltinAddon@resource://gre/modules/addons/XPIInstall.jsm:3743:16
async*XPIProvider[meth]@resource://gre/modules/addons/XPIProvider.jsm:2888:28
installBuiltinAddon@resource://gre/modules/AddonManager.jsm:1972:33
installBuiltinAddon@resource://gre/modules/AddonManager.jsm:3294:33
_loadEngines@resource://gre/modules/SearchService.jsm:1111:30
async*_init@resource://gre/modules/SearchService.jsm:746:18
async*init@resource://gre/modules/SearchService.jsm:1821:18
getDefault@resource://gre/modules/SearchService.jsm:2354:16
delayedStartupInit@chrome://browser/content/browser.js:3997:21
_delayedStartup@chrome://browser/content/browser.js:1647:19
EventListener.handleEvent*onLoad@chrome://browser/content/browser.js:1573:12
EventHandlerNonNull*@chrome://browser/content/browser.xul:105:39

So using STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1549075#c12, I can see https://i.imgur.com/041MrcF.png

From what I can tell, the DB_SCHEMA bump is 'breaking' how things interact with the addon manager, this means if SearchService tries to use the AddonManager (which it very often will) it will also break, but its not the cause of the theme breaking (in my screenshot SearchService loaded from cache and works fine)

Attached video 2019-05-04_22-03-58.mp4

Debian Testing, KDE, X11, Macbook Pro
State of broken Nightly with STR from comment 9, as encountered in real life today.

  • empty tiles on about:newtab
  • address bar/awesomebar mostly broken. It's only possible to open links typed in with scheme.
  • empty search engine dropdown on about:preferences#search
  • all themes are force-disabled

Multiple restarts do not help. Fixable with workaround from comment 3. Fresh profiles are fine.

Summary: [nightly updates disabled] Nightly 68.0a1 (2019-05-04) is broken: no theme, address bar not functioning → [nightly updates disabled] Nightly 68.0a1 (2019-05-04) is broken: Address bar not functioning, about:newtab blank

So @mixedpuppy is looking into fixing the deadlock with the SearchService that Mossop identified in https://bugzilla.mozilla.org/show_bug.cgi?id=1549075#c12

I filed a new bug about the theme being broken as while it has a similiar cause (the DB_SCHEMA upgrade), it not related to the SearchService deadlock

Both theme and search extensions are using the builtinLocation class (aka "app-builtin"). Extensions using this do not have a regular patch, so when the XPI DB_SCHEMA is updated, they are not updated properly. The result is that builtin themes and search engines are broken.

STR

  • do an artifact build
  • create a new profile
  • start firefox
  • change theme to dark them
  • note that search engines have icons
  • shutodown
  • increment DB_SCHEME in XPIProvider.jsm, rebuild
  • startup

expected:

you have the dark theme and search icons appear in urlbar

actual:

you do not have the dark theme and there are no search icons
There is potentially other fallout, newtab broken to various extent, urlbar not working at all

Duplicate of this bug: 1549109
Duplicate of this bug: 1549121

On Android, I've observed this to
a) effectively disable the currently active (user-installed) theme (it's still showing as active in the add-on manager, but doesn't actually work), and
b) uninstall [1] all disabled themes (which will include all user-installed themes except for the one that's possibly enabled).

[1] I've checked in the profile directory - the affected themes really are gone for good.

Attachment #9062746 - Attachment description: Bug 1549075 update addon compatibility for builtin extensions → Bug 1549075 update builtin addon metadata when the XPI database is rebuilt
Attachment #9062754 - Attachment description: Bug 1549075 first cut → Bug 1549075 Don't blow up on builtin addons while rebuilding the extensions database r=kmag
Pushed by aswan@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/74e72eb8369d
Don't blow up on builtin addons while rebuilding the extensions database r=kmag a=lizzard CLOSED TREE
Pushed by maglione.k@gmail.com:
https://hg.mozilla.org/mozilla-central/rev/7995904ca18e
Follow-up: Fix ESLint bustage on a CLOSED TREE. a=bustage

Various comments with STR mention changing DB_SCHEMA, but this can be tested without changing source code.

First, the rough steps are:

  1. Create a new profile with an "old" build, change to the dark theme, exit Firefox.
  2. Start a newer Firefox with the same profile.
  3. If the bug is fixed, the dark theme should still be applied, and the top stories entries on about:newtab should all be populated. Those things will be broke if the bug is present.

Now, the relevant commits are https://hg.mozilla.org/mozilla-central/rev/e9bfe907b847e08e7fe89e12e6d86aa6115c99d9 (corresponding to nightly buildid 20190503215639 and anything earlier than that)
and https://hg.mozilla.org/mozilla-central/rev/7995904ca18e2d85e768bc4317c56c1cddff44aa (no shipped nightlies with that patch yet)
The one nightly that we shipped between those commits has buildid 20190504100003

We should verify at least two things:

  1. updates from 20190503215639 or earlier to recent builds work smoothly (ie the bug is not present when following the STR above)
  2. updates from something old to 20190504100003 exhibit the bug, but then updating again to a recent build makes the bug disappear (ie repeating steps 2 and 3 again on a recent build make the bug vanish)
Pushed by aswan@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/445c0c44fa89
Follow-up: Fix system addon test on CLOSED TREE r=kmag a=bustage

Upgrade with broken profile: Still broken.
mozregression --repo mozilla-central --launch eb5b01e0b309d50231f2412721353b1183aff117 --profile /tmp/fix-test
=> last good (comment 9): set to dark theme

mozregression --repo mozilla-central --launch e9bfe907b847e08e7fe89e12e6d86aa6115c99d9 --profile /tmp/fix-test
=> first bad (comment 9): broken as expected

mozregression --repo mozilla-central --launch 445c0c44fa894aadf3ebf849fef5bdb0aa4c547d --profile /tmp/fix-test
=> Build from comment 26: not fixed, still broken as seen in comment 15

Upgrade with profile of "last good" build: Regression still occurs.
mozregression --repo mozilla-central --launch eb5b01e0b309d50231f2412721353b1183aff117 --profile /tmp/fix-test2
=> last good (comment 9): set to dark theme

mozregression --repo mozilla-central --launch 445c0c44fa894aadf3ebf849fef5bdb0aa4c547d --profile /tmp/fix-test2
=> Build from comment 26: regression as seen in comment 15 still occurs

Observing the same issue like Jan:
Created a new profile with Nightly 20190503041749: firefox.exe -no-remote -P
Launched it with that Firefox.
Launched it with the latest Nightly build: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&searchStr=windows%2Cbuild&revision=7620ecc6c5349a3808aa915757dd5c36421d8433&selectedJob=244721760

All search engines except Amazon are shown as disabled on about:support but even Amazon isn't shown in the search bar or the dropdown of search engines in Options > Search > Default Search Engine.

Flags: needinfo?(dharvey)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Priority: -- → P1

OK, so when we hit:

https://searchfox.org/mozilla-central/rev/06578bfadb5bdc5faee81f7e9b3c3fed21e616e0/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#2679-2697

    // Update the add-on's database metadata from on-disk metadata if:
    //
    //  a) The add-on was staged for install in the last session,
    //  b) The add-on has been modified since the last session, or,
    //  c) The app has been updated since the last session, and the
    //     add-on is part of the application bundle (and has therefore
    //     likely been replaced in the update process).
    if (newAddon ||
        oldAddon.updateDate != xpiState.mtime ||
        (aUpdateCompatibility && this.isAppBundledLocation(installLocation))) {
      newAddon = this.updateMetadata(installLocation, oldAddon, xpiState, newAddon);
    } else if (oldAddon.path != xpiState.path) {
      newAddon = this.updatePath(installLocation, oldAddon, xpiState);
    } else if (aUpdateCompatibility || aSchemaChange) {
      newAddon = this.updateCompatibility(installLocation, oldAddon, xpiState,
                                          aSchemaChange);
    } else {
      newAddon = oldAddon;
    }

at startup, we take the if (aUpdateCompatibility || aSchemaChange) { for builtin add-ons. This is bad because then we take the updateCompatibility path which goes to:

https://hg.mozilla.org/mozilla-central/file/7620ecc6c5349a3808aa915757dd5c36421d8433/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#l2582

(searchfox hasn't updated)

    let manifest = null;
    if (checkSigning || aReloadMetadata) {
      try {
        manifest = XPIInstall.syncLoadManifest(aAddonState, aLocation);
      } catch (err) {
        // If we can no longer read the manifest, it is no longer compatible.
        aOldAddon.brokenManifest = true;
        aOldAddon.appDisabled = true;
        return aOldAddon;
      }
    }

where we don't pass aOldAddon to syncLoadManifest, which means we throw at:

https://hg.mozilla.org/mozilla-central/file/74e72eb8369d8f494be2943cbf010d072d3e266c/toolkit/mozapps/extensions/internal/XPIInstall.jsm#l645

function syncLoadManifest(state, location, oldAddon) {
  if (location.name == "app-builtin") {
    let pkg = builtinPackage(Services.io.newURI(oldAddon.rootURI));
    return XPIInternal.awaitPromise(loadManifest(pkg, location, oldAddon));
  }
  ...

because oldAddon is null. There are no exceptions because as shown in the second snippet, we just try...catch and swallow the error. The test does not catch this because it tests an app version change instead of a schema change, so in the first snippet we take the first branch (calling updateMetadata instead of updateCompatibility).

https://hg.mozilla.org/mozilla-central/rev/445c0c44fa89 has 3 calls to syncLoadManifest, only 1 of which passes an oldAddon.

It's not super clear to me what the best course of action is. Some options:

  1. calling updateCompatibility for builtin add-ons seems wrong, so we could make it take the first branch as per suggestions in https://phabricator.services.mozilla.com/D29952 .
  2. pass aOldAddon along in this case (it doesn't look like we have access to an old addon ref in the addMetadata case).
  3. ensure syncLoadManifest behaves sanely if oldAddon is null.

Today's Firefox Nightly (2019-05-05) works for me (bug 1549061 comment 17). Thanks!

Pushed by aswan@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/e5ed24b52564
Follow-up Fix loading built in manifests r=zombie a=pascalc CLOSED TREE

Upgrade with broken profile: Fixed.
mozregression --repo mozilla-central --launch eb5b01e0b309d50231f2412721353b1183aff117 --profile /tmp/fix-test3
=> last good (comment 9): set to dark theme & duckduckgo

mozregression --repo mozilla-central --launch e9bfe907b847e08e7fe89e12e6d86aa6115c99d9 --profile /tmp/fix-test3
=> first bad (comment 9): broken as expected

mozregression --repo mozilla-central --launch e5ed24b52564b6a41fd6a4eadde8e8832c4b91c1 --profile /tmp/fix-test3
=> Build from comment 35: Fixed, dark theme & duckduckgo restored.

Upgrade with profile of "last good" build: Fixed.
mozregression --repo mozilla-central --launch eb5b01e0b309d50231f2412721353b1183aff117 --profile /tmp/fix-test4
=> last good (comment 9): set to dark theme & duckduckgo

mozregression --repo mozilla-central --launch e5ed24b52564b6a41fd6a4eadde8e8832c4b91c1 --profile /tmp/fix-test4
=> Build from comment 35: Fixed, dark theme & duckduckgo restored.

Thank you!

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

:-)

Assignee: gijskruitbosch+bugs → aswan
Summary: [nightly updates disabled] Nightly 68.0a1 (2019-05-04) is broken: Address bar not functioning, about:newtab blank → Nightly 68.0a1 (2019-05-04) is broken: Address bar not functioning, about:newtab blank

I think that when we get down to the cause of this, any fixes should land in a separate bug. But lets keep the conversation here now for continuity.
Pike reported on Slack that at the moment he uses the broken URL bar, this exception appears:

Error: Something tried to use the search service before it's been properly intialized. Please examine the stack trace to figure out what and where to fix it:
_ensureInitialized@resource://gre/modules/SearchService.jsm:709:15
get defaultEngine@resource://gre/modules/SearchService.jsm:2264:10
_getUrlMetaData@resource:///modules/UrlbarValueFormatter.jsm:111:35
_formatURL@resource:///modules/UrlbarValueFormatter.jsm:196:28
update@resource:///modules/UrlbarValueFormatter.jsm:64:12
formatValue@resource:///modules/UrlbarInput.jsm:252:27
_on_blur@resource:///modules/UrlbarInput.jsm:1272:10
handleEvent@resource:///modules/UrlbarInput.jsm:305:23
_adjustFocusBeforeTabSwitch@chrome://browser/content/tabbrowser.js:1150:32
updateDisplay@resource:///modules/AsyncTabSwitcher.jsm:415:23
postActions@resource:///modules/AsyncTabSwitcher.jsm:618:10
queueUnload@resource:///modules/AsyncTabSwitcher.jsm:1026:10
requestTab@resource:///modules/AsyncTabSwitcher.jsm:1015:10
updateCurrentBrowser@chrome://browser/content/tabbrowser.js:922:29
_setupEventListeners/<@chrome://browser/content/tabbrowser.js:4519:14
set selectedIndex@chrome://global/content/elements/tabbox.js:192:12
set selectedPanel@chrome://global/content/elements/tabbox.js:206:5
set_selectedIndex@chrome://global/content/bindings/tabbox.xml:177:15
set_selectedItem@chrome://global/content/bindings/tabbox.xml:202:39
set selectedTab@chrome://global/content/elements/tabbox.js:85:9
set selectedTab@chrome://browser/content/tabbrowser.js:271:5
_blurTab@chrome://browser/content/tabbrowser.js:3209:29
_beginRemoveTab@chrome://browser/content/tabbrowser.js:2911:10
removeTab@chrome://browser/content/tabbrowser.js:2819:15
onxblclick@chrome://browser/content/tabbrowser.xml:2431:22
SearchService.jsm:709:15

I suspect this happens far enough into startup that something else earlier caused search initialization to fail quietly.

We also have empirical reports that after multiple startups in the same profile, the bug eventually stops occurring. A half-baked theory is that for each built-in engine, something fails during startup, but does manage to make some progress (e.g., adding to the search cache it or changing some bit of its state in the search cache?) so that that particular engine doesn't fail in the next startup. As a result, after one failed startup per built-in engine, we finally arrive in a working state.

Also empirically, this doesn't seem to be hitting the majority of Nightly users so we've restarted updates but may stop them again if this appears to be widespread.

Dale, sorry there isn't more to go on here, but can you make this a high priority on Monday?

Duplicate of this bug: 1549240

After some restarts with previous versions, I got to a point where the navigation bar was working again, and only Amazon.com search engine was enabled.

Now I've applied the latest upgrade to the nightly and I'm back to non-working navigation bar, no search engines listed in the preferences.

What's different now, is in about:support I see only "DuckDuckGo" and "Wikipedia (en)" as disabled, where previously all were disabled, except Amazon.com and Bing (but only Amazon was actually available to use)

The error "Error: Something tried to use the search service before it's been properly intialized." is still produced when using the nav bar

See Also: → 1549122
Attachment #9062794 - Attachment is obsolete: true
Duplicate of this bug: 1549074
Depends on: 1549277
Duplicate of this bug: 1549320
Duplicate of this bug: 1549291

Between the fixes that landed here and in bug 1549122, I believe this can be verified fixed. Axel, can you verify?

Flags: needinfo?(l10n)

Yes, I can verify that browsing works now. Also did a safety restart. And search logging gave me all my engines twice in a row.

Status: RESOLVED → VERIFIED
Flags: needinfo?(l10n)

What's the process / delay to have the bugfix available on PPA? It's still blocking for the ones who install Nightly from PPA.

(In reply to Anthony B from comment #48)

What's the process / delay to have the bugfix available on PPA? It's still blocking for the ones who install Nightly from PPA.

PPA's are not maintained by Mozilla (see https://wiki.mozilla.org/Nightly#Is_there_a_Nightly_repository_for_my_distro.3F). You should contact the maintainer of the PPA you use for Nightly and ask her.

(In reply to Pascal Chevrel:pascalc from comment #49)

(In reply to Anthony B from comment #48)

What's the process / delay to have the bugfix available on PPA? It's still blocking for the ones who install Nightly from PPA.

PPA's are not maintained by Mozilla (see https://wiki.mozilla.org/Nightly#Is_there_a_Nightly_repository_for_my_distro.3F). You should contact the maintainer of the PPA you use for Nightly and ask her.

I didn't know that. Thank you for pointing me out Pascal and sorry for disturbing.

Attachment #9062746 - Attachment is obsolete: true
Whiteboard: cert2019

I'm not sure whether it's related to this bug or the extension signing issue, but FWIW: I managed to fix my dark theme today by going to the Themes tab on about:addons, toggling the theme to disabled and then enabling it again.

I have the 3 themes disabled Default, Dark and Light. The actual one is the Dark one which I dislike

about:studies shows both hot fixes complete.

Could someone help me please?

Toggling the state of the one I wanted to enable worked for me, but the others still looked "stuck" until I toggled them as well. So I'd try toggling all 3 and see if that does anything to get your preferred theme unstuck.

I have the three of them disabled, so no chance to toggle them. All are grey. I mean, in the Themes panel I see Dark, for example and Disabled between brackets so I see: Dark (Disabled). And the same for Default and Light.

Maybe a screenshot would help?

(In reply to Gabriela [:gaby2300] from comment #54)

I have the three of them disabled, so no chance to toggle them. All are grey. I mean, in the Themes panel I see Dark, for example and Disabled between brackets so I see: Dark (Disabled). And the same for Default and Light.

Maybe a screenshot would help?

Please file a new bug with more specifics, like what version of Firefox you're using, and a screenshot of what you mean.

(In reply to :Gijs (he/him) from comment #55)

Please file a new bug with more specifics, like what version of Firefox you're using, and a screenshot of what you mean.

Filed bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1549595

Thanks for your help!

Duplicate of this bug: 1549652

Clearing old needinfo

Flags: needinfo?(dharvey)
You need to log in before you can comment on or make changes to this bug.