1919721 - Bookmarks bar empty, pinned extensions gone, buttons gone etc. 132.0a1 (2024-09-18) (aarch64) macOS 15.1 Beta 4 and again in 133.0a1 (2024-09-30) and macOS 15.1 Beta 5

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect, P1)

Description

[Julie]

Attachment: Screen Shot 2024-09-19 at 10.27.21.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Updated macOS 15.1 Beta 3 to 4 a day before this happened. (no problems since first day of 15.0 Dev. Beta 1)

Just opened the browser without knowing if there will be an update installed. I close it every night. And sometimes restart it a few times.

Actual results:

Firefox Nightly is my main browser since about a year and I never had any problems.

Yesterday suddenly the upper bars were almost blank. There are no bookmarks in the bar, although they are still in the menu for it, no extension is pinned anymore and many buttons are missing. :(

The only good thing is, that the dark background color of the address bar is gone. Couldn't find it in settings.

I can't remember if this happened directly after a Nightly update.

Expected results:

Everything should have stayed as it was before, like after any other restart with or without Browser or macOS update.

Comment 1

[Julie]

Hello,

I am new year. I hope I did it the right way.

Kind regard,
Julie

Comment 2

[Julie]

year = here

Can't I edit?

Comment 3

[Julie]

Downgrading to an older build of 132a or even 131a didn't change it. Also tried using the pkg-installer instead of the dmg-file where I only have to copy the app.

Comment 4

[Julie]

A few updates later the bookmarks bar is still empty and I can't put anything in it, because it's always there in the "Bookmarks Toolbar" menu.

The cross next to the last Tab is still missing. It's either in the upper right corner of the Tab bar or I can but a symbol for it in the address bar where everything else, but it looks different and the cross is gone completely then in the tab bar.

The only thing I could fix manually was pinning the extensions and several function icons again to the address bar.

Nothing happened to Developer Edition/Beta/Release/ESR 128/ESR 115 also not to all the forks like Waterfox, LibreWolf, Pulse Browser Alpha, Mullvad Browser Release/Nightly/Alpha, Tor Browser Release/Nightly/Alpha, Floorp, SeaMonkey (Intel emulated).

All are updated to there latest version.

I don't now how this is working here, that people even see it. So I might just remove it from the Library and start over again. Would still be interested how this has happened...

Comment 5

[:Gijs (he/him)]

Have you tried going to customize mode and using "restore defaults"? You'd still need to pin the extensions again but I think it'd fix everything else.

If you could create a copy of prefs.js before doing that I would be interested in the value of browser.uiCustomization.state.

Comment 6

[Julie]

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

Have you tried going to customize mode and using "restore defaults"? You'd still need to pin the extensions again but I think it'd fix everything else.

If you could create a copy of prefs.js before doing that I would be interested in the value of browser.uiCustomization.state.

Hi,

with this customize mode I already brought back the most important things like back and forth, reload, show bookmarks in sidebar, settings and some others, I didn't have before. But it's a strange order. On the site you posted the cross for a new Tab is also in the upper right and not next to the tab where it is normally and I wasn't able to move it. So I have it also with all this other stuff in the address bar next to reload.

I saw in the other bug you linked there had been a crash while updating. That wasn't the case for me. So I still wonder how this happened. Sorry for not using that and opening a separate one. It was the first time being on this site for me, I also searched, but maybe didn't really know what to enter and didn't browse the list of bugs, somehow I did see it in the first place.

Found the pref file and copied it. I'll restore now. I could have also just reset the whole browser (by deleting the Nightly profile in the Library), but I thought this bug might be an important information.

Wow it worked. Even the Bookmarks Toolbar isn't empty anymore. :) I thought at least that would stay. Thank you very much.

Did you mean all this with value? It's from before restoring:

user_pref("browser.uiCustomization.state", "{"placements":{"widget-overflow-fixed-list":[],"unified-extensions-area":["i2ppb_eyedeekay_github_io-browser-action","34daeb50-c2d2-4f14-886a-7160b24d66a4-browser-action","idcac-pub_guus_ninja-browser-action","firefoxbeta_tampermonkey_net-browser-action"],"nav-bar":["sidebar-button","alltabs-button","zoom-controls","new-window-button","privatebrowsing-button","firefox-view-button","back-button","forward-button","new-tab-button","stop-reload-button","urlbar-container","downloads-button","unified-extensions-button","downie_charliemonroe_net-browser-action","browserassistantbeta_adguard_com-browser-action","ublock0_raymondhill_net-browser-action","jid1-mnnxcxisbpnsxq_jetpack-browser-action","7599bb55-1e8e-445a-9e32-66da6e1d6749-browser-action","4262db2c-adc6-481f-b8e3-828877c148b1-browser-action","myallychou_gmail_com-browser-action","2662ff67-b302-4363-95f3-b050218bd72c-browser-action","onepassword4_agilebits_com-browser-action","26b4f076-089c-4c69-8497-44b7e5c9faef-browser-action","private-relay_firefox_com-browser-action","fxa-toolbar-menu-button","preferences-button"],"TabsToolbar":[],"vertical-tabs":[],"PersonalToolbar":[]},"seen":["save-to-pocket-button","reset-pbm-toolbar-button","profiler-button","developer-button","i2ppb_eyedeekay_github_io-browser-action","canvasblocker-beta_kkapsner_de-browser-action","onepassword4_agilebits_com-browser-action","browserassistantbeta_adguard_com-browser-action","downie_charliemonroe_net-browser-action","7esoorv3_alefvanoon_anonaddy_me-browser-action","ublock0_raymondhill_net-browser-action","myallychou_gmail_com-browser-action","34daeb50-c2d2-4f14-886a-7160b24d66a4-browser-action","firefoxbeta_tampermonkey_net-browser-action","2662ff67-b302-4363-95f3-b050218bd72c-browser-action","4262db2c-adc6-481f-b8e3-828877c148b1-browser-action","jid1-mnnxcxisbpnsxq_jetpack-browser-action","numatrix_arek_codes-browser-action","b7f9d2cd-d772-4302-8c3f-eb941af36f76-browser-action","idcac-pub_guus_ninja-browser-action","7599bb55-1e8e-445a-9e32-66da6e1d6749-browser-action","private-relay_firefox_com-browser-action","26b4f076-089c-4c69-8497-44b7e5c9faef-browser-action"],"dirtyAreaCache":["nav-bar","TabsToolbar","PersonalToolbar","unified-extensions-area","vertical-tabs"],"currentVersion":20,"newElementCount":10}");

By the way: I just had my first crash ever of Nightly about an hour ago since using it again for more than a year as main browser, while watching a YouTube video since about 15 minutes and downloading a Chrome browser directly from Google for testing purposes. A window to report it showed up that I never saw before. I didn't enter anything because I still was half asleep. I think there were two YouTube sites ( a running video and the subscription site) open in the same Container and the Chrome website I download from was in a tab without container I think.

That's really good for a Nightly version to only have one crash while also being on macOS developer betas since day 1 for 15.0 and 15.1 each starting somewhere in the later 14.x betas in March maybe.

P.S.: Sorry for off topic things in here. Maybe you are able to remove them, if it's not allowed.

Comment 7

[Julie]

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

Have you tried going to customize mode and using "restore defaults"? You'd still need to pin the extensions again but I think it'd fix everything else.

If you could create a copy of prefs.js before doing that I would be interested in the value of browser.uiCustomization.state.

I just had a look at this prefs-file content and in the value I posted, I see a few extensions that are not pinned, they are even disabled like canvasblocker and numatrix also "save to pocket" wasn't there and many of the pinned are not listed there and some other things I never heard of like "myallychou_gmail_com-browser-action" (I don't even use gmail, except entering an address for YouTube login) and "jid1-mnnxcxisbpnsxq_jetpack-browser-action" and "idcac-pub_guus_ninja-browser-action" (this sounds like it's just an internal name for the "I (still) don't care about cookies" extension, what also was not pinned I think, because it doesn't have any settings. Maybe it's the case for some others too, that you don't see the official name.

Anyhow at least two of my disabled extensions are listed there, what's strange.

Comment 8

[Julie]

So, it happened again. Same as last time. Bit this time I can tell for sure it happened directly after an update.

I just woke up and started Nightly version 133.0a1 for the first time and everything up there including the Bookmarks Toolbar was empty again.

Restoring to defaults in "Customize Toolbar" fixed it again.

And there was already the update for a new build waiting.

Comment 9

[:Gijs (he/him)]

(In reply to Julie from comment #7)

Anyhow at least two of my disabled extensions are listed there, what's strange.

We keep the positions of any extensions even when disabled, so that they appear in the same place where you left them when no longer disabled. This is important also for things like temporarily using "troubleshoot mode" (which among other things disables all extensions). It wouldn't be nice if you then had to re-customize everything.

(In reply to Julie from comment #8)

So, it happened again. Same as last time. Bit this time I can tell for sure it happened directly after an update.

So this is really bad but I honestly am not sure what is going on. It would maybe be useful to enable browser.uiCustomization.debug in about:config (set it to true) and then the next time it happens we may get more information (in the browser console, you can open it with ctrl-shift-j). But we don't permanently log information like this all the time and so right now I don't think we have a great way of finding out from the fact that things got broken, why they were broken...

I'll ping some more people in case they have other ideas.

Comment 10

[:Gijs (he/him)]

Comparing https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/browser/components/customizableui/CustomizableUI.sys.mjs#2916-2929 and https://searchfox.org/mozilla-central/rev/21b890d440814444e4c879f06db7e2495b34691c/browser/components/customizableui/CustomizableUI.sys.mjs#2765-2775 (the previous version of this code) it looks like before, we would write saved state placements rather than nothing, as long as gPlacements didn't have info for an area, and now we only do so if neither gPlacements nor gFuturePlacements has info.

But gFuturePlacements will always have information, cf. https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/browser/components/customizableui/CustomizableUI.sys.mjs#1047-1057 which is in registerArea which gets called from initialize so before any other CUI code runs.

So we would never override with info from gPlacements anymore.

I wonder if this causes us to try to save state with empty arrays for the nav bar (that's certainly what I can see in some logging locally, even when not reproducing the bug), which could plausibly cause something like this - only the non-removable items (navbar, extensions button, back/fwd button) stay in the navbar. I don't yet know why they'd reverse order but that is hardly the most important thing in the circumstances - we're losing user customizations.

A log from an affected run would still be really helpful.

Comment 12

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

I agree that we need some logging here - something very strange is happening during the startup window, and I hope the logging might make it clearer what it is.

Comment 13

[Dão Gottwald [:dao]]

I've seen this too in my local build's testing profile that gets reset regularly. Unfortunately I'm not sure how I got there, but I assume the steps are going to be fairly straightforward.

Comment 14

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

Set release status flags based on info from the regressing bug 1899346

Comment 15

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

People are starting to report this in other channels as well, for example, Reddit: https://www.reddit.com/r/firefox/comments/1ftrm12/users_of_firefox_beta_developer_edition_132/

[Tracking Requested - why for this release]:

This is a fairly disruptive bug in the Firefox UI for which we don't have a great understanding just yet - but we should get this figured out before 132 goes to release.

Comment 16

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

Notably, the user on Reddit was using Windows, so this doesn't appear to be restricted to just macOS users, or a particular macOS version.

Comment 18

[Alexandre Poirot [:ochameau]]

(In reply to Dão Gottwald [:dao] from comment #13)

I've seen this too in my local build's testing profile that gets reset regularly. Unfortunately I'm not sure how I got there, but I assume the steps are going to be fairly straightforward.

Same. I got it once on local linux build.

It actually relates (at least) to safe mode.
STR:

• mkdir ppp
• ./mach run -profile ppp -safe-mode
  => the toolbar button will be in the buggy order
• ./mach run -profile ppp
  => the toolbar is still in the buggy order

Comment 19

[juraj.masiar]

I'm the guy from Reddit, using Windows 11 and Firefox Developer Edition 132.0b1 (64-bit).
I have an ordinary Firefox, using one simple "userChrome.css" file (that still works). Other than that, nothing special that would clear the toolbar.

If there is a way to avoid this "toolbar armageddon", please let me know, because when I start my work Firefox tomorrow, it will install this update (it was already downloaded when I left), and most likely blow up same as here at home. Thanks!

Also, you may want to stop the beta updates ASAP as this is pretty terrible experience for who knows how many users.

Comment 20

[:Gijs (he/him)]

(In reply to juraj.masiar from comment #19)

Also, you may want to stop the beta updates ASAP as this is pretty terrible experience for who knows how many users.

--> Ryan for a decision as 132 owner.

I don't have a workaround right now for preventative measures, but you can:

(a) revert to default from customize mode;
(b) if you're aware this is going to happen in future, copy paste the value of browser.uicustomization.state pref and restore it afterwards (will need a restart, we don't listen to changes on that pref).

At least IME on Nightly, it is definitely not the case that every update causes this so it's unclear to me how many folks are affected.

Comment 21

[:Gijs (he/him)]

(In reply to Alexandre Poirot [:ochameau] from comment #18)

STR:

• mkdir ppp
• ./mach run -profile ppp -safe-mode
  => the toolbar button will be in the buggy order

This doesn't reproduce for me. Can you try with a setpref on mach run to get a log as noted in earlier comments?

I expect this is some kind of race...

Comment 22

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

The STR from comment 18 do not currently cause the bug to appear for me.

ochameau, can you update your local instance to have browser.uiCustomization.debug set to true, and pasting the log after startup here?

Comment 23

[Ryan VanderMeulen [:RyanVM]]

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

--> Ryan for a decision as 132 owner.

I've set the update rate for Beta and DevEdition to 0% while the investigation continues. Can we please set a severity on this bug?

Comment 24

[ku4eto]

Just got updated to 132.0b1 on Windows 10 and got hit with the same issue.

Comment 25

[ku4eto]

Enabling the debug flag mentioned above - on the Home page, right after start, this is what i get in the console:

ERROR
Content-Security-Policy: The page’s settings blocked an event handler (script-src-attr) from being executed because it violates the following directive: “script-src resource: chrome:”
Source: function() {
[native code]
}

WARN
Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content. react-transition-group.js:9:10154

WARN
Source map error: Error: URL constructor: is not a valid URL.
Resource URL: about:home
Source Map URL:

Comment 26

[Alexandre Poirot [:ochameau]]

Attachment: CUI logs (on a subsequent firefox run, not the first time the toolbar appeared broken)

Comment 27

[Sam Foster [:sfoster] (he/him)]

(In reply to ku4eto from comment #25)

Enabling the debug flag mentioned above - on the Home page, right after start, this is what i get in the console:

You should get a lot of CustomizableUI: prefixed messages in the browser console (not the devtools one). ctrl+shift-j opens it. Can you double-check you enabled browser.uiCustomization.debug in about:config?

Comment 28

[Alexandre Poirot [:ochameau]]

Attachment: CUI logs (first time toolbar looked broken)

Comment 29

[Alexandre Poirot [:ochameau]]

Attachment: CUI logs (firefox run just before the run that looked broken)

Comment 31

[Alexandre Poirot [:ochameau]]

Attachment: CUI Logs (a few runs, and the very last with the broken toolbar)

Comment 32

[Alexandre Poirot [:ochameau]]

My STR is, on linux, from a Virtual Machine (VMWare), so may be slower than an usual dev laptop:

• create the empty profile folder
• open firefox once to toggle the browser.uiCustomization.debug pref
• run ./mach run -profile ppp -safe-mode many times. I either Ctrl+C, of quit gracefuly via Ctrl+W, I accept safe mode by pressing Enter button, or cancel it via Escape.

Comment 33

[ku4eto]

Attachment: browser console

(In reply to Sam Foster [:sfoster] (he/him) from comment #27)
> (In reply to ku4eto from comment #25)
> > Enabling the debug flag mentioned above - on the Home page, right after start, this is what i get in the console:
> 
> You should get a lot of `CustomizableUI: ` prefixed messages in the browser console (not the devtools one). ctrl+shift-j opens it. Can you double-check you enabled `browser.uiCustomization.debug` in about:config?

My bad, here it is:

```

Comment 34

[ku4eto]

Attachment: browser

(In reply to Sam Foster [:sfoster] (he/him) from comment #27)
> (In reply to ku4eto from comment #25)
> > Enabling the debug flag mentioned above - on the Home page, right after start, this is what i get in the console:
> 
> You should get a lot of `CustomizableUI: ` prefixed messages in the browser console (not the devtools one). ctrl+shift-j opens it. Can you double-check you enabled `browser.uiCustomization.debug` in about:config?

My bad, here it is:

```

Comment 35

[ku4eto]

Attachment: browser-console.txt

Comment 36

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

From comment 35, this appears (to me at least) to be the smoking gun:

CustomizableUI: registerArea PersonalToolbar, no gPlacements yet, nothing to restore CustomizableUI.sys.mjs:1051
CustomizableUI: All the areas registered: widget-overflow-fixed-list,unified-extensions-area,nav-bar,toolbar-menubar,TabsToolbar,vertical-tabs,PersonalToolbar CustomizableUI.sys.mjs:397
CustomizableUI: reconcileSidebarPrefs, kPrefSidebarRevampEnabled: {sidebarRevampEnabled}, kPrefSidebarVerticalTabsEnabled: false CustomizableUI.sys.mjs:4129
CustomizableUI: initializeForTabsOrientation, toVertical: false, gCurrentVerticalTabs: null CustomizableUI.sys.mjs:4013
CustomizableUI: initializeForTabsOrientation, savedPlacements null CustomizableUI.sys.mjs:4018
CustomizableUI: getAreaPlacementsForSaving for area: widget-overflow-fixed-list, gPlacements for area: , returning: CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: unified-extensions-area, gPlacements for area: ublock0_raymondhill_net-browser-action, returning: ublock0_raymondhill_net-browser-action CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: nav-bar, gPlacements for area: undefined, returning: CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: toolbar-menubar, gPlacements for area: undefined, returning: CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: TabsToolbar, gPlacements for area: undefined, returning: CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: vertical-tabs, gPlacements for area: undefined, returning: CustomizableUI.sys.mjs:2930
CustomizableUI: getAreaPlacementsForSaving for area: PersonalToolbar, gPlacements for area: undefined, returning: CustomizableUI.sys.mjs:2930
CustomizableUI: Saving state. CustomizableUI.sys.mjs:2963
CustomizableUI: State saved as: {"placements":{"widget-overflow-fixed-list":[],"unified-extensions-area":["ublock0_raymondhill_net-browser-action"],"nav-bar":[],"toolbar-menubar":[],"TabsToolbar":[],"vertical-tabs":[],"PersonalToolbar":[]},"seen":["developer-button","enhancerforyoutube_maximerf_addons_mozilla_org-browser-action","webextension_metamask_io-browser-action","_d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d_-browser-action","profiler-button","save-to-pocket-button","ublock0_raymondhill_net-browser-action"],"dirtyAreaCache":["nav-bar","toolbar-menubar","TabsToolbar","PersonalToolbar","unified-extensions-area","vertical-tabs"],"currentVersion":20,"newElementCount":7} CustomizableUI.sys.mjs:2965

^-- the placements have all been cleared out.

And then:

CustomizableUI: Restoring nav-bar from saved state CustomizableUI.sys.mjs:2797
CustomizableUI: Placements for nav-bar:
	unified-extensions-button
	urlbar-container
	forward-button
	back-button CustomizableUI.sys.mjs:2841

Comment 37

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

I think we're starting to realize that there's a few layers here:

1. There are cases where we'll write to prefs with empty placement arrays for each registered area in CUI. This seems to happen early during startup.
2. If Firefox starts up with a set of empty placement areas for registered areas (this is highly unexpected), it'll default to doing nothing, and the default state of the DOM is used as the source of truth for placements
3. That default source of truth for the DOM seems to do a reverse-iteration of DOM nodes https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/browser/components/customizableui/CustomizableUI.sys.mjs#1357 to construct the placements which it's... pushing into the placements array. I think this is why we're seeing the navbar effectively get into a reversed state for people seeing this.

So here's how to reproduce part 2 and 3 reliably:

1. Create a new testing profile. You can do that with ./mach run --profile <X>, where X is some empty directory. Once Firefox launches, shut it down.
2. Open up the prefs.js file in X, and find the line that starts with user_pref("browser.uiCustomization.state". Replace that line with:

user_pref("browser.uiCustomization.state", '{"placements":{"widget-overflow-fixed-list":[],"unified-extensions-area":[],"nav-bar":[],"TabsToolbar":[],"vertical-tabs":[],"PersonalToolbar":[]},"seen":["save-to-pocket-button","developer-button"],"dirtyAreaCache":["nav-bar","vertical-tabs","TabsToolbar","PersonalToolbar"],"currentVersion":20,"newElementCount":2}');

3. Save your prefs.js changes.
4. Launch the profile again using the same command from Step 1. You should notice that there are some missing default items in the toolbar (namely, the ones created dynamically via createWidget), but the back/forward buttons and the URL bar should all be in the right order.
5. Shut down the browser, and restart

At that point, you'll be in the broken state.

Comment 38

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

I think comment 10 basically nailed it. We're doing a truthyness check here on something that in its default state always exists, but is an empty Set, which gets coerced into an empty array with the next line.

A potential fix:

diff --git a/browser/components/customizableui/CustomizableUI.sys.mjs b/browser/components/customizableui/CustomizableUI.sys.mjs
index 55f1c8194445e..4dd3fa7ec4148 100644
--- a/browser/components/customizableui/CustomizableUI.sys.mjs
+++ b/browser/components/customizableui/CustomizableUI.sys.mjs
@@ -2915,7 +2915,7 @@ var CustomizableUIInternal = {
   getAreaPlacementsForSaving(area) {
     // An early call to saveState can occur before all the lazy-area building is complete
     let placements;
-    if (this.isAreaLazy(area) && gFuturePlacements.has(area)) {
+    if (this.isAreaLazy(area) && gFuturePlacements.get(area)?.size) {
       placements = [...gFuturePlacements.get(area)];
     } else if (gPlacements.has(area)) {
       placements = gPlacements.get(area);

Comment 40

[Ania]

(In reply to juraj.masiar from comment #19)

I'm the guy from Reddit, using Windows 11 and Firefox Developer Edition 132.0b1 (64-bit).
I have an ordinary Firefox, using one simple "userChrome.css" file (that still works). Other than that, nothing special that would clear the toolbar.

If there is a way to avoid this "toolbar armageddon", please let me know, because when I start my work Firefox tomorrow, it will install this update (it was already downloaded when I left), and most likely blow up same as here at home. Thanks!

Also, you may want to stop the beta updates ASAP as this is pretty terrible experience for who knows how many users.

Thank you, Juraj, and apologies for causing the toolbageddon. The impact is limited to ~6,000 users, and we have paused the rollout of the affected beta build to avoid more folks experiencing the issue until we have a fix.

Comment 41

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1919721 - Check size before building an empty placements list from gFuturePlacements in CustomizableUI. r?mconley!

Comment 44

[Sam Foster [:sfoster] (he/him)]

I hadn't seen Comment 38 yet, but ended up with the exact same patch. This checks out for me so far, but as its been a bit squirrelly to reproduce, we'll want some independent verification before rolling out the fix.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/57cd9cb3e458
Check size before building an empty placements list from gFuturePlacements in CustomizableUI. r=mconley

Comment 49

[Alexandre Poirot [:ochameau]]

I no longer reproduce with the submitted patch following comment 32 STR.

Comment 50

[pg_78]

(In reply to Ania from comment #40)

Thank you, Juraj, and apologies for causing the toolbageddon. The impact is limited to ~6,000 users, and we have paused the rollout of the affected beta build to avoid more folks experiencing the issue until we have a fix.

Are you sure the rollout pause worked? I started my Firefox Dev Edition at around 0830 UTC on 2nd Oct, had the defective update pushed to me and ended up with a clobbered toolbar.

Comment 51

[Sarah Clements [:sclements]]

Comment on attachment 9428397 [details]
Bug 1919721 - Check size before building an empty placements list from gFuturePlacements in CustomizableUI. r?mconley!

Beta/Release Uplift Approval Request

• User impact if declined: Disappearance/reordering of toolbar widgets, particularly for users who are on devEdition.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a one-line change to a condition that adds an additional check
• String changes made/needed:
• Is Android affected?: No

Comment 52

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/57cd9cb3e458

Comment 53

[:Gijs (he/him)]

(In reply to pg_78 from comment #50)

(In reply to Ania from comment #40)

Thank you, Juraj, and apologies for causing the toolbageddon. The impact is limited to ~6,000 users, and we have paused the rollout of the affected beta build to avoid more folks experiencing the issue until we have a fix.

Are you sure the rollout pause worked? I started my Firefox Dev Edition at around 0830 UTC on 2nd Oct, had the defective update pushed to me and ended up with a clobbered toolbar.

https://aus-api.mozilla.org/api/v1/rules/firefox-beta has the background update rate at 0 (also visible on https://whattrainisitnow.com/release/?version=beta ).

There's not a lot of info to go on here, but some hypotheses on why you would still have gotten the update:

• If you manually go to the about dialog that may still apply updates. I'm unsure right now if this applies for opening the Firefox settings, too, but it might (it has similar UI to the about dialog that will indicate whether or not your Firefox is up-to-date).
• It's also possible that if your machine was turned on yesterday or the day before, that either Dev Edition or the maintenance service (on Windows, you've not said what platform you're on) checked for updates before we set the update rate to 0 and downloaded it, and applied it when you started devedition today (it won't do a "phone home" on startup to check if it should still apply the update, or something like that).
• Finally, if you're using snap/flatpak/distro channels (on Linux) then those update rates are unfortunately not controlled by us.

If you're super sure none of these cases apply to you then it may be worth filing a separate bug, and the update folks will probably ask for some log information.

Comment 56

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9428397 [details]
Bug 1919721 - Check size before building an empty placements list from gFuturePlacements in CustomizableUI. r?mconley!

Approved for 132.0b2.

Comment 57

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/2f1eeae41cad

Comment 61

[:Gijs (he/him)]

For clarity for folks reading along: 132b2 is out now and will stop changing/breaking the toolbars once they are configured a certain way (ie fixes the bug that got your browser into this state).

However, it will not change your current toolbar configuration - so if it's broken it will stay broken until you do something. We're very sorry about this but unfortunately there aren't backups inside Firefox (so even though we'd love to, we cannot put things back to how you had them organized beforehand on your behalf, because we have no way of finding out what that was), and we didn't restore things to the default configuration either - that would have required being able to detect who had and hadn't hit this bug, which would have been close to impossible to do reliably and seemed too risky to uplift to beta on such short notice while we had beta updates throttled. Plus the "change it all to the default" update would have still been disruptive and left you needing to make more changes.

To fix your toolbars, we recommend you:

1. right click any empty toolbar space and choose "Customize toolbar" (also accessible from the "View > Toolbars" main menu and the hamburger menu -> More -> Customize toolbar)
2. you can "restore defaults" (on the bottom right) to go back to the default toolbar configuration, and/or manually drag/drop items as you find helpful.

You can also use the context menus on toolbar items to move them between the main toolbar and overflow/unified extensions toolbars.

More details are available in https://support.mozilla.org/kb/customize-firefox-controls-buttons-and-toolbars .

Comment 64

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest Builds. I tested with Firefox Dev Edition 132.0b2 and the issue no longer occurs.

Comment 83

[Julie]

So everything is fixed now? I got so many emails for this and couldn't really read them because of health issues.

Strange that this only happened to my Nightly and it wasn't even an update the first time, at least not a new version number, it was already on 132 for a while.
And if I remember correctly it also was no build update. I always see the green dot and do a restart then to update.
I just quit the browser before I was sleeping and when I woke up everything was gone. And it didn't happen to the Developer Edition, the normal Beta and the Release version.

Only the second time it was the update to version 133.

Comment 84

[Francesco Lodolo [:flod]]

(In reply to Julie from comment #83)

So everything is fixed now? I got so many emails for this and couldn't really read them because of health issues.

Not completely (see bug 1922802). Not sure if it happens across platforms, but while the address bar is mostly visible, clicks can still go through to the bookmark toolbar.

Wrong bug, this is fixed.

Comment 91

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

Is anybody experiencing this bug, where the back and forward buttons suddenly move to the end of the navigation bar, that did not first apply 132.0b1?

You can check by going to about:preferences#general, and scrolling down to "Firefox Updates" or "Firefox Developer Edition Updates", and clicking the "Show Update History" button.

What I'm interested in hearing about is anybody experiencing this bug that does not have 132.0 Beta 1 listed in their applied updates. Is anybody in that state?