Close Tabs to the Bottom as top-level menu item

[jareware]

Short description

☝️ most other menu items can be top-level, but the (arguably) most useful one has to be in the "Close Multiple Tabs" submenu.

Is there any way to have the "Close Tabs to the Bottom" option at the top level of the menu?

[piroor]

There is no option to do that. TST's tab context menu is designed to simulate Firefox's native one, and I have no plan to make it customizable until Firefox implement the option natively.

[bughit]

@piroor

You already have a great system for configuring the context menu. Close actions can be top level or in the sub-menu or both, as the user chooses. But then you take 2 close actions out of this flexible and powerful system, and put them in a new 3rd location for close actions and without any configurability. This makes no sense and undermines what you've already built.

• it doesn't matter how firefox does it, this whole project is an attempt to improve on firefox native
• a 3rd location for close actions is confusing and unnecessary, 2 is enough
• having 2 actions be un-configurable is frustrating and bewildering

Please plug them back into the existing system of menu configuration.

[piroor]

@bughit Please remind that the tab context menu on the sidebar has three categories of commands:

1. Commands to simulate Firefox's native tab context menu. "Close Multiple Tabs" is in this category. TST doesn't provide ability to customize for these commands.
2. Commands for TST specific features. You can customize these items via TST's options page.
3. Commands provided by other addons. You can customize them via options for each addon.

Commands in categories 2 and 3 are available in the context menu on Firefox's native tabs also. And Firefox doesn't provide configs for default commands in the menu. (You can show/hide them via userChrome.css, but it is not the standard way.)

And I decided that I don't provide customizability for commands in the category 1 on TST, due to following reasons:

• Basically, customizable features takes more cost to be maintained. I need to become very careful while I maintain such features.
• On the other hand, simulating Firefox's native context menu commands is also hard. Firefox is updated day by day and I need to pay attention to synchronize behaviors of simulated commands to Firefox's native one.
• "Customizability" * "simulate Firefox's native commands" = chaos.
• I don't want to lock people in TST. For past years - 20 years or about, I saw many bad practices about customizability. A highly customizable application locks users into itself, like Firefox 56 and older versions with legacy XUL addons. Even if the application became outdated and it became vulnerable, people cannot migrate themselves to an alternative. To be honest, in old days I was really tied down to Firefox 1.5 due to Firefox 1.5-specific addons and I couldn't migrate to Firefox 2 for some years. I can't repeat such a terrible thing.

[bughit]

@piroor

Any ui of TST, like the sidebar context menu, does not need to match Firefox. It's your ui. It just has to make sense and be useful/convenient for TST purposes, and putting close actions in yet a 3rd non-configurable location, is not helpful.

I don't want to lock people in TST

Lock-in happens due to unique and valuable functionality not minor menu differences. If users want side/tree tabs they're locked-in, the only way to combat such lock-in is to eliminate all useful functionality, such that going back to native won't be a big deal, so it's an absurd goal.

[piroor]

If my replies looks to be evasive, I apologize about my poor writing ability in English. I have some policies about this topic but I haven't wrote them as a concrete statement yet, so I'm trying to describe it incrementally with more example cases.

• I personally use TST's sidebar and Firefox's native tab bar together. In other words I don't hide the top tab bar with userChrome.css.
  • This is because there are some missing features (e.g. "Send Tab to Device") in TST's tab context menu due to restrictions of WebExtensions API.
  • Moreover, it is a safety net for my mistakes on TST development. Even if I break TST and the sidebar becomes unavailable, the top tab bar helps me.
  • On this usage style, I go back and forth between TST's sidebar and the top tab bar frequently. If TST's tab context menu and Firefox's native one are too different, it will be painful for me.
    • I don't want to study about two different menus providing similar (but different a little) features. I don't want to find a menu command in different positions on both menus every time.
    • So I decided to minimize difference of those two menus as possible as I can.
    • I need to pay many cost to maintain category 1 commands compatible to Firefox's native one, but this is reasonable for me to minimize such a pain.
• I'm afraid that I become hating the difference and I seclude myself into TST's sidebar world. It definitely lead me to lock-in desired to avoid.
• Due to these reasons I never use high customizability about category 1 commands.
  • This means that such a customizability is just a dead-weight for me. Such dead-weight codes definitely make it hard to maintain.
  • I continually remove dead (outdated, obsolete) codes to keep maintainability. Preventing to introduce codes unnatural for the project policy is a part of this kind efforts.
• Tree Style Tab project aims just to provide tree-like appearant tabs and natural enhancement for native tab features available on the top tab bar also.
  • Customizable context menu is not the prime target on this purpose, especially about commands simulating Firefox's native one.

[irvinm]

@piroor I think you have made your thoughts fairly clear. Any reason to leave this open at this point in time?

[piroor]

I've added a link from the FAQ to this issue. Now I think it's OK to close.