Toggle tabs and vertical pane button

[henryxrl]

We used to have the toggleTabsAndSidebarButton.uc.js where it toggles between the sidebar and tabs (though need to configure it in CSS). Is it possible (if it's not too much work, of course) that you can make a version that toggles between the vertical tab pane and tabs? I have been trying to make my own but not much progress... Or if you can provide some help that'd be helpful too! Appreciate it!

Edit: I saw that the vertical pane comes with vertical-tabs. Therefore, this should do the trick:
:root[vertical-tabs=true] #TabsToolbar { visibility: hidden; }

[aminomancer]

Yeah the documentation in verticalTabsPane.uc.js gives a bit of a walkthrough for hiding things when the vertical tabs pane is open. I would recommend using visibility: collapse or display: none instead of visibility: hidden, unless there's some reason you want that empty space to remain present. I guess it qualifies as drag space?

[henryxrl]

Because I actually want these title buttons to show up. If I see TabsToolbar to collapse or none, then those buttons will be gone. So I actually wrote these:

Manually moved 33 px down haha. I know it looks ugly, but I don't know how to make it work perfectly. I'd also tried to set the background color of the title button's area but those I commented out never works. :-(

[aminomancer]

Oh, you need !important; for those rules you commented out.

You could just add new window control buttons instead of trying to repurpose the titlebar buttons. Like, make a new script in the JS folder called navbarWindowControls.uc.js or something, and paste this in it:

(function() {
    let newControls = document.querySelector("#toolbar-menubar .titlebar-buttonbox-container").cloneNode(true);
    newControls.id = "navbar-window-controls";
    newControls.setAttribute("removable", false);
    CustomizableUI.getCustomizeTargetForArea("nav-bar", window).prepend(newControls);
})();

I think that should work. Then you can just style it with CSS using #navbar-window-controls

[aminomancer]

If that doesn't work I can do some testing and just publish a script on here that hides the titlebar and moves the buttons into the navbar. The reason I haven't done this already is that removing the titlebar actually has a lot of subtle side effects. It changes the height of the navigator toolbox. Which is important when we go into fullscreen mode and the toolbox auto-hides by sliding up and down. In order to make the nav-bar float above the content, we have to let the content stretch all the way to the top of the window. With this theme the findbar slides with it, but the findbar isn't actually attached to the toolbox, it's a child of the browser stack. The giant box that contains the content area basically. So when the navbar moves up and down the findbar doesn't naturally move up and down to fill in that space. It doesn't know when to move up/down or by how much. I have to hard-code that behavior and the values.

Well, the amount is calculated by combining the user-specified height of the titlebar + the height of the navbar. If those elements change in height programmatically, the findbar won't know about it. Basically uc-globals.css defines what the height of those toolbars should be via variables, and the toolbars' heights are set according to those variables' values, and the findbar uses those same values expecting that they will always be the same. But when hiding the titlebar, the titlebar height variable's value no longer matches the actual bounding box. The navbar moves up to fill the space left behind by the titlebar, but the findbar remains in the spot calculated by combining those values. So we get a findbar that's just floating off in space.

There are only a couple ways to get around that. One would be to just give up on the floating nav-bar thing. But I think it looks really ugly when the entire content area slides up and down when the nav-bar comes into view. That's how it works in vanilla firefox. The nav-bar slides down and pushes all the browser stack down with it, including the findbar and the content area and the sidebar and even the vertical tabs pane. It gives me motion sickness honestly. So I don't think that's a viable option.

But the only other alternative is to use javascript to set the findbar's position. To set variables based on the computed dimensions of the toolbars' bounding boxes, and then position the findbar according to those computed values. That's how a lot of the vertical tabs pane's sizing and positioning works. So it would be possible to do it again. I just haven't really been motivated to do all of that yet since there are so many other things to deal with, and I wouldn't personally want to hide the titlebar in the first place.

[aminomancer]

Actually, I guess you might be able to achieve similar results (preventing the findbar from floating in fullscreen mode) by adding this to your custom-chrome.css:

:root, menupopup {
    --tab-min-height: 0px !important;
}

[henryxrl]

On a Mac, adding this menupopup css code or not, the whole navbar remains visible during fullscreen.

[henryxrl]

Mozilla should really hire you to make Firefox better, haha!

I can confirm that :root, menupopup { --tab-min-height: 0px !important; } does work. Before adding this, in full screen mode my navbar won't even show up. With this it's working fine.

I tried your navbarWindowControls.uc.js script. With it, after I set #TabsToolbar and #titlebar to visibility: collapse, there is this blank title bar still remaining (meaning that collasping the titlebar doesn't work any more). How can I make the navbar windows controls show up? I tried :root[vertical-tabs=true] #navbar-window-controls { visibility: visible; } but no luck.

[henryxrl]

I always put the window control buttons on the left. Once I switch it to the right side, with the about js script enabled so that window buttons show in navbar...

Does this happen to you?

This is on Windows. On a Mac, I guess the userChrome.css.titlebar-buttons-on-left setting doesn't affect anything anyways.

[aminomancer]

Well the chevron (>>) and hamburger buttons aren't in the customization target. See this line? CustomizableUI.getCustomizeTargetForArea("nav-bar", window).prepend(newControls);
CustomizableUI is the component that manages all the user-customizable buttons. The system you use to drag and drop them to wherever you want. getCustomizeTargetForArea(area, window) is a function that locates one of the customizable areas. There are several customizable areas. The nav-bar is one of them, the tabs toolbar is another, then there's the bookmarks bar, the menubar, and the overflow list.

Each of those customizable areas has a certain type, like toolbar, menu, etc. And they all have a child element called a customization target, which is where all the user-customizable buttons go. So the chevron and menu button aren't actually user-customizable. You can't move or remove them since they're not inside the customization target. prepend(newControls) just means put the new controls at the beginning of the customization target. So it gets to be the very first element in the customization target.

Which works since there aren't any other elements to the left of the customization target. But the chevron and hamburger buttons are both to the right of the customization target. You can find the customization target in the browser toolbox to see this yourself. Just search for #nav-bar-customization-target and you'll see it's a long rectangle including most of the nav-bar but not the chevron & hamburger buttons.

So if you want to put the window control buttons on the right side, you need to do this a little differently, appending it to the nav-bar instead of the customization target, and placing it after the hamburger button.

(function () {
    function init() {
        let newControls = document
            .querySelector("#toolbar-menubar .titlebar-buttonbox-container")
            .cloneNode(true);
        newControls.id = "navbar-window-controls";
        newControls.setAttribute("removable", false);
        document.querySelector("#PanelUI-button").after(newControls);
    }
    if (gBrowserInit.delayedStartupFinished) init();
    else {
        let delayedListener = (subject, topic) => {
            if (topic == "browser-delayed-startup-finished" && subject == window) {
                Services.obs.removeObserver(delayedListener, topic);
                init();
            }
        };
        Services.obs.addObserver(delayedListener, "browser-delayed-startup-finished");
    }
})();

[henryxrl]

I see! So you find the #PanelUI-button and append the newControls after it. Where do you know all the stuff about Firefox? Wish I know it too so that I can fix all the problems I encounter myself, haha.

[aminomancer]

Well if you learn how to use the browser toolbox to inspect events and jump to the source code in the debugger, it's pretty easy to find the source code that does a given thing. You can use searchfox.org to find anything in the source code. The source code often has a bit of documentation in it. And then if there's something I can't figure out I just ask in the https://chat.mozilla.org developers room, and usually someone gets back to me. In theory there's also documentation on here but it's not exactly geared toward writing custom scripts, it's mainly intended for people contributing to firefox's source code. But often those things overlap since these autoconfig scripts sort of function as additional source code.

[aminomancer]

Mainly I just figure this stuff out by trial & error. There isn't a textbook or course on it anywhere unfortunately. I'm just very comfortable messing with things so I have stumbled on a lot of stuff by messing around in the browser toolbox console. I also spend a lot of time on https://bugzilla.mozilla.org and I spend a lot of time reading the source code on https://searchfox.org so I can learn how to replicate something from the source code by just reading how the source code does it. Firefox's UI is a lot like ordinary web design. It is built with markup, dynamically controlled by javascript, styled by CSS. It's extended by modules that are called components.

The main difference is components can be in binary languages too, C++ and Rust mainly, but also some Java and I think there's Python involved in the build system, don't really remember. Firefox is all linked together by XPCOM. This lets my scripts call binary functions or hook binary interactive systems or timers/intervals, even though all the scripts are executed by Firefox's normal JIT ECMAScript interpreter. A bunch of these binary components are exposed through the global object. So on the global object is a property Components and that has properties like classes or interfaces or utils or manager, which contain giant lists of class IDs, interface objects, etc. These objects are abbreviated, i.e., Components.classes can be referenced in a script or in the browser toolbox console by Cc and Components.interfaces by Ci, etc.

Anyway inside those are a lot of binary components or ways of referencing them. For example if you look at aboutCfg.uc.js it's really heavily linked up with XPCOM. Because it's creating a new about: page and most of the about: pages are built using this interface Ci.nsIAboutModule that sort of functions like a template but ensures the security of the page, I have to use it to create a new one. I mostly figured that script out just by imitating other component factories in the source code.

There are many other global objects like Services and ChromeUtils and XPCOMUtils and more. So you can think of these as like libraries that extend the basic pure javascript. Another way the Firefox UI deviates from a normal webpage is that it uses multiple markup languages, namespaced xul or html. This causes some confusion for people using CSS to customize Firefox but it's pretty easy to get the hang of. Anyway, everything else that really differentiates Firefox from a normal webpage comes down to the functionality of its components. So by reading the source code it's simple to find things that use a component and figure out what that component does and how to reuse it.

Most of the stuff I do with these scripts is actually pretty simple. The most complicated thing I have done involves communicating between the parent process (the chrome document, basically the main UI that you style with userChrome.css) and content processes (the stuff you style with userContent.css). That usually requires using a series of components called message managers and frame scripts. You can look at this script for an example. Basically you use this frame script method because it injects your specified script into every content window that opens. So every tab you open basically.

But it injects it via a special wrapper so that it can interact with the content but it can also send and receive information to/from the parent process. So the frame script is set up with some kind of system that listens to the content and sends information up (sendSyncMessage) to the parent process; and the rest of the script is set up with a message listener that does something upon receiving a message from the frame script. And sometimes vice versa, where you send a message down to the frame script and it does something to the content based on that. That system was pretty hard for me to figure out but basically all I did was imitate what I saw in the source code, and I read a guide that no longer exists unfortunately, but there's a backup of an older version of it here.