Go to about:config and set the pref browser.ml.chat.hideLocalhost to false Afterwards you can select localhost as the provider in Settings > Firefox Labs

That is not browser toolbox - just normal devtools. Browser toolbox is separate tool which is used to inspect the browser window itself rather than web content. It’s essentially a separate Firefox instance with it’s own profile.

That is not possible. Browser toolbox runs in a completely separate Firefox instance in a separate profile so there’s no way you could display it inside the “main” browser window.

I don’t think there a way to open the library to history section via address. Library window history and bookmarks section are the same document, and the buttons that open open library window to history view do it by opening the window with extra window arguments - which you cannot do by simply changing the url.

A possible other option to show history would be to open Firefox view to history section. about:firefoxview#history

There’s also another thing that I don’t think is mentioned yet. The options available in Settings are supported features. If the feature is only available via about:config then there’s a good chance that it is not supported or tested configuration. It might work or it might not, at least not in all scenarios

A subset of “advanced” users might have turned telemetry off so it certainly is skewed somewhat, but I don’t think there a good reason for me to believe that the subset is necessarily that large.

I’m guessing that the reason (and a good one at that) is that simply having an option to connect to a local chatbot leads to just confused users because they also need the actual chatbot running on their system. If you can set up that, then you can certainly toggle a simple switch in about:config to show the option.

You can hide them with userContent.css - most of the devtools window stuff is styled via userContent.css not userChrome.css.

But there’s a catch.

Browser toolbox is essentially a separate instance of Firefox, running in separate profile so your “normal” user css files don’t apply to it. Thus, you need to first enable the toolbox profile to load it’s own user css files and create them just like you do normally (toggle toolkit.legacyUserProfileCustomizations.stylesheets, create files in chrome/ folder etc.). The toolbox profile is stored inside the regular profile - in a directory chrome_debugger_profile.

To get to about:config of the toolbox profile you need to first open a new main-window for it - one way that works is to click the meatball menu at the top-right of the toolbox window, and select “Documentation…” - that will launch a new window using using the toolbox profile and then you can just open about:config and proceed as usual. Or you can just modify prefs.js of the toolbox profile directly while the toolbox is not running.

Anyway, after you have set up the toolbox window to load user css files, then just slap this to its userContent.css and restart the toolbox:

header.chrome-debug-toolbar{
  display: none !important;
}

Yeah, !important doesn’t affect inheritance in any way. It only means that this particular rule is to be used if there are multiple rules that would set that particular property for the element in question (unless there’s some other more specific rule with !important tag as well). MDN lists property inheritance in the formal definition section. You can totally make background-color inherited though - like *{ background-color: inherit } (and then set the property to something else on the root element from which you would want to inherit from) but it would then either not apply if website set it to anything else for an element or override any other set value if you used !important tag.

One other thing worth noting is that I would not recommend the rules mentioned for userChrome.css to be used as is - at least on Windows they completely break Firefox startup - it fails to display any window if you do that. Instead you should add a [sessionrestored] selector to wait a bit before those rules are applied to main-window:

#main-window[sessionrestored], #tabbrowser-tabpanels{ background: transparent !important; }

Right, background-color is not an inherited property (compared to for example color (color of text) which is). But even if it were, inheritance is not “enforced” so if website css sets a backround-color specifically for that element then the inherited value would be lost anyway.

But the way you now describe it doesn’t seem possible. There is not syntax to apply style rule to “just the innermost element”. I think the closest would be to have everything else have fully transparent background, but the html root element have only partial transparency:

*{
  background: transparent !important;
}
html:root{
  background: #00000080 !important;
}

However, you will still face a problem; many websites draw graphics or images as a background-image so if you use the background shorthand property then those graphics will be effectively removed. On the other hand, if you instead set just background-color then parts might get opaque again because a website could be drawing even opaque backgrounds as background-image instead of background-color.

I think the answer depends on which elements exactly you want to make transparent. The page is a layered structure. The html root element is behind them all. Then body element is on top of that, the rest of the elements on top of body, etc.

So if you intend to have transparency all the way down, then you need to make sure that all the elements in that stack are transparent. If any single item in a stack has an opaque background then the transparency effect stops at that.

As an example, if you set background:transparent to just body but not the document root element, then body will indeed be transparent, but it does not matter because the root will still be opaque. Likewise, if root is made transparent, but there is any opaque layer on top of that, then only the parts of the root element that are not covered by that opaque layer will show up as transparent. If you have a glass table and put a sheet of paper on top of it, then you don’t see through the part covered by the paper even though the table itself is transparent.

Yeah, I just figured the safest option would be to only set the actual document root element transparent - in practice I think it’s possibly more likely that the <body> element has background set by the page - although the page might as well set both. So yes, it depends on the website.

I don’t think I understand exactly what parts you want to make transparent, but this does work:

1. set browser.tabs.allow_transparent_browser to true
2. in userChrome.css add #main-window, #tabbrowser-tabpanels{ background: transparent !important; }
3. in userContent.css add html:root{ background-color: transparent !important; }

The above would make window background, and the are behind web-content transparent as well as background of html documents - otherwise the background of browser area wouldn’t show up anyway. Toolbars that have their own specified colors would still be colored - which might be opaque or not depending what theme you have selected.

With prefs or CSS no, but there’s been quite lot of other changes related to that, and I think there’s a non-zero chance that some other change could get introduced that could be used to fix custom styling for urlbar.

You are almost certainly experiencing changed behavior from this bug

Would be pretty idiotic to not close it, otherwise opening a bookmark would always require a second click to close the popup.

Anyways, you can go to about:config and set browser.bookmarks.openInTabClosesMenu to false - afterwards you can hold Ctrl (or just click the middle mouse button) while clicking a bookmark from such popup and the popup should stay open.

Doesn’t really sound like a company that I would want to do any business with then.

But if you’re using the built-in auto-updater (like people tend to do on Windows and macOS), then it happens automatically in the background, unless you tell the auto-updater to not update automatically.

Definitely does not work that way on my Windows 10 installation. When update is available, Firefox will have a “Restart to install updates” in menu button notification - but the files are not replaced on disk until you actually close (or restart) Firefox and thus Firefox continues to work normally.

What can happen though is that if you run another instance (ie. another profile) of Firefox while the first one has “staged” the update then that another instance can trigger the files to actually be replaced on disk but you would very deliberately do that.

Firefox shouldn’t force you to restart and update like that unless something else, such as your package manager, has already replaced the executable files on your disk. In such a scenario Firefox doesn’t have any option except to inform you to restart it (well I guess it could choose to crash). But the mechanism that forced the update is the package manager.

The non-standard :-moz-lwtheme is now considered invalid syntax, so using that invalidates the whole ruleset it’s used in. Featurewise the equivalent would be to check for existense of lwtheme attribute on root element. But the way you have written your rules the you have never even needed :-moz-lwtheme selector to begin with since you are applying the same rules when that matches and doesn’t match. So you can just write this to get your desired selection color in urlbar:

#urlbar ::-moz-selection{
  background-color: #3040cf !important; /*it's green again; want to fix this too*/
  color: white !important;
}