1963549 - Sidebar bookmarks no longer open automatically since the last update.

Status: VERIFIED FIXED

(Firefox :: Sidebar, defect, P1)

Description

[d-schendel]

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

Steps to reproduce:

1. open sidebar bookmarks
2. close the browser
3. start the browser

Actual results:

Sidebar bookmarks no longer open automatically since the last update.

Expected results:

Sidebar bookmarks automatically open.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ania]

This seems only reproducible with the updated sidebar, old sidebar persists on quit Firefox -> start Firefox.

NVM: I cannot reproduce this either way anymore, unfortunately.

Comment 3

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

I'm not able to reproduce this yet. :reporter, or anyone able to reproduce this, I'm interested in the value of the sidebar. preferences. Can you go to about:config, type sidebar. in the search box there and and copy or screenshot those and attach the results here?

The other source of relevant data requires enabling the browser developer tools. In the browser console (not the same as the regular devtool console you'd use for a regular web page) type SidebarController.getUIState(), right-click on the result and select "Copy object" and paste the result into a comment here.

One more thing, can you go to about:studies and see if you are enrolled in the "Upgraded sidebar - 138 broad rollout - Forced enrollment" study. It would say "Active" next to that line if so.

Comment 4

[d-schendel]

(In reply to Ania from comment #2)

This seems only reproducible with the updated sidebar, old sidebar persists on quit Firefox -> start Firefox.

NVM: I cannot reproduce this either way anymore, unfortunately.

i want old sidebar back, if it is possible?!

Comment 5

[d-schendel]

(In reply to Sam Foster [:sfoster] (he/him) from comment #3)

I'm not able to reproduce this yet. :reporter, or anyone able to reproduce this, I'm interested in the value of the sidebar. preferences. Can you go to about:config, type sidebar. in the search box there and and copy or screenshot those and attach the results here?

The other source of relevant data requires enabling the browser developer tools. In the browser console (not the same as the regular devtool console you'd use for a regular web page) type SidebarController.getUIState(), right-click on the result and select "Copy object" and paste the result into a comment here.

One more thing, can you go to about:studies and see if you are enrolled in the "Upgraded sidebar - 138 broad rollout - Forced enrollment" study. It would say "Active" next to that line if so.

{
"command": "viewBookmarksSidebar",
"panelOpen": true,
"panelWidth": 168,
"launcherExpanded": false,
"launcherVisible": false
}

Comment 6

[d-schendel]

Attachment: aboutstudies.PNG

Comment 7

[d-schendel]

Attachment: sidebar1.PNG

Comment 8

[d-schendel]

Attachment: sidebar2.PNG

Comment 9

[Sarah Clements [:sclements]]

Thanks for all of the information. Did this issue with the bookmarks panel not staying open on restart only happen once? or is it every time you quit the browser and reopen?

Also, just want to confirm - did you change any of the sidebar. preferences you shared with the screenshots?

Comment 10

[d-schendel]

(In reply to Sarah Clements [:sclements] from comment #9)

Thanks for all of the information. Did this issue with the bookmarks panel not staying open on restart only happen once? or is it every time you quit the browser and reopen?

Also, just want to confirm - did you change any of the sidebar. preferences you shared with the screenshots?

Every time i quit the browser and reopen...otherwise it wouldn't be a real problem or?

2nd question: maybe be accident, but i guess i didn't change it, but i don't know

Comment 11

[Sarah Clements [:sclements]]

(In reply to d-schendel from comment #10)

(In reply to Sarah Clements [:sclements] from comment #9)

Thanks for all of the information. Did this issue with the bookmarks panel not staying open on restart only happen once? or is it every time you quit the browser and reopen?

Also, just want to confirm - did you change any of the sidebar. preferences you shared with the screenshots?

Every time i quit the browser and reopen...otherwise it wouldn't be a real problem or?

Could you share a screencast of that happening please (literally opening the bookmarks panel, quitting the browser, and it restarting without it being open)? None of us on the team are able to reproduce the problem.

Comment 12

[temp2645]

I'm having the same problem with the old sidebar.
I have it set to automatically delete history on exit.
After changing that setting, the problem no longer occurred.

Comment 13

[Sarah Clements [:sclements]]

(In reply to temp2645 from comment #12)

I'm having the same problem with the old sidebar.
I have it set to automatically delete history on exit.
After changing that setting, the problem no longer occurred.

Hi, are you saying that you originally had history set to never remember history and then you changed it? Would you be willing to change it back just to see if the issue re-occurrs? We have a backup pref sidebar.backupState that stores values (whether the sidebar was left open) in case users have that setting or do a one-time clearing of history. Any additional information or a screencast would be really helpful.

Comment 14

[temp2645]

(In reply to Sarah Clements [:sclements] | PTO until May 12th from comment #13)

(In reply to temp2645 from comment #12)

I'm having the same problem with the old sidebar.
I have it set to automatically delete history on exit.
After changing that setting, the problem no longer occurred.

Hi, are you saying that you originally had history set to never remember history and then you changed it? Would you be willing to change it back just to see if the issue re-occurrs? We have a backup pref sidebar.backupState that stores values (whether the sidebar was left open) in case users have that setting or do a one-time clearing of history. Any additional information or a screencast would be really helpful.

When that issue occurred, I had configured Firefox to retain the history while it was running and to automatically delete the history when exiting. If I change the setting to not automatically delete the history, the issue will not occur, but if I change the setting back, it will recur.
sidebar.backupState does not change before and after the issue occurred. The value of panelOpen remains true. If I restart again with the sidebar closed, it becomes false.

Comment 15

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

(In reply to d-schendel from comment #5)

{
"command": "viewBookmarksSidebar",
"panelOpen": true,
"panelWidth": 168,
"launcherExpanded": false,
"launcherVisible": false
}

Just to clarify for people watching this bug, this makes it clear that at least in this case we are talking about the "legacy" sidebar, not the new treatment.

Comment 16

[Ania]

Hi!
We are still trying to figure out the source of the issue, so very much appreciate your patience.
Can I please ask you to confirm a few things to help us eliminate possible reasons for breakage:

1. If I understood your screenshot from about:studies correctly, you have no active studies going, is that right? I'm using a translate tool to read German, so wanted to double-check.
2. Do you, by any chance, use Firefox ESR (extended support release) that your organization manages?
3. Can you please post a screenshot of how your sidebar actually looks like?

Comment 17

[temp2645]

(In reply to Sam Foster [:sfoster] (he/him) from comment #3)

Sorry. I realized I should have reported it too.

Object { command: "viewBookmarksSidebar", panelOpen: true, panelWidth: 216, launcherWidth: undefined, expandedLauncherWidth: undefined, launcherExpanded: false, launcherVisible: false }

"Install and run studies" is unchecked.

Comment 18

[temp2645]

Attachment: sidebar..PNG

Comment 19

[d-schendel]

(In reply to Sarah Clements [:sclements] | PTO until May 12th from comment #11)

(In reply to d-schendel from comment #10)

(In reply to Sarah Clements [:sclements] from comment #9)

Thanks for all of the information. Did this issue with the bookmarks panel not staying open on restart only happen once? or is it every time you quit the browser and reopen?

Also, just want to confirm - did you change any of the sidebar. preferences you shared with the screenshots?

Every time i quit the browser and reopen...otherwise it wouldn't be a real problem or?

Could you share a screencast of that happening please (literally opening the bookmarks panel, quitting the browser, and it restarting without it being open)? None of us on the team are able to reproduce the problem.

i think i have never done a screencast in my entire life. just screenshots, but i guess they are not helpful in this case.

is a discord-stream an option for u?

otherwise can u explain how to screencast? in german would be the best, because Sam Foster's tasks were already kinda hard to do for me.

By the way, since I'm new here, I'm currently being "spammed" with quite a few emails. The default notification settings aren't great in my opinion, so I don't know if you can change them...are u devs of this website or can use your connection to a dev, if u have one?!

The settings in general are quite overwhelming, especially the notification settings, and they're in English, too. I'm feeling a bit overwhelmed right now with everything and so on. Is there a way to change this page to German?

Comment 20

[d-schendel]

(In reply to Sam Foster [:sfoster] (he/him) from comment #15)

(In reply to d-schendel from comment #5)

{
"command": "viewBookmarksSidebar",
"panelOpen": true,
"panelWidth": 168,
"launcherExpanded": false,
"launcherVisible": false
}

Just to clarify for people watching this bug, this makes it clear that at least in this case we are talking about the "legacy" sidebar, not the new treatment.

Yeah kinda...i mean the "legacy" sidebar also got update(s) with the newest update being this kinda blue marker stuff when u click on something and btw i am not sure if i like that... although I'm not entirely sure if something like that didn't exist before and if it was maybe just a bit more subtle before. the (last) update(s) fucked up, I apologize for the use of bad language...i don't want to insult anybody, no offense! so when i wrote "i want old sidebar back" i meant the "legacy" sidebar before the (last) update(s)...an older version(number) of firefox or something like that.

Comment 21

[d-schendel]

(In reply to Ania from comment #16)

Hi!
We are still trying to figure out the source of the issue, so very much appreciate your patience.
Can I please ask you to confirm a few things to help us eliminate possible reasons for breakage:

1. If I understood your screenshot from about:studies correctly, you have no active studies going, is that right? I'm using a translate tool to read German, so wanted to double-check.
2. Do you, by any chance, use Firefox ESR (extended support release) that your organization manages?
3. Can you please post a screenshot of how your sidebar actually looks like?

1. yes i guess so. hehe, btw me doing the same with english.
2. i don't even know what ESR is and i am a private person.
3. yes ofc gimme a sec

Comment 22

[d-schendel]

Attachment: sidebar.PNG

Comment 23

[d-schendel]

maybe that (new?!) button above instagram is the problem?! u can see it in my newest posted screenshot and if i remember correctly ---> this button is new

Comment 24

[dcar425]

I just signed up to affirm this is a problem. Everything was fine until a few days ago. Keeping the bookmark sidebar open is a great convenience with a wide screen. It was always open whenever I opened a browser and now it's not there unless I manually open it. I would like to have it back the way it was.

Comment 25

[d-schendel]

(In reply to dcar425 from comment #24)

I just signed up to affirm this is a problem. Everything was fine until a few days ago. Keeping the bookmark sidebar open is a great convenience with a wide screen. It was always open whenever I opened a browser and now it's not there unless I manually open it. I would like to have it back the way it was.

me2

even without a wide screen bookmark is a great convenience and im just using a 24,5 Zoll 1920 x 1080 Full HD screen...its the major reason for me using firefox...i just love my bookmarks

but thanks to temp2645's comment i figured out what the problem is...or at least I can now narrow down the cause of this problem...it is one or more settings up to 4:

"Die Chronik löschen, wenn Firefox geschlossen wird"

and click on "Einstellungen" rigth next to it and maybe it's one of those 3 causing the problem, if it is not the one above:

"Besuchte Seiten & Download-Chronik
Löscht die Such-, Website- und Download-Chronik"

"Temporäre Dateien und Seiten im Cache (36,3 MB)
Löscht Elemente, die helfen, dass Websites schneller geladen werden"

"Gespeicherte Formularinformationen
Löscht Namen, E-Mail-Adressen und andere Einträge, die Sie in Formularen eingeben"

Comment 26

[chokito]

For me, it was enough to delete the "xulstore.json" file. After that, everything worked as before.
https://www.camp-firefox.de/forum/thema/139279-aktivierung-der-sidebar-wird-nicht-gespeichert-fx-138/?postID=1271249#post1271249

Comment 29

[Sören Hentzschel]

Sam, could this be a regression from bug 1921536 that landed in Firefox 138? Reports on Bugzilla and in the Firefox support suggest that the problem started with Firefox 138.

In bug 1964270, someone wrote:

As far as I remove the following section sidebar-box from the file, it works with the remaining content of the file. I have not yet manipulated the file manually.

"chrome://browser/content/browser.xhtml":{...

"sidebar-box":{"src":"chrome://browser/content/bookmarks/bookmarksPanel.xul","width":"328","sidebarcommand":"viewBookmarksSidebar","style":"width: 330px; -moz-box-ordinal-group: 1; order: 2;","checked":"true"},

And “sidebar-box” is also something that appears in the patch of bug 1921536.

Unfortunately, I was not able to reproduce. But I will set the status of the bug from UNCONFIRMED to NEW, based on the number of reports.

Comment 30

[temp2645]

Thanks. I also solved the problem by deleting "xulstore.json". This solution to the user interface problem is listed on support.mozilla.org, but I didn't notice it because it didn't mention the sidebar.
The problem was occurring in all three profiles I usually use, so unfortunately I neglected to check with a new profile. In my case, this problem does not occur with a new profile, nor with a profile I created about a month ago that I haven't used much.

Comment 31

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

(In reply to Sören Hentzschel from comment #29)

Sam, could this be a regression from bug 1921536 that landed in Firefox 138? Reports on Bugzilla and in the Firefox support suggest that the problem started with Firefox 138.

Yeah that seems plausible but we don't yet have steps to reproduce to confirm.

As far as I remove the following section sidebar-box from the [xulstore.json] file, it works with the remaining content of the file

I've tried re-creating a xulstore.json file with the "sidebar-box": { ... } contents but I was not able to reproduce. As of bug 1892033 we aren't using the xulstore.json for sidebar state/settings - and that landed over a year ago. So I don't yet understand how removing the xulstore.json file fixes this issue. If someone has a profile which reproduces this bug, could you attach your xulstore.json file here? As well as as much of the other details we've already mentioned: the values of the sidebar.revamp pref, sidebar.backupState, sidebar.revamp.defaultLauncherVisible and the output of SidebarController.getUIState(). I appreciate that's a lot, but there's enough reports here that clearly something is not working as expected, but so far we don't have a reliable way to reproduce and troubleshoot.

A couple of points to clarify:

• When we talk about the "new" sidebar, we mean the narrow sidebar "bar" with icons for bookmarks, history etc. you get (usually) on the left of the browser window. This is enabled by the sidebar.revamp pref, and can be manually enabled in Settings by checking "Show sidebar" item under the General > Browser Layout.
• The sidebar icon/button that appears top left is not a new button - its been available in the customize panel for many years. But placing it automatically on the toolbar when enabling the new sidebar is new.

Comment 32

[chokito]

Sam here is an old xulstore.json that failed at me.
https://www.camp-firefox.de/forum/thema/139279-aktivierung-der-sidebar-wird-nicht-gespeichert-fx-138/?postID=1271235#post1271235

Comment 33

[Sören Hentzschel]

I can not reproduce if I replace my xulstore.json with this file. So there are probably several factors at play, see comment 31.

Comment 34

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

I was able to reproduce by taking an old profile and editing in a sidebar-box xulstore.json entry:

{
    "chrome://browser/content/browser.xhtml": {
        "main-window": {
            "screenX": "24",
            "screenY": "4",
            "width": "1280",
            "height": "785",
            "sizemode": "normal"
        },
        "sidebar-title": {
            "value": "Bookmarks"
        },
        "sidebar-box":{
          "src":"chrome://browser/content/bookmarks/bookmarksPanel.xul",
          "width":"328","sidebarcommand":"viewBookmarksSidebar",
          "style":"width: 330px; -moz-box-ordinal-group: 1; order: 2;","checked":"true"
        }
    }
}

I did not enable "Delete cookies and site data when Nightly is closed". And session restore ("Open previous windows and tabs") was left unchecked. This profile dated back to ~v106 and had no sidebar.* user prefs set at all.

mozregression then gave me a pushlog which pinpoints bug 1921536 as the regressor.

Comment 35

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

Attachment: xulstore.json with sidebar state

(In reply to Sam Foster [:sfoster] (he/him) from comment #34)

which pinpoints bug 1921536 as the regressor.

I think what actually happened is that while bug 1892033 removed the updating of xulstore.json with sidebar state changes, it didn't remove the ability to read from that file and restore state via the xulstore mechanism. So right up until bug 1921536 (which landed in 138) this has continued to work as expected as long as you left the sidebar in the same open state each time the browser restarted.

That should mean the following STR:

• Clear the sidebar.backupState pref and ensure sidebar.revamp is false.
• Shutdown the browser and replace the xulstore.json in the profile with the one attached

I can put together a patch that uses these xulstore-derived values as fallback values. That will help users/profiles which have a record of the open sidebar in xulstore.json and haven't toggled it since bug 1892033 landed.

Comment 37

[Jonathan Sudiaman [:jsudiaman]]

Code tracing using the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1963549#c35:

Upon initial load of the browser, uiStateInitialized is set to true by _delayedStartup, and consequently startDelayedLoad.

console.trace() uiStateInitialized set to true. browser-sidebar.js:919:13
    startDelayedLoad chrome://browser/content/sidebar/browser-sidebar.js:919
    _delayedStartup chrome://browser/content/browser-init.js:506

Since uiStateInitialized is set to true, we are blocked from loading the backup state:

if (
    !this.uiStateInitialized &&
    !this.inSingleTabWindow &&
    (this.sidebarRevampEnabled || windowPrivacyMatches)
) {
    const backupState = this.SidebarManager.getBackupState();
    this.initializeUIState(backupState);
}

Note that this only happens when using the xulstore.json provided by Sam.

Comment 38

[Stuart Colville [:muffinresearch]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #35)

That should mean the following STR:

• Clear the sidebar.backupState pref and ensure sidebar.revamp is false.
• Shutdown the browser and replace the xulstore.json in the profile with the one attached

Sam, can you confirm if you have Clear history when Firefox closes checked (Note: in settings... Browsing & download history needs to also be checked)? I don't seem to be able to get this STR from comment 35 to reproduce without that set.

Comment 39

[Jonathan Sudiaman [:jsudiaman]]

(In reply to Jonathan Sudiaman [:jsudiaman] from comment #37)

Code tracing using the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1963549#c35:

Upon initial load of the browser, uiStateInitialized is set to true by _delayedStartup, and consequently startDelayedLoad.

console.trace() uiStateInitialized set to true. browser-sidebar.js:919:13
    startDelayedLoad chrome://browser/content/sidebar/browser-sidebar.js:919
    _delayedStartup chrome://browser/content/browser-init.js:506

Since uiStateInitialized is set to true, we are blocked from loading the backup state:

if (
    !this.uiStateInitialized &&
    !this.inSingleTabWindow &&
    (this.sidebarRevampEnabled || windowPrivacyMatches)
) {
    const backupState = this.SidebarManager.getBackupState();
    this.initializeUIState(backupState);
}

Note that this only happens when using the xulstore.json provided by Sam.

Upon further investigation, I think I can see what's going on here. This appears to be a subtle oversight of the fix for Bug 1908019.

For context, that bug was to fix the sidebar state being wiped out for users with "Permanent Private Browsing" or "Clear history when Firefox closes" enabled. So basically, before that was implemented, all users with those settings were not able to persist sidebar state. But now, it works for them, except in this case...

The smoking gun is this part of xulstore.json:

{
  "chrome://browser/content/browser.xhtml": {
    "main-window": { ... },
    "sidebar-title": { ... },
    "sidebar-box": {
      "src": "chrome://browser/content/bookmarks/bookmarksPanel.xul",
      "width": "328",
      "sidebarcommand": "viewBookmarksSidebar",
      "style": "width: 328px;",
      "checked": "true" <==== Here!
    }
  }
}

Normally, when loading from startDelayedLoad, without state information set by session store, we'd return early right around here:

// If we're not adopting settings from a parent window, set them now.
let wasOpen = this._box.getAttribute("checked"); // (this._box = #sidebar-box)
if (!wasOpen) {
  return;
}

But in this case, since checked has been set by the XUL Store data, we do not perform this early return, and arrive to the last line of this function, which is this.uiStateInitialized = true, thus blocking us from loading the backup state as I mentioned.

Running this seems to be the bare minimum for fixing this issue:

Services.xulStore.removeValue(
  AppConstants.BROWSER_CHROME_URL,
  "sidebar-box",
  "checked"
);

Perhaps, SidebarManager should just remove the entire sidebar-box entry from XUL Store, and let backup state do its thing?

As far as why we're continuing to read these values from XUL Store, I'm not entirely sure. I tried to add a console.trace() to XULStore.sys.mjs, and I see that we are indeed enumerating the values of sidebar-box, but the stack trace gets cut off, which leads me to believe it's somewhere out in XPC land.

Comment 40

[:Gijs (he/him)]

(In reply to Jonathan Sudiaman [:jsudiaman] from comment #39)

As far as why we're continuing to read these values from XUL Store, I'm not entirely sure. I tried to add a console.trace() to XULStore.sys.mjs, and I see that we are indeed enumerating the values of sidebar-box, but the stack trace gets cut off, which leads me to believe it's somewhere out in XPC land.

XULStore integration is part of how chrome document restoration works, restoration will get called from C++.

https://searchfox.org/mozilla-central/rev/4c065f1df299065c305fb48b36cdae571a43d97c/browser/components/sidebar/browser-sidebar.js#483-488 persists some stuff to xulstore still. Not clear to me if that is intentional or not.

Perhaps, SidebarManager should just remove the entire sidebar-box entry from XUL Store, and let backup state do its thing?

If the intent was to stop using XULStore for state restoration entirely, there should have been a _migrateUI profile data upgrade entry created that wipes that xulstore state. Otherwise the core XUL window infra will keep restoring whatever is still in the db.

Comment 41

[Jonathan Sudiaman [:jsudiaman]]

Rather than relying on this.uiStateInitialized and an idle period from requestIdleCallback(), it could be more useful to be able to check if there is a condition where SessionStore will not be expected to call restoreSidebar(), let me know if there is such a way.

Update: Spinning this off as Bug 1965508.

Comment 42

[Jonathan Sudiaman [:jsudiaman]]

Attachment: Bug 1963549 - Add profile migration to remove outdated sidebar attrs from XULStore. r?Gijs,#sidebar-reviewers

There was some discussion on whether the XULStore data should be written back into Session Store or Prefs. My concern there is that since we no longer write to XULStore, there is a good chance that this data is outdated anyways, and we'd be overwriting data in other places that are up-to-date. My vote is to simply discard this data, it seems that users were already comfortable with clearing their xulstore.json, so it doesn't seem like an issue to do the same programmatically.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/35212b487fd9
Add profile migration to remove outdated sidebar attrs from XULStore. r=Gijs,sidebar-reviewers,firefox-desktop-core-reviewers ,sessionstore-reviewers,sthompson

Comment 44

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/35212b487fd9

Comment 45

[Rares Doghi, Desktop QA]

I was able to reproduce this issue in our older builds using the steps and xul file from Comment 35 while also setting to Erase history when Firefox closes. This issue is Verified as fixed in our latest Nightly build 140.0a1 (2025-05-11).

Comment 46

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

The patch landed in nightly and beta is affected.
:jsudiaman, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 47

[Jonathan Sudiaman [:jsudiaman]]

Attachment: Bug 1963549 - Add profile migration to remove outdated sidebar attrs from XULStore. r?Gijs,#sidebar-reviewers

There was some discussion on whether the XULStore data should be written back into Session Store or Prefs. My concern there is that since we no longer write to XULStore, there is a good chance that this data is outdated anyways, and we'd be overwriting data in other places that are up-to-date. My vote is to simply discard this data, it seems that users were already comfortable with clearing their xulstore.json, so it doesn't seem like an issue to do the same programmatically.

Original Revision: https://phabricator.services.mozilla.com/D248476

Comment 48

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Users with "Never remember history" or "Clear history when Firefox closes" enabled may not be able to save their sidebar settings.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: https://bugzilla.mozilla.org/show_bug.cgi?id=1963549#c35
• Risk associated with taking this patch: Low
• Explanation of risk level: One-time migration of XUL Store preferences that we no longer actively write to.
• String changes made/needed: None
• Is Android affected?: no

Comment 49

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/99414e1f6ffb

Comment 50

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest Beta 139.0b8.

Comment 51

[Rares Doghi, Desktop QA]

Updating the remaining flags.