Keep scroll position stable when closing a tab in the tab well

[PunchyRascal]

• VSCode Version: Code 1.5.3 (5be4091, 2016-09-22T08:50:42.185Z)
• OS Version: Windows_NT ia32 10.0.14393

Steps to Reproduce:

1. open many files so that tabs are scrollable, have the first (left-most) tab active
2. scroll to the farthest (right-most) tabs
3. close a tab in that area
4. the whole tab bar scrolls back to the left-most position (active tab)

This leads to loss of focus and confusion. If I want to close multiple tabs there, I have to scroll to them each time I close one.

[bpasero]

@PunchyRascal share a video? I think this behaviour is intentional if the first tab was active before opening the last one (we go back in MRU order and open it).

[PunchyRascal]

I see no reason to generate focus to active tab since the tab never lost the focus, it is still open, I am just trying to close a few tabs at the end of the tab bar, I am not activating other tabs or closing active tab.

I edited the initial report for better clarity.

[bpasero]

@PunchyRascal oh yeah I see it, uncooool

[bpasero]

I am undecided how to best fix this because it might also cause in users reporting issues why the current tab is not revealed. I think eventually maybe it needs to boil down to a setting which sucks too.

Maybe a delay could be added that after a close we only reveal the active tab after some timeout so that you can continue closing tabs without loosing context.

Anyway, I would accept a PR in this area if someone wants to jump in 👍

[PunchyRascal]

But the active tab is still there, you are looking at it (its editor), while deciding to scroll only the tab bar to the right, on your own. Why should the editor force you to jump back each time you want to do something in that area? E.g. Netbeans don't do this.

The timeout idea seems even more confusing than the current situation.

The active tab could be re-revealed (if you think this behaviour is necessary, I don't) when you focus the editor again (since the active tab is still open there).

The question is, what are the benefits of the current implementation?

[bpasero]

I hear you. Thus this is a fair and valid feature request 👍 . I agree that a timeout makes it worse.

[PunchyRascal]

I would actually argue that this is a bug, it totally confuses you when you want to close a few tabs, and you're taken away for no reason.

[bpasero]

@PunchyRascal One of our explicit tab design decisions was to never show an editor without its context (aka without the tab it belongs to) as demonstrated here:

I see the issue with rapidly closing multiple tabs that are not active, but I think once you leave the tabs area, the active one should get revealed.

I think #18965 is going a bit too much into the wrong direction. Can we not just track where the mouse is by listening to mouse enter / mouse exit on the tab and if we have to make the decision to reveal the active tab or not we just don't do it when the mouse is over a tab? On top of that I think we should then go ahead and reveal the tab when the mouse exists the tab area.

Does that make sense? Seems like a much simpler and better fix to me.

[PunchyRascal]

Tracking mouse movement and restricting this fix to when user does not leave the tab area seems confusing to me.

I can only reiterate my previous solution in comment #13001 (comment) - which I think addresses all the issues (no auto scrolling in tab bar on tab close, re-reveal of current file on editor focus).

[bpasero]

@PunchyRascal but the editor is never loosing focus when you close an inactive tab. Do you mean to reveal again when the user clicks back into the editor?

[PunchyRascal]

Well I just tried and I think it does lose the focus - but that of course depends on the definition of "losing focus" :) When I close any tab at all via mouse middle click and start typing, the open editor does not receive the keystrokes, so in a sense I would consider it not in focus.

[bpasero]

@PunchyRascal that would be a severe bug, can you share a video? Here is how it works for me:

(I am pressing the mouse middle click here to close)

[initialshl]

It seems that the focus is lost when you close inactive tabs (using middle click or right-click menu), and closing your active tab activates the previous editor, hence the focus gained.

[PunchyRascal]

It is difficult to demonstrate that the editor does not receive the keystrokes, but after closing the tab, I kept typing, but nothing happened.

[bpasero]

Oh yeah I can reproduce (only when closing an inactive tab), that should be something to fix...

[bpasero]

Ok, let's see how it goes, I pushed a fix that ended up to be a larger refactoring (also for #22292) that is why I did not merge your PR.

Let me know how it goes. The idea is that invoking close from within the tab container will not cause the active tab to be revealed (using the same flag to block revealing once).

[PunchyRascal]

Just tried it, it's amazing, thanks :)

[bpasero]

Cool. The only thing I am not doing, which maybe users might complain is that when focus moves back into the editor (if it was outside e.g. in the explorer), we do not reveal the active tab. But that is actually also the behaviour today.

[isidorn]

Adding verified by user