Bug: Multiselected tabs are closed on mouseup if you hold Shift, click & hold a tab's close button, release Shift, then release click
Status: NEW
Priority: --
Created: 2022-07-03 20:43:16+00:00
Resolved: 2022-07-18 12:07:46+00:00

There's a kind of obscure set of steps that will cause some unintuitive behavior while multiselecting tabs.

If you hold down the Shift key and click a tab, it will multiselect the range of tabs between the selected tab and the clicked tab, on mousedown, regardless whether you clicked the tab or one of the buttons inside the tab. But the way this is done is by checking the accel/shift key state of the event. It's possible for that key state to change in the time between mousedown and mouseup (and click) events.

This can result in the following odd behavior:

1. Make a bunch of tabs
2. Hold down the Shift key
3. Click the close button in a tab other than the selected tab, holding down the left mouse button
4. You can see the range of tabs become multiselected on mousedown because of the blue borders on the tabs
5. With the left mouse button held down, release the Shift key
6. Release the left mouse button (it should still be on the tab close button)
7. All the tabs in the range that was multiselected during this operation are closed

Of course this is an unusual series of steps but we're doing it very deliberately here. It's possible for that to happen accidentally (which is how I noticed it). I don't know about others, but it seems like when I modifier+click, I _usually_ hold down modifier keys throughout the process. I certainly don't consciously release them prior to mouseup. But it seems like releasing the modifier keys and releasing the left mouse button are so near to each other in time that it's possible to release the modifier key(s) first. And even if that only precedes mouseup by a single event loop, that's enough to trigger this problem.

So I would propose that a "modified" mousedown event that causes multiselection should suppress the normal handling of mouseup events. In other words, once we've caused multiple tabs to be selected, we should try to suppress the subsequent mouseup/click events.

But care needs to be taken in dealing with dragstart because it's possible to hold Shift, click to multiselect while holding the LMB down, and immediately start dragging the just-multiselected set of tabs. But only if multiselection was not triggered by clicking one of the secondary buttons. If we Shift+click one of the buttons, it will multiselect the tab range, but dragging will have no effect. Whereas if we clicked in the neutral area of the tab while holding Shift, we can hold and drag the tab range immediately.

So to avoid foreclosing that feature by fixing this oddity, it would probably make sense to only suppress mouseup/click events if _their_ target is a secondary button, regardless whether the original mousedown event target was a secondary button. That sounds kinda wonky, but as described above, we already differentiate between dragging on the neutral area and dragging on secondary buttons. And aside from dragging and the ordinary secondary button click handlers, there aren't any other mouse behaviors implicated here.