Many tabs overlapping with bottom buttons

[Kaedriz]

As stated above, documented below. Although simple fix to max height seem to work, but needs to be done dynamically using variables and probably vh.

[Kaedriz]

But this one will be tricky, as buttons on bottom are user configurable, and dunno if we have a way to get that height to CSS.

[Kaedriz]

@soulhotel, can you see for yourself this branch? Code was reformatted, because bc I just can't write code that is not indented. Overall bottom buttons were changed to be flex elements, no longer position: absolute, it is advanteus in a way that we can write tab bar height dynamically. Ordering was reversed to sync what's displayed on customize page, but can be changed to not avoid existing users. And best of all, a tab bar that is somewhat usable with a multitude of tabs open. Only remaining problem would be full screen support I suppose, if even doable in the current form.

It's only prototype for now, to test things, if this does break something, but for now appears to be fine, only spacing is butchered, but didn't want to waste time with elements that are cosmetic only for prototype.

And on this topic, some changes are required to tab bar overall, like bottom buttons not expanding tab bar.

For now, I'm satisfied by this test, didn't think it would go this smooth.

My next idea with this would be pinned tabs, that are static on top of the bar, but still take space and scroll. Static part already work but scrolling, we will see. Oh and pinned indicator will need to be reworked I think(?). In my view, it is indistinguishable from current tab, dunno if this is a personal problem.

[Kaedriz]

Oh, when I went back to main didn't know customization panel was horizontal, will need to repair that too, as it in prototype seemed to change changed to vertical and bugs out.

[soulhotel]

I understand the indentation part, to be honest I thought what I was doing was organized, since before I started making themes, I wasn't looking too much at other peoples code. Its going to be a lot of work to reorganize the whole project though, but ill try to indent from now on as well.

In terms of changing the buttons to flex, this will not work. The buttons are toolbar buttons that are SIBLINGS to the tabbrowser-tabs. And hovering over the buttons are independent to hovering the tabbrowser-tabs. So to get them to act accordingly:

:root:not([customizing]) tabbrowser-tabs + toolbarbutton { } + for targetting siblings after the element :root:not([customizing]) tabbrowser-tabs ~ toolbarbutton { } ~ for siblings preceding the element

I'll test it out and see if this works well

But as you can see, with flexed buttons they dont display, and the titlebar spacing is effected as well:

Lastly, the minibuttonbar, its very limited by just css, if you were to adjust the tabs height according to the number of buttons effected then the tabs would be like 60% of the view height of the browser and it would look weird which sucks. So my solution was to just make it optional, where you can just drag the buttons out

[soulhotel]

Alright so for the hovering over buttons this works, going to add this to function-tabs-autohide files:

:root:not([customizing]) toolbarbutton:hover + #tabbrowser-tabs {
    width: var(--uc-vertical-tabs-width-revert);
}
:root:not([customizing]) toolbarbutton:hover ~ #tabbrowser-tabs {
    width: var(--uc-vertical-tabs-width-revert);
}

[Kaedriz]

What do you mean they don't display?

Even customizing them works, but axis got changed as a side effect, probably could be fixed with precised selectors.

[Kaedriz]

And this thick border, I said that this is only prototype to test things, cosmetic changes like these (padding, margin etc) would come later if this could be pulled off, actually. Will polish things tomorrow to reach somewhat cosmetic state of main branch.

[Kaedriz]

And about hover, can't you take hover action from #TabsToolbar-customization-target, and then propagate it to child selectors? It would eliminate this issue, along with other causing tab bar to not expand when cursor is on left screen border. Maybe there are some implications that this can't be used? As far as I can see, this ID only targets left tab bar.

#TabsToolbar-customization-target:hover #tabbrowser-tabs {
    width: ...
}

[soulhotel]

And about hover, can't you take hover action from #TabsToolbar-customization-target, and then propagate it to child selectors? It would eliminate this issue, along with other causing tab bar to not expand when cursor is on left screen border. Maybe there are some implications that this can't be used? As far as I can see, this ID only targets left tab bar.

#TabsToolbar-customization-target:hover #tabbrowser-tabs {
    width: ...
}

Right, you can do that as well!

But for the toolbar buttons, I put your branch on a new install and that was my result? this one right: https://github.com/Kaedriz/FF-ULTIMA/tree/tabs-overflow

[Kaedriz]

Yes, that one. I'm using it myself, with only change to enable second autohide element, didn't know why i didn't uncomment another one.

Are you having anything in that bar though? Maybe this is profile related, as position saved in profile data.

[soulhotel]

Yeah i dont know why it was showing up like.... Nevermind!

• Using order to position the buttons instead of what I did is genius! I honestly didn't know you could do that here.

• I really like this idea, it will need further testing,

• i transferred the height adjustments for when bookmark bar is active and full screen is active -> over to the #TabsToolbar-customization-target element, will probably have to make this similar adjustment throughout the whole theme

• the backgrounds for the context menus that sit inside of the #tabstoolbar are being overwritten, this is an easy fix for later.

But so far this looks really good! Once im free I can power through these changes and get the next release up.

[soulhotel]

Also I put everything in the related files for the 1.6.8 branch https://github.com/soulhotel/FF-ULTIMA/tree/1.6.8 function-mini-button-bar.css position-verttab.css

Edit: the 1.6.8 branch already has the updates we've discussed earlier as well, such as the navigation bar centering.

[Kaedriz]

Oh, I was about to say, that you could just fork this branch and work on this on a separate branch, as 1.6.8 seemed almost ready for release, but nothing could go wrong with waiting a bit more days with this for full 1.7 maybe, as changes here are somewhat huge, at least in backend.

And about using absolutes, I would only use them as last resort, they tend to break very easily, or are hard to maintain with new features. This one seemed like a good use of flexbox as they were besides each other.

And about customizing these toolbars buttons, are you experiencing similar issue dragging as tabs? As that is my experience, icon slides to side when hovered. That's why I wanted that customization bar back horizontally. But this bar honestly this feels good to drag, unlike tabs, so I'm wondering what we can learn from it, to incorporate in normal tab dragging.

[soulhotel]

I noticed the dragging, its probably trying to use its default behavior, but its never going to be as bad as the tabs.

Im pretty sure the tabs width have inline script attached to it, I had to override them when i was first making the tabs functional. Its going to be more complex since we're dealing with the scrollbox but there may be a solution that i can work with here: https://github.com/MrOtherGuy/firefox-csshacks/blob/master/chrome/multi-row_tabs.css. That will have to wait until after this release though.

[soulhotel]

Also quick fix for the the context menus being effected, so you don't have to search yourself just add #TabsToolbar-customization-target to the shadow styling

/* Source code for shadow inspired by */
/* https://css-tricks.com/books/greatest-css-tricks/scroll-shadows/ */

#TabsToolbar-customization-target scrollbox {

[Kaedriz]

Also quick fix for the the context menus being effected, so you don't have to search yourself just add #TabsToolbar-customization-target to the shadow styling

/* Source code for shadow inspired by */
/* https://css-tricks.com/books/greatest-css-tricks/scroll-shadows/ */

#TabsToolbar-customization-target scrollbox {

Does that work for you, though?

For me, it doesn't even register selector.

It looks like it lies in Shadow DOM (?)

[soulhotel]

i noticed after but its pretty annoying huh, when i transfer the effect to .scrollbox-clip instead of scrollbox it works, but on restart and updated code, nope. There might be a less specific selector that can be used

[soulhotel]

alright it has to be the shadow DOM

from what i understand, the :host will adopt the added effects from 'scrollbox' being targetted, but targetting just 'scrollbox' will also effect irrelevant elements obviously. On top of this, you cant target inside of a shadow Dom (:host) unless you do it that way, or depend on an agent sheet. It leaves two options really..

finding every other scrollbox, and seeing if they can be overwritten to cancel out the effect, or.. redoing the theming of the context menus as it seems they are the only things being effected

I did find something interesting that could be worked with,

<scrollbar (etc,etc,...) disabled="true"/>

when the scrollbox overflows with tabs 'disabled' for its child element becomes true. It could potentially work as a 'non-specific' attribute to target with a scrollbox:has selector. I havent tried it yet though.

[soulhotel]

Shoot i fixed it. Nvm.

.scrollbox-clip scrollbox[smoothscroll="true"] { style }

this works.

[Kaedriz]

Yes, it seems to have fixed it.

[Kaedriz]

Is there a way to style depending on amount of tabs pined? Because that would allow us to move that overflow indicator when more tabs are pinned, essentially creating that separate zone for pinned tabs.

[Kaedriz]

Ok, got some progress using :has selector. It's pretty powerful, but should be probably used with care as could have slight performance degradation, but so far have seen none. It would enable us some interesting quirks as settings variable in parent then using that in another child, as used here:

#tabbrowser-tabs:has(.tabbrowser-tab[pinned]:nth-of-type(1)) {
  --tab-height: 40px;
}

#tabbrowser-tabs:has(.tabbrowser-tab[pinned]:nth-of-type(2)) {
  --tab-height: 80px;
}

Code is boilerplatyy, but that just quirks of CSS. Then position overflow indicator derived from this variable, and you got an indicator in different position depending on amount of tabs pinned.

Will look for more robust solutions, not requiring so much boilerplate, but don't have much hope.

Another thing on similar topic I would like to pursue is, sticky active tab. There are times I just don't know what tab I'm on, and this would surely help in navigating. This shouldn't be any hard, maybe just interaction with pinned tabs is gonna be pain in the ass, and absolute positioning.

[Kaedriz]

Ok, pushed this and other changes, most notably:

• Toolbars button initial styling (Thinking if labels are okay by default, or should stay behind option, as they are still some quirks behind them)
• Sticky active tab
• Made basic customizing toolbar view (Something you have done similar before, nothing much)
• Close button on active tab on hover
• Basic style for overflow indicator, needs more design research on how this one should look like.

Would need testing if these are stable.

After this update, we need to work ASAP on some refactoring, namely:

• Some spreadsheet of sort, that includes all current variables and what they accomplish, default values etc. It will help not only end users, but future collaborators too.
• As I have said before, we need to come up with styling of code. This can be discussed separately, as there are some options.
• Changing most options to use Firefox about:config. I have seen other themes use this, and we should too, as this simplifies light modding, and enables hot swap of options I believe?
• And lastly, overall refactoring of code, commenting most of the styling, as I, or probably most other people can't digest something only from selector, I'm thinking more complex selectors like .tab-label-container[textoverflow][labeldirection="ltr"]:not([pinned]), .tab-labelcontainer[textoverflow]:not([labeldirection],[pinned]):-moz-locale-dir(ltr). This should be described what it does.

[soulhotel]

• Alright so! We have the new style of the mini button bar down.

• And the customize toolbar page follows a similar vertical layout.

• The new scrollbox overflowing shadow is fixed.

• Ive styled the overflow indicator good enough for release, and its modified for both light and dark modes.

• fixed the black box stutter from the shadow on light mode.

• I found that .scrollbox-clip scrollbox[smoothscroll="true"] wasnt an absolute solution :/, but Ive fixed the issues it caused in both light and dark modes (context menus wont be overwritten with colors).

• For the "sticky active tab" is it possible with just CSS? It would involve knowing the scrollboxs current position right? Where if the scrollbox is in the tabs peripherals, the tab would keep its current position. But if not, it would become an absolute position that stays at the top of the view.

• :warning: The themes using about:config were using user agent script to change styles, tools like auto-config for that. The alternative would be using userChromeToggle, but thats limited to turning a theme on/off.

• Ive managed to cut the source down 20mb! it grew a lot when i decided to add the preview images.

• Ive changed the help folder into a documentation folder, same as before it holds the modification page, and such.

• Ive also decluttered the README.

• edit: And I decided to leave the autohide on as default too.

The variables are self-explanatory, Everything related to colors is labeled accent/background/etc, -uc-light/dark are used interchangably to theme text between light and dark modes, selected/active for selected buttons (hovered) active for a button that has an active menu open, like extensions, then the border-radius and margins are only in the global positioning files labeled at the top and in the modification page as effected all windows, panels, borders, spacing, buttons and nothing else. Every other variable is just a default to Firefox that ive overwritten with my own. Regardless I do agree, I can work on a spreadsheet eventually and that would probably be for the doc folder.

Right now, im going to see how I can keep the buttons on the bottom aligned-left when hovered, then I'll go through every line of every file, organize them with indentations, and further organize what code belongs in what file.

Ive updated the 1.6.8 branch with all of this this will be a 1.7 release now. Check it out and Let me know what you think, what am I missing? https://github.com/soulhotel/FF-ULTIMA/blob/1.7/doc/change-log.md

[soulhotel]

Also for styling the pinned tabs you already know its easy, the hard part is deciding on how they should look. At the moment this is the format

.tabbrowser-tab[selected=true]

• this applies to the current active tab
• have a colored background matching the theme

.tabbrowser-tab[multiselected=true]

• when multiple tabs are selected
• have a colored background matching the theme
• have a selection border matching the themes accent color

.tabbrowser-tab[pinned="true"], .tabbrowser-tab[pinned=""]

• when a tab is pinned
• have a colored background matching the theme
• have a selection border matching the themes accent color

[Kaedriz]

For the "sticky active tab" is it possible with just CSS? It would involve knowing the scrollboxs current position right? Where if the scrollbox is in the tabs peripherals, the tab would keep its current position. But if not, it would become an absolute position that stays at the top of the view. No, at all, surprisingly. Only one caveat, the same as pinned tabs, would require a fair amount of boilerplate, to accommodate for the amount of pinned tabs.

You can check my branch for this and other changes. Toolbars buttons were done there too, with experimental labels, although there's slight border gap, it's a CSS war what's overriding what I suppose, will need polish, but works surprisingly well, could fill that void with something other than just free space. A topic of toolbars buttons, I have thought of idea like this, instead of wasting so much vertical space, we could go horizontal on hover, and just show 1 or several buttons depending on amount, that just show expanded vertical menu on hover, but that's just mind experimentation for another time.

⚠️ The themes using about:config were using user agent script to change styles, tools like auto-config for that. The alternative would be using userChromeToggle, but thats limited to turning a theme on/off. user.js is only for making default I suppose, as that can't be done in CSS.

I'm thinking more of user.js style, like this, docs, albeit I can't find original docs, not sure why.

[Kaedriz]

Ok, first thing I noticed, mouse to left border still doesn't show vertical tabs, in my branch, I have fixed this by applying :before element behind tabs and styling it like background to catch hover, as margin/padding/outline don't catch hover I think. Another one being toolbar buttons hover area have shrunk too, some regression in that regard. I have styled customize toolbar closed to its actual position, but it can be there as well if you like.

[soulhotel]

I'm thinking more of user.js style, like this, docs, albeit I can't find original docs, not sure why.

You know I have some experience with javascript but I never liked the idea of modifying useragents because theyre more of a headache than just userChrome alone when an update breaks things. But this still this is really good.

You could even use irrelevant config settings that dont necessary effect anything else (browser.aboutConfig.showWarning) as a toggle for certain styles.

[Kaedriz]

If we prefix it with a unique name, I don't see why this should break. Maybe if Mozilla abandons it, but this has minimal security implications, well, maybe aside from changing actual security configs.. but then you download userChrome, with already comes with some responsibility. Just think this would streamline most of the options settings, and not require Frankenstein-like code to be commented to disable. My only worry is, if updating would also break current user selected options, but that's actual problem even now, so nothing much to lose.

Link Even Mozilla uses it under the hood, I think? For their Nightly experiments.

[soulhotel]

Ill consider it, although the thing holding me back is that adding useragents to the theme makes it a lot more complicated for normal users.

And I would have to study for that also, Ive never played around with them before. If I do consider it, I'd probably just remove the tabs completely and create my own from scratch using the already present info in the tabs apis, that sounds easier to work with. But this is only spectulation.

[Kaedriz]

Excuse me, but what complications are you speaking of? user.js looks like this:

user_pref("general.smoothScroll.msdPhysics.continuousMotionMaxDeltaMS", 250);
user_pref("general.smoothScroll.msdPhysics.enabled", true);
user_pref("general.smoothScroll.msdPhysics.motionBeginSpringConstant", 450);
user_pref("general.smoothScroll.msdPhysics.regularSpringConstant", 450);
user_pref("general.smoothScroll.msdPhysics.slowdownMinDeltaMS", 50);
user_pref("general.smoothScroll.msdPhysics.slowdownMinDeltaRatio;0", 4);
user_pref("general.smoothScroll.msdPhysics.slowdownSpringConstant", 5000);
user_pref("mousewheel.min_line_scroll_amount", 22);
user_pref("toolkit.scrollbox.horizontalScrollDistance", 4);
user_pref("toolkit.scrollbox.verticalScrollDistance", 5);

And, from what can I see, is only limited to user_pref(). Its only purpose is to set about:config programmatically way by file, that supersedes browser default settings. We don't need any JS loader for this shit. We would only use our own variables with prefix to avoid name collision, we wouldn't touch firefox settings at all, preferentially.

Will write later proof of concept if this this works. This is completely separate from tabs issue.

[Kaedriz]

Ok, tested it, and it has problems recognizing custom variables, will need to investigate further how other themes do it.

But maybe using user.js isn't a final solution, as settings there are permanent. Users would need to delete that file after first install to apply their own settings, this is suboptimal. But I'm standing by the use of media (-moz-bool-pref: "some.setting.there"), as this enables hot swapping of modifications. Although it is limited to boolean values in my research, it still is super useful.

[soulhotel]

My bad i started mixing up the userchrome script and user script. The custom preferences should always work so long as its

1. in the right place
2. and boolean

[Kaedriz]

Yes, it's working, but I wanted there to be default, i.e. not expecting everything on user's end. Example: Tabs vertical bar could have background by default, but there could be an option to disable it and hide. But if it can't be done, then nvm. A potential workaround would be just using different wording: vertical.tab.background.disabled = false = unset value, and then we just apply condition in CSS to be active when this is true,

[Kaedriz]

My bad i started mixing up the userchrome script and user script. The custom preferences should always work so long as its

1. in the right place

2. and boolean

It is working, my problem lies in user.js and it's usage with custom variables.

[soulhotel]

Im liking this! I created a preference to remove vertical tabs, letting the user opt to use sidebery instead. And made some adjustments to the hiding tabs code. Another preference for toggling tab sizes. Made use of the position-verttab-gone.css file as a safeguard for users who might two tab sizes to true at the same time to only work when one is enabled at a time. Since I can only use booleans i cant just make a size string so this works just as well. Some more fine tuning needs to be done.

[soulhotel]

Referring to your comment it cam be done, when I'm back home 20 minutes I'll show what I did

[soulhotel]

alright i made the user.js relatively simple, no comments. I dont know what exactly you meant by no defaults but:

https://github.com/soulhotel/FF-ULTIMA/blob/1.7/user.js these are defaults, tab size L, autohide On, verticle tabs

For the first install when you place the user.js in the profile directory, you open firefox. The pref.js file already in the folder grabs the user.js every time firefox starts up. So when after you open firefox you can delete the user.js file.

When you change preferences like i did in the GIF above, it will remember these decisions.

Ive also added everything to the 1.7 branch, just simply wrapping the entire specific files in a media query.

[Kaedriz]

Don't know why, but this doesn't work for me. I have user.js with content:

user_pref("ultima.tabs.vertical", true);
user_pref("ultima.tabs.xs", false);
user_pref("ultima.tabs.s", false);
user_pref("ultima.tabs.l", true);
user_pref("ultima.tabs.autohide", true);

But in about:config I don't see it being set. It's the same for other variables.

Maybe Linux version is doing it differently.

[soulhotel]

Really.. and the custom pref's arent in the pref.js either?

it should be fine on linux after a quick search, it could be blocked by hardening settings, idk. You could try clearing startup cache in about:support, and also these settings are unrelated, but i did tweak them the first time i made the user.js, then youd have to copy/paste/restart again etc.

[Kaedriz]

No, they aren't from I'm seeing, weird that there is this setting ultima.theme.setting set to true, but probably artifact from the past.

Oh, nvm figured it out. As I have learned it from here, I thought this was supposed to go alongside userChrome.css, but there being chrome folder nuzzled me off. Just was in wrong direction I guess, but, doesn't this break actual folder structure? Or users would be asked to download this file separately. Entire repo could be moved folder downwards, but as there are other, profile related files, I would be hesitant with users doing something there themselves (ex. git commands).

[soulhotel]

yes look at the new readme theres also a video in "detail" right under.

its in the chrome folder so users can just copy and paste it, they will need to follow the instruction of opening firefox and deleting it anyway so they have to be aware of that.

sidenote, new squared option removes borders, border radiuses, margins:

[soulhotel]

Ive uploaded all edits to the 1.7 branch, updated modifications page with preferences, and all links throughout the files are established for the main branch. Im just about ready to release.

Wait, you added labels to the mini button bar on hover, i'll actually bring that over when i get back home

[Kaedriz]

It's still bugged somewhat, that causes a slight gap. Preferably it would mimic tabs behavior but had troubles setting it up.

[soulhotel]

It's still bugged somewhat, that causes a slight gap. Preferably it would mimic tabs behavior but had troubles setting it up.

Hey np. I just found this annoying little thing that you pointed out earlier, I thought I fixed it but it turns out the backwards/forwards icons by default arent centered like the other toolbar buttons.

[soulhotel]

alright, tried it myself and this was the result. only thing is, when not hovered, they jump a tiny bit to the right. I cant figure out why, but do you think this is good for release?

code

``` /* visual indicator, when hovered */ @media (-moz-bool-pref: "ultima.tabs.l"), (-moz-bool-pref: "ultima.tabs.s") { #TabsToolbar-customization-target .toolbarbutton-1:not(#tabs-newtab-button) { justify-content: left; margin-left:1px !important; } #TabsToolbar-customization-target:hover .toolbarbutton-1:not(#tabs-newtab-button) .toolbarbutton-text { display: flex; margin-left: 5px !important; overflow:clip; } #TabsToolbar-customization-target:not(:hover) .toolbarbutton-1:not(#tabs-newtab-button) .toolbarbutton-text { margin-left: 0px; display: none !important; } :root:not([customizing]) #TabsToolbar-customization-target toolbarbutton:hover + #tabbrowser-tabs { width: var(--uc-vertical-tabs-width-revert); } :root:not([customizing]) #TabsToolbar-customization-target toolbarbutton:hover ~ #tabbrowser-tabs { width: var(--uc-vertical-tabs-width-revert); } :root:not([customizing]) #TabsToolbar-customization-target:hover #tabbrowser-tabs { width: var(--uc-vertical-tabs-width-revert); } } ```

[soulhotel]

wait i know what this is, the icons are trying to match the width of the customization-target

[Kaedriz]

You are using display: none, and this is a big no, when you want something to gracefully disappear. In my case I just shrank it till it was near 0px wide, but there was still problems with it being flex element and not fully respecting width property, some hacking with max-min width is necessary I would presume.

[soulhotel]

The transitions werent effective, because the toolbarbuttons were set to be 100% the width of the container transitions just made the jump more noticable, and using width would .. yes what you said, the flex element not respecting the width.

Although i got it down now. Simply keep the icons at the 40px max-limit when not hovered. Very smooth.

Also note: I replaced the forwardback buttons at the nav bar, much better

[Kaedriz]

You could also fuse text labels with icons, but this would require slight changes in toolbar buttons.

On another topic, I found this doc, that should be helpful for spreadsheet.