7

With nested vertical tabs enabled, closing a parent tab currently shifts the first child up to replace the closed tab. It would be more natural for all children of the tab to be promoted up rather than just the one.

Here is how it currently functions:

Here is how I am proposing it to work:

Tab 1
    Tab 2
        Tab 3
        Tab 4
            Tab 5

↓
(Close tab 2)
↓

Tab 1
    Tab 3
    Tab 4
        Tab 5
    10 days later

    bestlem The close button currently closes entire trees when they are collapsed (which feels natural since the whole tree is now that one entry), but having it close a whole tree even when expanded would be very surprising and would mean there'd be no way to close just the parent tab while preserving the children – a step back from the current functionality in my view. There's also a 'Close Tree' item in the context menu in either situation.

      @adamaveray That depends on your use

      I very rarely collapse a tree - perhaps I put to do that more. So your comment makes sense.

      I definitely never want to close the parent and leave the tree. So that reasoning does not work for me.

        6 months later

        Currently, when you have a tab with several "child" tabs, e.g.

        • Tab A
          • Tab B
          • Tab C
          • Tab D

        When closing Tab A, the inheritance structure will be changed as such:

        • Tab B
          • Tab C
          • Tab D

        In my view, the group should be undone i.e. tabs B, C and D should all move back one level of depth.

          Merged 2 posts from Closing the parent vertical tab should not inherit parent state to first child tab.
            5 months later

            I definitely never want to close the parent and leave the tree. So that reasoning does not work for me.

            bestlem Personally, this is the vast majority of how I use tree-style tabs: open tabs are something like a 'todo list'; I use ⌘-click to 'open in background' a series of new tabs as I read through a resource or page, then work my way through the unvisited tabs, closing irrelevant ones or potentially spawning new subtrees as I work. (I will also often have a remaining, longer-lived tree-structure of resources that ended up valuable to me, that I will continuously refer back to as I work; although that's usually only a handful of the tabs I initially open during the exploratory/research phase of my task.)

            To me, it seems reasonable to me that the default behaviour of clicking the 'X' in the sidebar should differ based on whether the tree is visible or not - but it does not seem intuitive. I don't think this behaviour is obvious, without a meaningful indication within the UI; but I do think it is the correct path to proceed down.

            My suggestion would be to modify the visible interface depending on what the action will actually result in:

            1. When the tree is collapsed, replace the x with a double-struck x/x; include a tooltip indicating it will close the tree; and the first time the user clicks it, ask for confirmation (unless they've explicitly modified the 'close child tabs' option)
            2. When the tree is expanded, and you hover over the x next to a parent tab, popover a second double-struck x/x button directly below it that can be clicked to close the whole tree without mousing over to the 'collapse' icon first.

            As for hotkeys, perhaps a configuration-option is valuable; but given that there's already a menu-item for "Close Tree," a better solution IMO would be to ensure that that function is always available (it's currently greyed-out for single tabs that don't have children, which seems silly to me) - then a user like @bestlem can use the system-global features to make that their default ⌘W "close-tab" behaviour, if they wish to.

                Now, regarding the OP:

                Although the above-described behaviour is better than the current "promote a child", and the default in piroor's Tree Style Tab; I'd argue that the tree-structure should be maintained when closing tabs. (See my other post, https://orionfeedback.org/d/10674-closing-a-parent-tab-should-retain-the-tree-structure-not-promote-a-child)

                If you close a tab with children with children using ⌘W, I believe the sidebar's structure shouldn't change - the active page should be replaced with an 'empty' tab (about:blank, basically, but whatever the browser currently uses with ⌘N), and the focus/viewport should move onwards to whatever the next-selected tab would be if it had closed.

                If the user actively wants to remove the subtree, IMO, that's a separate user-intent, and needs a separate indication; but personally, I never want tree-structure information "thrown away" while I still have any of the children present. The whole point of tree-style tabs is to preserve and present metadata about a page that you may have forgotten while you were onwards to other tasks: "where did I find this page? why was I even here? what do I go back to doing when I finish on this page?" - the parent represents all of those things; and just because I don't need to keep interacting with the parent tab "as a wepgage" (and don't want it consuming the resources on my machine) doesn't mean those facts aren't still true.

                Effectively, at least in the ways I've seen people using it, tree-style tabs are halfway between a history interface and a RAM-usage/activity-monitor interface: what have you been doing recently, and what is your browser currently still doing because of those actions you took. Surfacing information related to those two purposes, and controls to affect those two purposes, feels paramount. (=

                  6 days later

                  ELLIOTTCABLE Interesting, your workflow is very different to how I use tree-style tabs. It sounds like you're using them as somewhat of a mix between tabs and folders, so perhaps this feature request might interest you? https://orionfeedback.org/d/79-tab-folders Assuming folders were implemented perhaps adding a new "Convert to Folder" context menu item to top-level parent tabs would help your workflow.

                  Either way I'm sure you're already aware but for now you can manually suspend a parent tab via the context menu to preserve the tab information while conserving your system's resources. Personally the idea of having ⌘W not close the tab but instead convert it to about:blank or equivalent feels very counterintuitive, but interesting to hear different tab workflows.

                      Oh, and to be clear, the about:blank description is a bit of a hack — Orion generally seems to go in for much smoother UX than that; that's just what TST/FireFox did.

                      I suppose what I'm picturing could be called a tab-folder? But I basically imagine the best way to implement it would involve zero interactability, nor any user-input whatsoever to produce: it's just "the tree structure that was present before closing a tab, retained as visual metadata."

                      I suppose one could right-click it to close and keep all children or something; but I rather strongly suspect that any sort of "assume users will interact manually with the tree" is misguided - maybe some of us power-users do; but it's probably best to not require that for a user to extract the best behaviour?

                      Here, revel in my gorgeous photoshop skills! 🤣

                      Before closing parent:

                      After closing parent:

                      Anyway, I'll leave it there. Getting a bit too down in the weeds, probably; I'm sure they'll come up with something fluid.

                      No one is typing