Breaks button strip of new native sidebar

[dreadbalaur]

OS: Windows 10 22H2 ESU
Firefox 148

This incompatibility issue has been ongoing for several months for me, but I was not able to find a likely culprit until now. Firefox is phasing out support for its old sidebar, so this becomes even more relevant as all users have to transition to the new sidebar.

The button strip at the bottom only gives access to sidebar settings by default, but Firefox has gradually introduced additional options like other device tabs, history, bookmarks, and passwords sidebar. Some extensions also use this sidebar. With fx-autoconfig enabled, the button strip functions as normal, but after an unspecified amount of time the whole button strip will disappear. Some options can still be access through hotkeys when the strip is hidden. The glitch is also window-specific: for each new window, the button strip is accessible from that window again before inevitably disappears later.

This bug could be mitigated previously by turning off "Expand sidebar on hover", which allow the strip to appear again in a permanently collapsed state. However, this workaround is no longer effective in 148.

Normal:

With fx-autoconfig:

[MrOtherGuy]

I cannot fathom how this could be caused by fx-autoconfig itself, I think it's more likely that this might be caused by one of your custom scripts loaded by fx-autoconfig.

Not saying that it's impossible, but I think you should check if the bad behavior happens if you disable all your custom scripts but don't diasable fx-autoconfig. And remember to clear startupcache after disabling scripts.

[dreadbalaur]

That's fair. I believe I have cleared startup cache earlier, but I will repeat my testing.

[dreadbalaur]

Removed my existing scripts in JS (Second Sidebar) and cleared startup cache. Seems to keep happening, but of course I am open to find other potential culprits.

I am also sharing a side-by-side comparison of the sidebar buttons in the bugged (left) vs non-bugged window (right):

[MrOtherGuy]

One other thing you should definitely test is to remove all your custom styles. I see you have loaded a file called customChrome.css which, based on your screenshots does at least two things - display a tab count below tabs and makes the tools icons centered horizontally to the sidebar in the expanded state, at least I'm pretty sure they aren't centered normally. I could see both of those things potentially causing the tools buttons to disappear since they are modifying the affected browser area but more importantly, there might be other changes you have that I don't know about.

The cleanest way to test would be for you to simply create a new profile without any custom things - then test it until you are confident that the issue doesn't occur. Then add only fx-autoconfig to it without any scripts or styles. If the issue the starts happening then alright maybe it is indeed really caused by fx-autoconfig - however, that sadly still doesn't help identifying why the issue occurs, nor how to fix it.

The reason why I'm having hard time to believe this is caused by fx-autoconfig is because it doesn't really modify the UI at all, except to add a new submenu to menubar. That happens when the tools menubar item is first opened, it doesn't start to happen after "unspecified amount of time" on it's own. Nonetheless, I can leave my test profile running for couple of days to see if this problem would manifest itself, although if this is any way dependent on user settings then it might be nigh-impossible for me to reproduce the issue.

[dreadbalaur]

I did not remove my custom styles because they have been running for some time before I try to incorporate fx-autoconfig. I will test on a fresh profile and report back.

[MrOtherGuy]

So I've had a test profile running for 4 days now with three windows, and the described issue doesn't happen in any of them. I'm afraid there's likely nothing further I can do unless you can figure out steps I can definitely reproduce the problem with.

[dreadbalaur]

I can't produce the behaviour a fresh profile on my end, either.
The behaviour is still present in the active profile even when the chrome content was removed, so it might be a conflict between existing userchrome themes specific to that profile with config-prefs.js or/and config.js.

[dreadbalaur]

@MrOtherGuy did more extensive testing today with a new profile. I believe the conflict is from the CSS styling in chrome\CSS. I will list my steps and my current reproduction method below:

• Sidebar settings: enable vertical tabs and expand sidebar on hover.
• Instead of expanding the sidebar on hover, you expand it by using the button toggle (Alt+Ctrl+Z)

[MrOtherGuy]

My test profile I experimented with has both of the two css files in the css folder (agent_style.uc.css and author_style.uc.css) and I did have vertical tabs enabled as well as expand on hover enabled, so I don't think those are the problem, at least not by themselves. agent_style.uc.css doesn't have any style rules, it's simply a template you can use, and author_style.css only adds a small dot to the developer tools -button panel menu.

I did not back then test ctrl+alt+z to expand the sidebar, but based on brief experimentation it doesn't seem to cause any problems, although I could believe that on some circumstances it might, because it sounds like the root of the problem is that sometimes toggling the toolbar visibility doesn't update the tools buttons' visiblity correctly.