Vscode: Mouse scroll wheel on tabs should switch tabs

[rightaway]

Just like in Chrome browser, if you put your mouse cursor over the tabs and then scroll, it changes between the tabs. Would be convenient if the same happened on the tabs in vscode.

[jhasse]

Currently, when there are more tabs so that a horizontal scrollbar appears, scrolling will control this scrollbar. Switching tabs would clash with that feature.

I think the behavior should stay as it is now, as otherwise one might very easily switch tabs by accident, if his mouse is over the tab bar (e. g. after switching tabs by clicking).

[rightaway]

Moving the set of visible tabs (the way it operates right now) is how Firefox handles their tabs, while moving between tabs is how Chrome handles their tabs.

I'd say that it's more useful to move between tabs since the majority of the time that your mouse is in the tab bar you want to switch to a tab that you can actually already see in the tab bar. And most of the time that you're switching tabs you're switching to one that was recently used, so it would already be in the visible portion of the tab bar (rather than out of scrollbar focus).

And if I do want to move to a tab that isn't in the visible portion of the tab bar, I would probably use another way to get there (because who even remembers which tabs are open when you're dealing with lots of tabs?), like a quick open dialog.

Because of vscode's preview mode, where it doesn't keep the tab open unless you want it to, so you'll have less tabs open in vscode than if you were using another editor, so it also makes it better to choose a default that is relevant to this case.

At the very least, it should be a configurable option what the scroll wheel does.

[jhasse]

And most of the time that you're switching tabs you're switching to one that was recently used, so it would already be in the visible portion of the tab bar (rather than out of scrollbar focus).

Why would that be the case? Tabs aren't ordered by LRU, so the tab you recently used might as well be outside of the visible portion.

At the very least, it should be a configurable option what the scroll wheel does.

Agreed. Also see #3130.

[clujin]

Would it be possible to expose the tab switch functionality through the menu? Like say for Mac OS, there should be a "Select Next/Previous Tab" option under "Window" and let the user bind it however they want to?

As it is right now, the VSC "Window" menu options are quite empty in Mac OS.

[rightaway]

Would it be possible to expose the tab switch functionality through the menu? Like say for Mac OS, there should be a "Select Next/Previous Tab" option under "Window" and let the user bind it however they want to?

Making it customizable like this would be ideal.

[ghost]

Even if the default behavior was set to switch tabs, it could switch tabs AND scroll all the way to the hidden tabs that need scrolling to get to. But as it is now the only way to switch tabs is by clicking on the exact tab as opposed to casually throwing the pointer on the top of the window and scrolling the wheel. I am doing literally hundreds of extra mouse clicks every day just to switch tabs.

[XeonG]

Number 1 requested feature for me this along with multiline tabbar

https://github.com/Microsoft/vscode/issues/54182

[eikawata]

FYI, on Sublime Text, you can hold right mouse button, and use the mouse wheel to switch tabs, which I find it pretty nice because I don't need to orient my mouse cursor in the top tiny area.

[parzh]

As for now, the proposed behavior does not seem to be intuitive to me.

[XeonG]

As for now, the proposed behavior does not seem to be intuitive to me.

Get a better mouse then, no cares if you don't find a optional improvement useful or not, fact is many others who aren't newbs will find it an improvement.

You know what I call incredibly un-intuitive... garbage ux and a tabbar that sucks....

...1. Does not even have a drop down icon on the far right side for all the document tabs that can no longer be displayed on the tabbar for quicker access in selecting.. because dolt design corp somehow think scrolling the tabbar is intuitive? no its rubbish and always has been unless you stuck using some touchpad rubbish where you can't use a mouse with a mousewheel. Using the mousewheel to select tabs has been the better way for well over a decade in any decent software that has implemented tabs...

And for reference a dropmenu icon on the end of the tabbar to show non visible tabbed documents has been implemented in VisualStudio, Firefox, Jetbrains, Eclipse and numerous other software packages that somehow managed to put a icon with a dropdown menu to show the document tabs that are no longer visible on the tabbbar... and to any derp that says just have the sidebar menu showing with OPEN EDITORS in view for a list view of tabs .. I REPEAT OPEN EDITORS in side bar view is the required.. because it's not like the sidebar is also used for showing addons, and many other views you might be in.. but ooh you've got to many tabs open and the tab document you want can't be seen, lets slowly use this shitty scrolling tabbar garbage ux, or switch sidebar to the Open Editors view so I can find the document tab I'm wanting, and then switch back to the sidebar view I was in before.. because someone overpaid so called professionals can't do there job properly and implement basics that don't suck.

Not to mention they waste more pixel width space than is really needed but offering that up for customization just hasn't happened), along with the tabbbar is used for showing countless things including settings because somehow making dialog windows for such things is so 90's with goolag, msuck flat crap design being peddled everywhere and and where everything needs to be a javascrap infested tab page.. but somehow they can't be seem to make a decent tabbar with the all the features and customization required for it.

1. how in the hell is it still 2018 and these basics haven't even been done yet?

https://github.com/Microsoft/vscode/issues/54182

[pdf]

@XeonG you might want to consider dropping the snarky and aggressive tone. And if you feel so strongly about this, why not contribute a patch?

[jhasse]

because dolt design corp somehow think scrolling the tabbar is intuitive?

It isn't only them: I also think it's intuitive. Switching tabs with the scroll wheel is what I would call unintuitive.

[pdf]

Switching tabs with the scroll wheel is what I would call unintuitive.

Works fantastically in Chrome and other apps, definitely miss it in VSCode and I wouldn't knock it unless you've tried it.

[jhasse]

Of course I have tried it, but I prefer scrolling the current view of the tabbar like in Firefox and VS Code.

[XeonG]

In the time it takes you to scroll the tabbar and click on the document you wanted, I could just have cycled to it with the mousewheel.

Not to mention with decent mousewheel support you can flick back/forth between documents for code comparison..

come on threads saying how great garbage ux is and anything better isn't better for them.. Of course it isn't better for you, you aren't even at the level of wanting faster workflow speed and a better interactive convenience to even be involved in the conversation frankly.

"tabbar like in Firefox" Firefox tabbar scrolling is garbage always has been, those mozillidiots only had a popular browser while XUL was around and that was what enabled awesome addons like tabmixplus and numerous other addons to actually work to improve the ux with countless features with options and customization for 'POWER USERS'.. and it's those very users who promoted the browser to and anyone with a half brain to want a better browser especially if they used the addons.

Right now Vivaldi.com (its built on chromium) craps over all Firefox quantum retardation and chrome .... ooh did I mention the tabbar in Vivaldi actually has most the features from tabmixplus built in... alt+mousewheel also makes for a nice popup list of documents(with thumbnail preview) to cycle through yeah how about doing the same in vscode, mozilla will never get around to that and thus I see the day there browser share gets even worse than what it was last reported at, they chose the path of catering to simpletons (without the marketing weight of over inflated stocks that goolag has to shove advertisements in people's faces promoting inferior products)

"And if you feel so strongly about this, why not contribute a patch?" because I have not the sparetime to waste looking at javascrap /typescrap (ugly assbackward language code).. if it was done in C# sure... sad thing is adding such shortcuts like mousewheel support I can't imagine being that hard at all for those who do work with the typescrap code of vscode. And neither would adding a drop menu icon at the end of the tabbar.

[parzh]

Speaking about the original issue, I don't find it intuitive because scrolling the mousewheel is an action that feels very lightweight (in UX terms), and therefore is expected to result in lightweight changes, while switching between the viewports is a heavy action (especially when they are fullscreen).
Problems might also arise when switching between multiple tabs very quickly with mousewheel. I expect huge performance drops in these scenarios.

[XeonG]

ooh jeez are you serious? just hold [ctrl]+[pgdown] or [ctrl]+[pgup] ..hold those keys down.. is your pc grinding to a halt in switching documents? then time upgrade from a potato pc... even a 15year old pc could handle that...

{
"key": "ctrl+pagedown",
"command": "workbench.action.nextEditor"
}
with ctrl+mousewheel down etc....

...with mousewheel tab switching.. so much better... and if the mouse cursor is over the tabbar and the user uses mousewheel that should switch tabs aswel... this stuff isn't rocket science and has been used in web browsers for almost 20years now.. unlike vscode developed by snails.

please get off this topic you are clearly don't even know wtf you are talking about.. using words like intuitive like that above reply.

[ChristianKurz]

I would also like to see the option to use this feature.
Most of the discussion in this thread wouldn't be needed if the feature would be a setting with the current behaviour as a default.

[XeonG]

Thanks RossBrunton, for fixing vscode usability issues.... maybe by 2020 they'll actually have it in a release.

[bpasero]

Sorry for being late on this issue: In Chrome I can see that you can scroll the tabs only when scrolling over the tabs and pressing the Shift key at the same time. I think we could allow the same in VSCode by default without having a setting for this.

Would that match what people expect?

@RossBrunton any chance you could simplify your PR at https://github.com/microsoft/vscode/pull/72030 to not introduce any setting and to work by default if the Shift key is pressed? I would aim the same kind of functionality as e.g. Chrome. where there is no wrapping around at the end of the tabs.

[ChristianKurz]

I personally would like to scroll tabs just by mouseover + scroll wheel.
A setting makes sense here - of course it could default to shift+wheel.
Non-wrapping would also be my preference.

[RossBrunton]

@bpasero I assume you are using Windows? On Linux, applications don't require the shift key to be held down.

In terms of making it optional, I'd rather keep all the options I've added, just because IMO there is no reason not to have options and in this thread it's clear that everyone has their own opinions on how the feature should work. :P

[bpasero]

@RossBrunton I am using stock Ubuntu 18 with stock Chrome, nothing fancy installed. And I need to press Shift to scroll tabs. I am using Windows, Linux and macOS since around 10 years side by side and only yesterday did I learn that Shift+scroll would change tabs (in other words - I never accidentally switched tabs while scrolling by accident). So I am quite sure that the default is to not scroll without modifier keys pressed. If someone can point me to UX guidelines for platforms where it is written otherwise, please share.

Re options: I would like to pick a good default before adding more options to our set of 300 options we have already. But I can do this change, no need to update the PR (please close it then).

PS: on macOS the native tabs do not change when I scroll, at least not with Shift pressed:

[RossBrunton]

Okay, something strange is going on then. On my Mint system scroll wheel does change the tab (without modifier) in Chrome. I wonder if it's some configuration somewhere that I've got turned on? It's not even a Chrome vs Chromium thing, since I just installed Chrome and I don't need the modifier.

Could some other Linux users chime in?

Other applications that (on my system at least) support scroll wheel (without modifier) to switch tabs:

• Atom (Wraps around)
• Cinnamon Window List (Supports optionally reversing the direction of scroll, and wraps around)
• Cinnamon Workspace List (Wraps around)
• Gnome Terminal (Doesn't support wrapping around)
• Foxit Reader (a PDF reader) (Doesn't support wrapping around)
  Firefox also recently added the feature, and it doesn't require holding shift there, but I don't have that version on my system.

[pdf]

No modifier is required on Linux here either, not sure why it is for @bpasero .

[bpasero]

Fair enough, I am fine just having one setting to enable this and then work without modifier (disabled by default though).

[rightaway]

@bpasero That PR has a few different settings. If you plan to include only one setting then what defaults are you planning to have for the other options provided there (reverse, wrap and forced)?

Is it really so bad to include more settings even if there are already 300? An IDE's usefulness is its customizability. How you like to work may not be how others like to work.

[bpasero]

I would start with 1 setting for now to enable it and behave in a sensible way.

[rightaway]

in a sensible way

What does "sensible" mean to you? If you don't want to offer settings then at least say what defaults you're planning so that people can comment on it before it's done.

[RossBrunton]

One thing I have noticed is that in Windows, the shift + Scroll thing actually goes the opposite way compared to Linux. What way are you going to implement? Scroll up = left (as in Linux), or right (as in Chrome)?

[RossBrunton]

For anyone still waiting on this and willing to build their own version, I've been keeping my version of this feature somewhat up to date at https://github.com/RossBrunton/vscode .

[rightaway]

@bpasero You should detect whether it's on windows or linux and scroll the same way as the system does (as @RossBrunton said).

And as was mentioned earlier you should say what "sensible" defaults mean to you if you don't want to include more than one setting, so people can at least comment.

[RossBrunton]

Or just let the user choose what they want. It's almost comical how much of this thread is people asking for it to be configurable or asking for what they want, and then Microsoft ignoring that and trying to figure out what the best way to force upon everyone is.

We're big boy programmers we can handle and expect our IDE to be configurable.

[rightaway]

Less Microsoft ignoring the various points in this thread and more @bpasero. If only someone else could be assigned to this issue who actually cares what the users are clearly asking for, and @bpasero could instead work on issues he actually has any level of interest in, it would benefit everybody.

[irvnriir]

just please do not make this a mandatory change, only optional/settable (for large tab counts and medium-performance laptops it would be bad) .

[XeonG]

🤦‍♂ how in the hell is this still not implemented? Seriously @bpasero

[bpasero]

Here is my current thinking: introduce a new setting workbench.editor.scrollToSwitchTabs with:

• off: disables this to preserve today's behaviour (this is the default)
• natural: switch to tabs in natural scrolling order
• reverse: switch to tabs in reverse scrolling order

On top of that, I would always allow to Shift-scroll to get the one or the other behaviour (aka switch tabs when this setting is off and just scroll otherwise). We already seem to be supporting Shift-scroll in the editor to scroll horizontally, so this seems like a good way for alternate behaviour.

In this model, there is no difference if the tab-stripe is overflowing. You just continue to switch to tabs when scrolling to the right. There is also no wrapping currently.

I am not 100% sure about the setting name and options yet, but I like that it is just 1 to begin with.

[bpasero]

Will be in tomorrows insider build to try out.

[bpasero]

Decided to change the setting to be a simple boolean and not control the direction of switching. Extracted https://github.com/microsoft/vscode/issues/96544 for that particular feature as it should also impact the scrollbar scrolling, not just the switching behaviour.

To enable this feature you need to change your existing setting to:

"workbench.editor.scrollToSwitchTabs": true

starting with tomorrows insider build.

[rightaway]

@bpasero For default scroll direction, when you scroll up does it move to the left? That's the default in most applications.

[bpasero]

@rightaway yes, the default is to switch to tab on the left for scrolling up and right for down.