[Enhancement] Make switching to stickied tabs on click release instead

[matru]

Instead of on click. This will actually make it possible for stickied tabs to be repositioned instead of using them for only switching.

[piroor]

Sorry I couldn't understand what gesture is suggested... Would you describe it more, with different terms?

[matru]

Not sure if this is possible within firefox extensions, since I notice this behavior is universal to any tabs, stickied or not. But it's a concept in other applications (even Windows I believe) and video games, so I wondered.

But currently the tab switch occurs on mouse click (while it travels down), not on release (when the click travels up). So I can't press down, hold, drag the stickied tab where I want and drop it without instantly switching to the tab, so if I am scrolled away from it it scrolls towards, defeating the purpose of me wanting to drag a stickied tab.

A workaround is with ctrl-clicking close to where I want to drop it then dragging, but would like to know if the click behavior is modifiable in this case.

[piroor]

You imagined about a behavior like Window Snapping on Windows? https://www.youtube.com/watch?v=ZuDyNawz1e0

[matru]

No, not at all. Sorry for my bad explanation.

I am just talking about mouse click events. It can apply to keyboard events too. They are technically I believe separate events, mouse down, mouse up, key down, key up.

Imagine pressing a key on a keyboard, but the key does not register until the button is released instead of when it was pushed down.

So you press down K, nothing happens. But when you release K then the action happens.

This must've happen to you at some point, say in TST you want to close a tab, you click on the X to close it and then right as you click (before releasing the button) you realize that you don't want to close the tab (although ctrl + shift + t exists), then you drag your mouse out of the X and release, the tab won't close since the event was not executed while the mouse was on the X.

Here's some doucumentation: https://developer.mozilla.org/en-US/docs/Web/API/Element/mouseup_event

[piroor]

OK I might to get what you told. I misunderstood the meaning of the term "switching". I try to describe my understanding based on the issue template. (Please remind that the template is very helpful to describe what you want so I put it to the form by default.)

Steps to reproduce:

1. Start Firefox and install TST.
2. Open large number tabs enough to make the sidebar scrollable.
3. Right-click on the topmost tab and choose "Stick Tab to Edges".
4. Scroll down the sidebar to the bottom.
5. The stuck tab is shown as a floating element at the top of the sidebar.
6. Press down the left mouse button on the stuck tab, and try to drag-and-drop it to the bottom of the sidebar.

Expected result:

• When you press down the left mouse button, nothing happens.
• So you can start dragging the stuck tab without scrolling of the sidebar. You can drop the stuck tab to the bottom of the sidebar easily.
• When you release the left mouse button without dragging, the clicked tab is activated. The sidebar is scrolled to the original position of the stuck tab.

Actual result:

• When you press down the left mouse button, the tab is activated. The sidebar is scrolled to the original position of the stuck tab.
• So it is hard to drop the stuck tab to the bottom of the sidebar.

[matru]

@piroor I should definitely be using the template next time. As for the issue on hand, you are exactly right on all things, except that in the expected result, the sidebar should not be scrolled to the original position of the stickied tab when mouse button released, but focus should follow wherever it is dropped (so most likely no scrolling).

[piroor]

A helper addon Move unloaded tabs for Tree Style Tab may be partial solution. It changes TST's behavior that activating the tab by mouseup instead of mousedown.

[piroor]

Both behaviors "activating a tab by mousedown (not mouseup)" and "scrolling to the activated tab" refers the one of Firefox's native horizontal tab bar. Thus currently I'm negative to add a new option to introduce TST specific behavior different from Firefox itself, to reduce confusion of users (this is one of design policies of TST), especially cases that is available with helper addons.

[matru]

A helper addon Move unloaded tabs for Tree Style Tab may be partial solution. It changes TST's behavior that activating the tab by mouseup instead of mousedown.

perfect, I actually have used this addon in the past, but probably have forgotten the mechanism of action. Thank you!

[piroor]

I experimentally implemented some new APIs to TST to prevent scrolling to activated stuck tab, and introduced changes using the API by the helper addon TST Auto Sticky Tabs. https://github.com/piroor/tst-auto-sticky-tabs

(Note that both they addons supporting this feature is not released yet and you need to use development builds to try the feature.)

[matru]

Oh, nice! One suggestion, I would keep the default to scrolling towards the tabs, then it would be cool to add a function (as a sub option to the one you just implemented, but which I believe should be inverted), that function would allow you to switch to the original location if you for example double click on the tab. More details:

Leave the default be as it is now, so scrolling to original stickied tab location if the stickied tab is clicked.

Then have the following options:

• Prevent scrolling to the original location of the tab when a stickied tab is activated
  • Allow scrolling to the stickied tab only if it is pressed once again after already being clicked (no time limit, but can also be double clicked quickly to mimic default behavior).

Btw, the Move unloaded tabs addon works perfectly, and I have been utilizing it multiple times a day since I've started using it.

[piroor]

TST is already designed to scroll to the original location of a stuck tab when it is active and clicked again. You can confirm the behavior by clicking on the auto-stuck active tab with scrolled sidebar.

[matru]

@piroor I know, this is why I am saying it's the default behavior. But I thought you are changing that in the screenshot you've posted, since there is a checkbox to "Scroll to the original location"?

[piroor]

The new checkbox actually affects only for the scrolling when an inactive tab become active. Clicking on already active tab always produces scrolling.

[github-actions[bot]]

This issue has been closed due to no response within 14 days after labeled as "has-workaround", 7 days after last reopened, and 7 days after last commented.