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

Status: VERIFIED FIXED

(Firefox :: General, defect, P1)

Description

[Francesco Lodolo [:flod]]

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.

Comment 1

[Julien Cristau [:jcristau]]

Nightly updates are disabled for this.

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

Comment 2

[Francesco Lodolo [:flod]]

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

Comment 3

[Francesco Lodolo [:flod]]

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

Comment 4

[Francesco Lodolo [:flod]]

Attachment: addonStartup.json.lz4

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

Comment 5

[Darkspirit]

(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.)

Comment 6

[Francesco Lodolo [:flod]]

Attachment: search.json.mozlz4

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 9

[Darkspirit]

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.

Comment 10

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

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.

Comment 11

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

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.

Comment 12

[Dave Townsend [:mossop]]

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

Comment 13

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

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

Comment 14

[Dale Harvey (:daleharvey)]

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)

Comment 15

[Darkspirit]

Attachment: 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.

Comment 16

[Dale Harvey (:daleharvey)]

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

Comment 17

[Shane Caraveo (:mixedpuppy)]

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

Comment 18

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1549075 update builtin addon metadata when the XPI database is rebuilt

Comment 21

[Jan Henning [:JanH]]

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.

Comment 22

[Andrew Swan [:aswan]]

Attachment: Bug 1549075 Don't blow up on builtin addons while rebuilding the extensions database r=kmag

Comment 23

[Pulsebot]

Pushed by [e-mail]:
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

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/7995904ca18e
Follow-up: Fix ESLint bustage on a CLOSED TREE. a=bustage

Comment 25

[Andrew Swan [:aswan]]

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)

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/445c0c44fa89
Follow-up: Fix system addon test on CLOSED TREE r=kmag a=bustage

Comment 27

[Darkspirit]

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

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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.

Comment 29

[:Gijs (he/him)]

https://phabricator.services.mozilla.com/D29954#inline-174096

Comment 30

[:Gijs (he/him)]

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.

Comment 31

[:Gijs (he/him)]

Attachment: Bug 1549075 - belt and suspenders: ensure syncLoadManifest gets given an oldAddon ref if possible and doesn't break if not

Comment 32

[:Gijs (he/him)]

Trypush:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d9125c30056bbbe427d3a456729fc2794dce1c8b

Comment 33

[Andrew Swan [:aswan]]

Attachment: Bug 1549075 Follow-up Fix loading built in manifests r=zombie

Comment 34

[sjw]

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

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/e5ed24b52564
Follow-up Fix loading built in manifests r=zombie a=pascalc CLOSED TREE

Comment 36

[Darkspirit]

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!

Comment 37

[:Gijs (he/him)]

:-)

Comment 38

[Don Marti]

Running 68.0a1 (2019-05-05) (64-bit) - freshly updated Nightly today.

Only my default profile seems to show this behavior. (Update: the problem went away after quitting and restarting Nightly, then came back for a few restarts, then disappeared again.)

On my default profile when I type "lat" in address bar

ER: see autocomplete suggestions including latimes.com

AR: no autocomplete suggestions show up.

When I make a fresh profile with "firefox -P" then in that new profile, the autocomplete is correct.

When I start up an old profile that I have not run in several weeks, the autocomplete is also correct in that profile.

Comment 39

[Dennis Clarke]

A lot of people running here to say "me too" and all I can say is that
nightly is intended to be unstable and things break. Which is exactly
what seems to have happened.

Well, me too.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Comment 40

[Andrew Swan [:aswan]]

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?

Comment 42

[Henri]

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

Comment 46

[:Gijs (he/him)]

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

Comment 47

[Axel Hecht [:Pike]]

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.

Comment 48

[Anthony B]

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

Comment 49

[Pascal Chevrel:pascalc]

(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.

Comment 50

[Anthony B]

(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.

Comment 51

[Emanuel Hoogeveen [:ehoogeveen]]

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.

Comment 52

[Gabriela [:gaby2300]]

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?

Comment 53

[Emanuel Hoogeveen [:ehoogeveen]]

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.

Comment 54

[Gabriela [:gaby2300]]

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?

Comment 55

[:Gijs (he/him)]

(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.

Comment 56

[Gabriela [:gaby2300]]

(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!

Comment 58

[Dale Harvey (:daleharvey)]

Clearing old needinfo

Comment 59

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.