Sideberry expanded width locked to 200px / animation delay?

[Raspberry32]

Normally I'm fairly fluent in modifying these .css files and locating the appropriate variables, but despite reading all of the posts here, digging through the suspect .css files and modifying every potential variable to change the expanded width of the Sideberry tabs, the width seems to remain locked to 200px. I can change the collapsed width with the "--uc-sidebar-collapsed-width" variable in settings-sidebar-sideberry.css. Changing any of the "max-width" settings nearby seems to have no effect. I tried experimenting by adding some lines from my Sideberry setup in Floorp browser, such as "--uc-sidebar-hover-width: 250px;", but I'm thinking it must rely on some non-existing references as it also had no effect.

What's more, while I was able to change the expand/collapse animation transition speed, I'm struggling to locate which factor controls the delay of that animation. I thought it to be "--uc-autohide-sidebar-delay:, but I don't believe it's had an effect.

Thanks for any insight on this matter.

[Raspberry32]

And in typical tinkerer fashion, I immediately resolved the first issue... leaving this up to be kept, removed, or modified at your discretion.

I hadn't seen anywhere that if you hover your mouse at the left edge of Sidebery, you'll find a bar you can drag to set the width of your sidebar. My Sidebery in Floorp doesn't have this function. Found it by pure luck...

The animation delay issue remains, however.

[soulhotel]

Solution down there. On a side note, the github wiki has been annoying me a bit. the organization, structure, and search ability, isn't as good as it can be so I am in the process of setting up a wiki.js for future reference.

[soulhotel]

Was typing this out but see that you found one solution.

The only fixed width is only for when sidebery is collapsed

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Line 137 in 9fa1bb4

--uc-sidebar-collapsed-width: 38px;

This allows the sidebars to remain resize-able with splitter even if it's in a forced position. The splitter itself can't be positioned with the sidebar width, so the best thing to do - to keep it available with a forced position sidebar + keeping resize-ability, was to position the splitter before the sidebar.

For the delay, --uc-autohide-sidebar-delay was a reference to how I used to do it but stopped using it since i set them all to 0 anyway, the variable isn't being used in the transitions, you can see that in line 142 "0ms", line 164 "0ms", line 169 "0ms", line 171 "0ms". All of the zeros in the transition property are the delay.

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Lines 136 to 143 in 9fa1bb4

	#sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:not(:hover) {
	--uc-sidebar-collapsed-width: 38px;
	--uc-autohide-sidebar-delay: 0ms;
	position: relative;
	min-width: 14em;
	max-width: var(--uc-sidebar-collapsed-width) !important;
	transition: max-width 0.2s linear 0ms !important;
	}

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Lines 163 to 167 in 9fa1bb4

	#sidebar-box {
	transition: max-width 0.4s linear 0ms !important;
	min-width: var(--uc-sidebar-collapsed-width) !important;
	will-change: max-width;
	}

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Line 169 in 9fa1bb4

transition: max-width 115ms linear 0s !important;

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Line 171 in 9fa1bb4

transition-delay: 0ms !important;

[Raspberry32]

Lightning fast response mate. Thanks for the info. I'm all cleared up on the splitter bar (I had a quick setup with Floorp previously and never had to so much as think about them before lol). Forgive me though, I think I'm still missing something about the animation delay.

Example (Firefox/ffultima/Sidebery) -

Quick flicks in and out of the sidebar result in a rapid expand/collapse, but leaving my mouse in the sidebar for longer than 1s or so, then removing my mouse results in quite a (relatively) long delay before the collapse. Is that to be expected? My Sidebery in Floorp doesn't appear to have that delay.

Example (Floorp/Sidebery)

If I'm understanding, settings all of those "transition" values to 0 should result in instant, snappy transitions? Are we meant to discern which lines (142, 164, 169, 171) control which aspect of the transition (expand / collapse / etc)?

[soulhotel]

By default theyre all 0 (like in my gif above) so noone should have a delay for sidebery. line 142, defaulting to 0s, for speed & delay when not hovered, this would be the cause of the delay in your video.

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Line 142 in 9fa1bb4

transition: max-width 0.2s linear 0ms !important;

line 164-171, defaulting to 0s, would be the speed & delay overall (when hovered/static/expanded)

FF-ULTIMA/theme/settings-sidebar-sidebery.css

Line 164 in 9fa1bb4

transition: max-width 0.4s linear 0ms !important;

Can compare the original to yours if needed https://github.com/soulhotel/FF-ULTIMA/blob/main/theme/settings-sidebar-sidebery.css

[Raspberry32]

I see - line 142 is the culprit for the delay, indeed.

I had set lines 142 and 164 to 1.0s for a bit of a slower "open / close" animation, which works well for the "expand" animation in line 164, but, for example, if I set line 142 to an extreme value such as 6.0s, the collapse animation won't actually begin "collapsing" until about 5.0 seconds in - the final 1 second taken up by the collapsing of the sidebar. The expected result is that the sidebar would slowly collapse from right-to-left for the entire 6 second duration.

All that to say, setting line 142 to a lower value such as 0.2s does make the delay shorter, albeit collapses quicker. I can live with that! I can't say I'm not curious about the above, though. Quirk or by design?

[soulhotel]

sorry, what are are you curious about, i don't understand.

[Raspberry32]

Sorry if I was unclear - If I wanted a really slow collapse animation, I'd set line 142 to 6.0s, which is what I did in the gif in my previous post. The gif shows that the sidebar doesn't start collapsing until about 5 seconds in. The actual collapse "animation" only lasts about 1 second. It's as if there's 5 seconds of delay and 1 second of animation, rather than 6 seconds of the actual collapse animation.

I wasn't sure if this was expected behavior,

[soulhotel]

Ohh okay, just be sure you are correctly setting the speed and not delay:

 transition: max-width (speed) linear (delay) !important;

Actually I see what you're talking about now about something being quirky.. Either the set speed on collapse is being used as if it's the delay or there's something interfering with the values. But I cant find anything in the source overriding the transitions..

And this section of code is the only place in the theme where sidebar transition is done too. So for a workaround, a bit hacky, but consistent at least. Basically, subtract time from the delay (wherever it's coming from). I did -2s for a 3.2s linear transition, -2.8s works well with a 4s linear transition.

Copy this code (replacing the "autohide sidebery" section) and let me know if it's progress:

replacement section

/* autohide sidebery ---------------------------------------------------------------------------------*/

@media -moz-pref("ultima.sidebery.autohide") {
@media not -moz-pref("ultima.sidebar.autohide") {

/* this method allows the sidebar-splitter (resizeable bar) to be used to resize the expanded sidebar width */

    #sidebar-box, #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"] {
        will-change: max-width !important;
    }    
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:hover {
        /* animation when expanding (speed, delay) */
        transition: max-width 0.2s linear 0s !important;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:not(:hover) {
        /* animation when collapsing (speed, delay) */
        transition: max-width 3.2s linear -2.2s !important;
    }
    
/* positioning, collapsed width, minimum & maximums */
    
    :root {
        /* used to match content with sidebar in various "spacing" scenarios*/
        --browser-content-margin-4-sb-autohide:40px;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:not(:hover) {
        /* collapsed width */
        --uc-sidebar-collapsed-width: 38px;
        position: relative;
        min-width: var(--uc-sidebar-collapsed-width);
        max-width: var(--uc-sidebar-collapsed-width) !important;
    }
    #main-window:has(#sidebar-splitter:hover) #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:hover,
    #main-window:has(#sidebar-splitter:hover) #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"]:not(:hover) {
        min-width: var(--uc-sidebar-collapsed-width);
        max-width: 75vw !important;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"][positionend] {
        direction: rtl;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"][positionend]>* {
        direction: ltr;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"][positionend]:-moz-locale-dir(rtl) {
        direction: ltr;
    }
    #sidebar-box[sidebarcommand="_3c078156-979c-498b-8990-85f7987dd929_-sidebar-action"][positionend]:-moz-locale-dir(rtl)>* {
        direction: rtl;
    }
    .sidebar-panel {
        background-color: transparent !important;
    }
    
}
}

[Raspberry32]

Incredible. Ultimately I dialed it down to "expanding: 0.9s, 0s" and "collapsing: 1.2s, -0.9s" for a quick but smooth in-and-out.

Hacky, maybe, but solved the problem! Great work and lightning fast support. Thanks a ton!

[soulhotel]

Awesome, and np.

[soulhotel]

Updated settings-sidebar-sidebery.css, but you should try the replacement section above instead, with the slower collapsing speed (no delay).