Tab wrap - clicking on tab can lead to selection due to jumping editors

[bersbersbers]

I have the following issue today with workbench.editor.wrapTabs: true on Version: 1.53.0-insider (user setup), Commit: a48ef56. When activating an editor group, additional icons may appear, changing the line wrapping of editor tabs, making the text jump, and leading to an involuntary selection of other text:

Originally posted by @bersbersbers in #70413 (comment)

[bpasero]

cc @sneakyfish5

[jmannanc]

Ok I've been able to reproduce this issue after messing with the screen size a bit, sorry for not catching it earlier. The jumping is caused by the extra icons in the editor actions being added after the editor group is selected. Those icons increase the margin-right of the last tab, and force it to a new row (which only happens on certain sizes of the window). So I understand the cause of the jumping, but not the reason for the selection of the extra lines. As trying to fix the jumping itself, I'm not sure how to do that, but I will look into it.

[bpasero]

I believe this is just a consequence of:

• mouse down to click into editor
• editor changes size
• mouse up is now at a different location in editor
• editor thinks this is a selection

Interestingly the layout happens async (on next animation frame), but I guess the mouse up is still happening afterwards. Maybe we need to further delay the layout or relayout in this case?

Note that the fact that editors jump is probably nothing we can fix easily because that is just how the wrapping tabs work.

[bpasero]

@bersbersbers to clarify, we will probably not be able to prevent editors from jumping, after all you enabled wrapping tabs in settings and different editors can have different number of actions.

A couple of thoughts to avoid this:

• you can configure workbench.editor.untitled.labelFormat: name to avoid long tabs for untitled files
• you can configure workbench.editor.tabSizing: shrink to get tabs shrinking up to a min width

Both things will help you.

The only issue I see here is the fact that the selection occurs, but otherwise I am not sure how to improve this.

[jmannanc]

The only issue I see here is the fact that the selection occurs, but otherwise I am not sure how to improve this.

This is the same conclusion I came to as well unfortunately. I'm also not familiar enough with how the selection works, so I don't know if I can help much there.

[bersbersbers]

@bersbersbers to clarify, we will probably not be able to prevent editors from jumping, after all you enabled wrapping tabs in settings and different editors can have different number of actions.

I'm not sure the issue is that different editors have different numbers of actions in my case [I do see how that could trigger it too, though] - the issue as it appears to me it that actions are hidden when an editor is un-focused. What if you did not hide them (that is, provide an option to make the actions stick upon changing editors)? This would prevent jumping upon focus change, and by the way, it would also calm the UI a bit which is very busy when I change focus - note how the actions are rendered in two steps. On the left side, a superset of the final actions is shown initially before some are removed while the right side, a subset of the final actions is shown before some more are added:

[bersbersbers]

The effect presented above (which appears consistently when changing from a diff editor to a regular editor in my setup, potentially, but not necessarily due to extensions) makes the original issue even more impactful as I just noticed: the editor jumps down and then up again as editor actions are added and then removed, if the larger set of action leads to wrapping and the final set does not.

I acknowledge that I caused this issue by enabling the option to wrap tabs, but if this is intended, then the option is simple not usable for me.

[bpasero]

Yeah I do like the idea of not hiding editor actions for inactive editor groups when tab wrapping is enabled, i am happy to accept a PR in this area.

[bpasero]

Actually this is not so trivial because currently we do not allow to click on editor actions for inactive groups, it would simply not work and rather target the other group that is active.

[bersbersbers]

Alright, next idea: what about adding an option to reserve space for a fixed number of editor actions in inactive editors, defaulting to zero if tab wrapping is off and some positive number if tab wrapping is on? This would not impact anyone not using tab wrapping; it would solve the jumping tabs for me; and each user can find their own middle-ground between "wasting" space and preventing tabs from jumping.

[bpasero]

Unfortunately I cannot find a good solution to this issue: the number of actions is very dynamic and some extensions may decide to only add actions when the editor becomes active, so we cannot reserve space for actions or always show them because some of them might only appear when you click into the editor.

The suggestions in #113818 (comment) improve this for anyone hitting this, so I suggest to workaround with those settings.

[bpasero]

After brief discussion with @alexdima we will investigate if this is something maybe the editor widget could provide as new API to indicate a layout change from a event like in this case.

[kbd]

I was going to open a new report, but this is exactly the issue I'm having:

The jumping is caused by the extra icons in the editor actions being added after the editor group is selected. Those icons increase the margin-right of the last tab, and force it to a new row (which only happens on certain sizes of the window).

Tabs will shrink if they can, but if they can't anymore they'll wrap to a new line, which moves the editor down as well. That's causing a selection, as the editor moves between mouse-down and mouse-up.

This has been happening frequently to me. It's much more likely to occur when you have your editor zoomed in (eg. for screen share), as tabs are bigger as well.

[ivanjonas]

Actually this is not so trivial because currently we do not allow to click on editor actions for inactive groups, it would simply not work and rather target the other group that is active.

I thought I had a solution, but it seems like it falls apart. Sharing here for the sake of conversation, in case I'm wrong.

Suppose we solve this jumping problem by showing the editor actions at all times, and disable them when the editor groups do not have focus. This is an existing pattern for some applications, so I feel that it would translate well here. One challenge might be that some tabs have more actions than others, so the problem would continue to exist (when switching tabs in the same editor group, rather than switching editor groups) unless the editor group always showed ALL available editor actions, even those that didn't apply for the current tab. I don't see how showing unavailable actions on the active editor could possibly fail to be confusing.

I found a different symptom the tab bar itself with the same "mouse down in one place, mouse up in another" root cause. Consider this example: there are five tabs in the unfocused editor group. When you mouse down on the fifth one, it triggers the overflow and causes the fifth tab to enter a new row, and also causes the fourth tab to occupy the space under the cursor. If you now drag before mouse up, you initiate a tab reordering on the fourth tab.

[bersbersbers]

Yes, the tab actions are causing all kinds of weird effects. Here's another two:

1. Note how tifftools.py moves left in one step when I activate the TeX file, but then moves right in two steps when I activate the right-most Python file.
2. Note how the x of the TeX file moves under my cursor when I activate the right-most Python file at it's right edge. Clicking there twice closes a file involuntarily.

Here's another one that I am not sure if it is related to the large number of tab actions:

3. I am resizing the window area horizontally in a continuous, monotonous fashion, and the whole thing is switching between breaking and non-breaking rapidly.

[bpasero]

@bersbersbers the last gif seems more like a bug to me, can you maybe file an individual issue on that with exact steps for me how to reproduce. Also, do you maybe have zooming enabled?

[bersbersbers]

@bersbersbers the last gif seems more like a bug to me, can you maybe file an individual issue on that with exact steps for me how to reproduce. Also, do you maybe have zooming enabled?

Yes, I am using "window.zoomLevel": -1. I will post a separate issue as soon as I can reproduce this. This is not easy, though: it's not enough to simply create 5 empty editors and splitting them horizontally. So it may be related to the editor actions.

[bpasero]

That issue with tabs stopping to wrap with zoom levels is fixed via #116385 and should be available in todays insider release.

[alexdima]

FYI @bpasero I just pushed a094513 which cancels the mouse down & drag operation when the editor height changes while dragging. I think this should cover this scenario without any adoption need from the workbench. Please try it out and let me know, I think that might fix the issue.

[bpasero]

❤️ 🥂 🍻

That is really cool thanks 👍