Prevent sidebar content layout from getting squished

[sonofevil]

I feel like the width of the sidebar content should stay the same even when hidden, to prevent the content layout from changing every time you hover/unhover. But maybe there are reasons to want that behavior I can't think of right now, and this should be a patch instead?

[MrOtherGuy]

The fact that layout is affected is actually pretty useful for for example sideabar tabs. It allows the extension content to "know" about how wide its viewport is and thus change its internal layout accordingly.

But I wonder if there is some specific use case where that would not be wanted?

[sonofevil]

The fact that layout is affected is actually pretty useful for for example sideabar tabs. It allows the extension content to "know" about how wide its viewport is and thus change its internal layout accordingly.

But I wonder if there is some specific use case where that would not be wanted?

Yeah I actually use Sideberry for sidebar tabs, and the narrow layout means the pinned tabs push the unpinned tabs out of the viewport since they are limited to a single column.

40px isn't enough to display tab titles anyway so there is no advantage in my use case.

[sonofevil]

My setup looks like this. It's set to 63 pixels wide to leave room for the tab group headers on the left. In the collapsed state I'm fine with only seeing the icons of unpinned tabs. Only problem is that you only see the leftmost column of pinned tabs, but personally I don't need to see pinned tabs in the collapsed state at all.

[MrOtherGuy]

Okay, I see the issue but I don't think that should be dealt on autohide_sidebar.css side. Instead, you should change the layout of sidebery so that it doesn't try to wrap pinned tabs into single column when its viewport gets very narrow.

I believe you could do that from sidebery, style editor like this:

#root:is([data-pinned-tabs-position="top"],[data-pinned-tabs-position="panel"]) .PinnedTabsBar,
.NavigationBar .main-items{
  min-width: 210px
}

But I can't really be sure if it works just like that for you, because apparently Sidebery has a whole load of different layout options and I don't know what specific ones you are using.

[sonofevil]

So no interest in a separate patch either?

[MrOtherGuy]

Right, sorry I meant to say that it might be a useful addition and I would accept it if you make it so that it's opt-in feature behind some pref like maybe userchrome.autohide-sidebar.clip-overflow. As an aside, I guess this also makes it unable to animate the width - but that doesn't matter if it's opt-in.

Since this only requires few additional rules you can add them inside media query like so:

@media (-moz-bool-pref: "userchrome.autohide-sidebar.clip-overflow"){
  /* insert new rules here */
}

[MrOtherGuy]

I've been thinking about this and it is pretty straightforward except for one thing; when sidebar is positioned at right then clipping overflow requires one of two things. Either:

1. Contents are clipped to show only right edge (which is different to "normal" behavior, and probably not wanted)
2. Layout needs to be changed anyway so that even though internal layout won't change the visible part is moved to show only left edge when sidebar is collapsed but then reposition it when hovered.

I think that option 2 feels better, but styling that has to work a bit differently. Essentially in non-hovered state the overflow should be clipped outside of window and then apply some transform to the sidebar-box to move it over web-content. The transform should be able to be computed from the two variables we are already using and it can actually animated as well.

[sonofevil]

Btw is it completely impossible to consistently keep the sidebar open during drag and drop? If I use d&d within Sideberry, it doesn't count as hover, and there doesn't seem to be any class or pseudoclass in the browser html which indicates that I'm still interacting with the sidebar.

[MrOtherGuy]

Sadly yes, on Linux anyway. I filed bug 1818517 about this a while back. It doesn't concern only sidebar, but all hover vs. d&d interactions.