2056857 - [Regression] in 153.0: Cannot open History sidebar (ctrl-H) when "Show Sidebar" is disabled in the settings

Status: ASSIGNED

(Firefox :: Sidebar, defect, P1)

Description

[Camusensei]

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

Steps to reproduce:

Settings > Tabs and browsing > Uncheck "Show Sidebar"
Ctrl-H

Actual results:

Nothing

Expected results:

History sidebar should have opened (but without the sidebar itself, which is disabled)

Comment 1

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

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

Comment 2

[:Gijs (he/him)]

Can't reproduce on 153 release, beta or nightly.

Can you reproduce on a clean profile from the steps here? Does this happen 100% of the time, or does the problem go away and then come back? If you open the browser console (open with ctrl-shift-j), then try to open the sidebar a few times, do any new errors appear there ?

Comment 3

[Camusensei]

Hello Gijs.
(Sorry for the lack of information in the original report, I did not expect it to be non-reproducible. I just now tried to reproduce it on another computer without success, even reverting to a clean profile on 152.0.6 and upgrading did not make the bug appear)
Thank you, I didn't know about the browser console, that's exactly what I needed to make a better bug report.

I cannot test with a clean profile because it's locked by policy, so I will try (tomorrow) the next best thing, removing the data and starting fresh. I expect it to work, because just like Bob in Bug 2056976, I also have tried with all extensions disabled (Troubleshoot mode) and ctrl-H did not function then.

Tomorrow, I will test with the browser console open:

• Ctrl-B
• Multiple Ctrl-B
• Ctrl-H
• Multiple Ctrl-H
• Click on the "show taskbars" button
• Multiple clicks on the "show taskbars" button
  And report back on what I can see.

Thank you for your support, and sorry for the wait.

Comment 6

[Camusensei]

Attachment: browser console.png

Browser console while performing the following actions:
42 Ctrl-B
69 Ctrl-H
A few clicks on "Show sidebar (Alt+Ctrl+Z)"

Comment 7

[Camusensei]

Funny test I did:

1. Install Firefox developer edition
2. Notice that, out of the box, it has the same issue as my profile. (same errors as the previous message despite being a brand new profile I guess)

I'll now do what I mentioned a few messages ago: backup my profile, delete everything and start a new session.

Comment 8

[Camusensei]

Huh, surprisingly, the problem is the same even after uninstalling Firefox completely, removing the %appdata%\Mozilla and %localappdata%\Mozilla folders and starting a brand new browser!
I traced it down to the policies that are applied by my company. I'll disable them one by one and let you know which one is causing this.

Comment 9

[Camusensei]

Success, I traced it down to a single policy:
Preferences: { "network.http.http3.enable": { "Value": false, "Status": "default" } }
This policy breaks the sidebar when disabled in the settings.
Over to you for the explanation as to why this happens.

PS: for people coming here because they have the same bug, you can see which policies are active in about:policies and for Windows, in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox)

Comment 10

[Camusensei]

This policy breaks the sidebar when disabled in the settings.
To be more clear, I meant to say that this policy prevents the sidebar from opening when Show sidebar is unchecked in Tabs and browsing, which results in sidebar.visibility = hide-sidebar in about:config (the default is sidebar.visibility = always-show)

Comment 11

[Bob]

To add a little more.

I do not have the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox. I could not find "network.http.http3.enable" in about:policies.

However, when Show sidebar is checked in Tabs annd browsing, ctrl-B does work.

Additionally, in distribution/policies.json if I remove "PasswordManagerEnabled": false, or "PrimaryPassword": false, ctrl-B works without Show sidebar checked.

Comment 12

[Camusensei]

@Bob policies can be added in different ways, I should have mentioned that.
I now see that if I have ONLY the "Preferences" policy, the bug is gone, so it's a combination of policies which causes this. I'm trying to find which.

Comment 13

[Camusensei]

Strangely, now it's when I remove PasswordManagerEnabled that the bug is gone and it's no longer Preferences which blocks the sidebar.
When I start from a completely new profile, it works.
I add the policy PasswordManagerEnabled:false and restart the browser, the bug appears.

I'm not sure if this is a definitive analysis but we know it's policy-related now.

Comment 14

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

I'm assigning S3, though I'm not sure "restart the browser" is really a good workaround and there's a case to be made for S2 here.
I'll get a bandaid patch on here to fix the more reproducible issue and which is low-risk enough to uplift. That part traces most directly back to bug 1999812.

There will still an underlying issue that will need more investigation and likely a more involved patch that should be a follow-up. That's either regressed or only partly fixed by Bug 2034633.

Comment 15

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

Attachment: Bug 2056857 - Ensure sidebar-switcher-megalist element exists before hiding it. r?Gijs!

Comment 16

[Camusensei]

(I'm taking about restarting the browser because that's how policies are changed. The problem is not about wether or not we restart the browser, but about which policies are set/enabled)
This patch will just hide the error, I don't think it will help much.
The cpmMenuItem should always exist. The error doesn't break anything so I'd vote against this change

Comment 17

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

(In reply to Camusensei from comment #16)

This patch will just hide the error, I don't think it will help much.
The cpmMenuItem should always exist.

Any of these elements can get removed if their visible property goes false, which can happen if one of the associated preferences changes value, or the window toggles between regular / smart window.

The error doesn't break anything so I'd vote against this change

The error has been shown to leave the sidebar unusable in some circumstances until the next restart. And if the browser starts up with both sidebar.revamp and browser.contextual-password-manager.enabled false, the sidebar will not work at all due to an exception being thrown during its initialization . The patch addresses this symptom, but you are right that its not a complete fix.