Show last active tab in tree as "parent" when tree is collapsed?

[reallyuniquename]

Is there any way to show last active (selected) tab in tree as "parent" when tree is collapsed?

Expanded tree:

▼ Main page
    Page1
    Page2 [last active tab in tree]
    Page3

Collapsed tree:

▶ Page2

It would allow to work with tabs inside huge trees without actually expanding whole tree.

I'm trying to migrate to TST from legacy tab stacking extensions and this feature is part of my core workflow, it would help a lot.

[piroor]

The idea is interesting. Hmm, but I'm afraid that it will make things complex - it requires more codes because current TST is not designed to do such a thing.

I have no plan to implement this feature by myself, but I'm interested to know this feature is really useful or not. Something prototype implemented by someone possibly change my mind, and any pull request is welcome.

[reallyuniquename]

Unfortunately I can only suggest legacy addons which have that feature implemented: https://github.com/yfdyh000/tabutils/blob/Fixed/chrome/content/tabutils-st.js (extensions.tabutils.dragToStack = true)

Currently, TST is the only tab management extension for power users on Firefox Quantum.

[irvinm]

Interesting idea, but definitely sounds like it will make things more complicated. @piroor I recommend we tag this "won't fix" (maybe leave "help wanted") and close out the issue.

[piroor]

Before marking as "won't fix", I've tried to implement the feature with minimum changes on a branch to confirm its cons and pros: https://github.com/piroor/treestyletab/tree/allow-collapsed-active-descendant You need to clone the repository and build the package yourself. It is interesting, but there are some concerns, for example: how should we treat the tab on drag and drop.

[irvinm]

I'll let @reallyuniquename give his thoughts on this and try it out. For me, I probably wouldn't use this feature (would prefer an option to enable\disable this).

However, here are my thoughts on the topic as I could see why people would want to use it:

• Collapsing a tree would effectively take the most recent active tab within the tree and make it the parent.
• The original parent would be made the first child tab. (I would think you would want most recent as the parent and the next most recent as first child, 2nd most recent as 2nd child, etc.)
• If the tree is collapsed, dragging the parent would drag the entire tree to a new location.
• If dragging a tab from inside the tree, would just remove it.

IF you are not moving the most active tab to be the parent and just showing a representation of it as the root, that might change things.

[piroor]

I've done more changes on the branch. Spec:

1. Last active tab in a collapsed tree becomes "frontmost". The "frontmost" tab is shown instead of the real parent of a collapsed tree.
2. When you start dragging on a "frontmost" tab for a collapsed tree, the real parent tab is dragged instead.
3. While you are dragging something on the sidebar, the "frontmost" tab disappears and the real parent tab become visible.
4. A tree can have only one "frontmost" tab. If you click any other tab in the tree, it becomes the new "frontmost" tab and the old "frontmost" tab in the tree becomes regular collapsed tab.

For example, assume that there is two trees like:

• A
  • B
    • C
      • D
  • E
• F
  • G
    • H

When the tab D is active and you collapse C, they become:

• A
  • B
    • D (real parent: C)
  • E
• F
  • G
    • H

When you collapse B, they become:

• A
  • D (real parent: B)
  • E
• F
  • G
    • H

When you drag something over these trees, they become:

• A
  • B
  • E
• F
  • G
    • H

After you drop the dragged object, they become:

• A
  • D (real parent: B)
  • E
• F
  • G
    • H

If you click F, G, or H, the D is still "frontmost". However, if you click A or E, due to the spec 4 they become:

• A
  • B
  • E
• F
  • G
    • H

[piroor]

I'm planning to judge to do or don't merging this branch to the master, after dogfooding for a while. If the behavior feels oddly for me, I won't merge it.

[irvinm]

You had me until the very last step. I would have thought that clicking on either A or E would ONLY affect the root of that tree and would show A or E, but that the "tree" showing D (with real parent B) wouldn't change as D is still the most recent tab in that tree.

Basically, I would think that the "head" of each tree would be the most recent tab of the children below it. I think if I used this, I would still want to see "D" instead of "B" for that sub-tree as that is still the most recent tab from that tree.

I could see this being a little confusing with nested trees and how the tabs will continue to change depending on what you click on. IMHO. Maybe it would just take some time getting used to.

[piroor]

I agree that the restriction (spec 4) should be removed and I've tried to implement more flexible system to do that. And finally I've given up to implement completely smart system based on the current implementation... I shouldn't do this with the current approach, instead I need to change the architecture.

[piroor]

On TST 3.0, an internal tab object and its corresponding tab element are separated. So, I should separate them more: 1) internal tab object, 2) its corresponding tab element, and a new part 3) a tab object for rendering. Currently the internal tab object is directly used to render for its tab element, but if I can use another tab object just for rendering, such a tab will behave like as "it is actually B, but its appearance is D".

[irvinm]

Have you considered just physically moving the tabs when the action of collapsing of a tree is done rather than creating another virtual aspect (display rendering) of a tab? (Move the active sub-tab to the root of that tree and move the current parent to be the first child ... update parentIDs as appropriate) I am just wondering if all this potential complexity is worth the gain.

Just my personal opinion obviously. :)

[piroor]

I think I should not rearrange tabs physically on this case, for compatibility with other addons. I'm afraid of troubles around combination with other addons observing tab moves. Rearranging of only tracked tab objects (without applying their order to Firefox's native tabs) looks dangerous also. TST is designed expecting completely synchronized order between tracked tab objects and Firefox's tabs, and long-live unsynchronized orders will introduce more problems.

[irvinm]

Good point. I agree with the tab object for rendering then.

[irvinm]

@piroor are you still considering this?

[piroor]

The experimental branch is now too far from the master due to changes around WebComponents...
(Here is the total changes on the experimental branch: master...allow-collapsed-active-descendant )

Now TST has the "locked-collapsed" state for tabs. I think we need to re-implement the experimental feature based on it. But sadly I lost my motivation about this, so I hope someone successor tries to do that.

[irvinm]

@piroor maybe we should close this for now ...

[piroor]

I thought about this topic again.

This feature looks not suitable as a builtin feature - it is too massive. I don't think it is very useful for all TST users. However, it still looks useful on some cases. So, now I think this feature should be provided as a helper addon communicating with TST.

But there are some missing APIs to implement such a helper addon. For example:

• Something way to embed something extra contents inside tabs, covering its contents.
• More notifications when trees are collapsed and expanded.

Such APIs may allow a helper addon to provide thumbnail in tabs. It was a feature lost on migration from the XUL version. I told as "I lost my motivation" but now it has became hot again for me. It may take more time but I hope to keep this unsolved.

[piroor]

https://github.com/piroor/treestyletab/wiki/API-for-other-addons#when-tree-is-collapsed-or-expanded

[piroor]

https://github.com/piroor/treestyletab/wiki/Tab-Extra-Contents-API

[piroor]

I've started to implement an experimental helper addon...
https://github.com/piroor/tst-active-tab-in-collapsed-tree

[piroor]

https://github.com/piroor/treestyletab/wiki/API-for-other-addons#suppress-unintentional-focus-change-by-tst
https://github.com/piroor/treestyletab/wiki/API-for-other-addons#suppress-unintentional-expansion-of-collapsed-tree-by-tst

[piroor]

A development build is now available:
https://piro.sakura.ne.jp/xul/xpi/nightly/tst-active-tab-in-collapsed-tree.xpi
It requires the latest development build of TST itself.

[irvinm]

@piroor did you want to continue with this item or close this out? It is an interesting idea, but I am not sure there is a lot of demand for it. I did try out the XPI to just see how it worked and it seems to accomplish what you wanted it to do. I think the visual look of showing a child tab as part of the parent tab feels weird, but does accomplish the goal. (Honestly that is probably a good solution to the problem)

[piroor]

Oops I forgot to close this...

After further testing I've realized that this feature is quite useful for me, and now it is available on AMO website: https://addons.mozilla.org/firefox/addon/tst-active-tab-in-collapsed-tr/

But I still think it is too much as a built-in feature of TST. I'll keep it as just an optional helper addon and maintained. It looks a good motivation for dogfooding of TST's API.