Looks like VS Code is listening to mouse scroll events, even while it is not active in the window.
Related:
https://bugs.chromium.org/p/chromium/issues/detail?id=608246
https://bugs.chromium.org/p/chromium/issues/detail?id=807187
Steps to Reproduce
requirements: Browser (Chromium / Firefox / Google Chrome), VSCode Editor (Any file type. Ideally a long file to ensure the scroll is visible.)
VSCode: Leave cursor at top of file.
Browser: Scroll, excessively, (For a few seconds) down the page. Even if it's a blank tab with no content.
VSCode: Scroll, ever so slightly, in any direction.
You'll find the editor will jump suddenly further down the active file.
It seems VSCode is receiving the scroll events, for whatever reason; which are all suddenly evaluated upon any form of scroll input in the editor.
Updates based on comments
GUESS: Appears to be an issue with Electron and some input libraries?
Is not isolated to VScode
Fix: Does not yet exist.
Linux Workarounds (Not to be confused with a fix)
imwheel - not suitable for all users
wayland - not suitable for all users
Note: Ubuntu 19.04 (Desktop) appears to be using Wayland.
I'm not sure we will see further updates in here, which is a bit disappointing from the developers, given the amount of comments from affected people. I would like to have some official guidance, even if it's pointing us to other resources.
|||
| ------------- | ------------- |
| OS | Ubuntu 16.04 |
| VSCode Version | 1.13.1 |
I'm getting a similar issue when Alt+Tabbing between windows.
E.g., Alt+Tab
to Chrome to read docs, etc., Alt+Tab
back to VSCode, scroll up _or_ down one click on the mousewheel, but the page scrolls down at least 3-4 pages pretty consistently.
UPDATE: Issue still present with all extensions disabled.
This also happens with the right sidebar (Explorer) sometimes, when Alt+Tabbing between windows.
Version: 1.14.2
I've been experiencing this issue for a rather long time. I've never really put much thought into it, and it's not got worse; but I'm starting to really find this ever more frustrating. The actual impact to my productivity is beyond measure.
I'll find that this happens intermittently, but frequently - in which I'll attempt to scroll in the current file, and suddenly I'm scrolled to a location way out of bounds to the input. (Eg; I'm attempting to scroll a few lines, and suddenly I'm at the end of the file).
Some key thoughts may be;
I've deliberately left the version of Debian (Buster), and VSCode out of this note. I'm using latest of both, however this has most certainly been present for a long time.
I'll endeavor to provide further constructive input in attempts to discover where the problem lies, and attempt to pay more attention when it happens. @ramya-rao-a & @rebornix - I would expect this impacts a lot more users than reported here, hence tagging you here. Just a matter of how long before they too come to this level of frustration.
Edited; included additional information, tagged some people, and fixed some content.
Same here, just couldn't find a way to reproduce it reliably. It is painful indeed.
I don't use multiple workspaces, just alt tabbing between windows (also CTRL + P quick switching between files, but that doesn't seem to affect this). I use just mouse scroll, no touchpad.
This is bugging me for quite some time, and I think I can reproduce it. It only happens (to me at least) if there is the mini search box at the top right corner of the editor. If I dismiss it, the scrolling disappears.
EDIT: I'm on Windows & OSX.
@tmtke So you have definitely had this happen on Windows?
@dmblack Yes, it happened on Windows.
...damn, I think it's not that consistent. maybe a combination of the search box and the inline reference lines. I don't know nothing now :/
I can confirm this behavior for Ubuntu 16.04, VC 1.18.1 if I switch between Chromium or Firefox back to VS Code. If switch back from Nautilus or Thunderbird for examples, everything works fine.
I also experience this on Fedora 27
vscode Version 1.18.1
I can finally, and consistently, reproduce. I can also confirm this not only impacts browsers like Chromium, Firefox, and Google Chrome, but other open applications. I can even have no applications open, only my Desktop visible, and reproduce.
For this example, simplified to ensure reliability; requirements: Browser (Chromium / Firefox / Google Chrome), VSCode Editor (Any file type. Ideally a long file to ensure the scroll is visible.)
You'll find the editor will jump suddenly further down the active file.
It seems VSCode is receiving the scroll events, for whatever reason; which are all suddenly evaluated upon any form of scroll input in the editor.
@tmtke @mariusa Tagging you two, if you are able to please attempt to reproduce.
Something tells me this is actually an Electron bug. Unfortunately; I don't have any other Electron apps to test with.
Edit: I now have a Windows 10 box at home. Will endeavor to test and add results tonight.
I was also able to reproduce this issue with Ubuntu 16.04. It doesn't matter what app I switch to (tested with Chromium, gedit) although I wasn't able to reproduce by scrolling on an empty desktop. I am not experiencing this with Windows 7. I do not believe that it has anything to do with find or extensions, because when I boot code with --disable-extensions and don't use the find feature, the issue still occurs consistently.
Edit: I don't mean to imply that something is related without better testing, but the Electron/Atom team has a very similar issue that was reported to Atom: https://github.com/atom/atom/issues/15482 The description is nearly identical. There are some suggestions there about switching to Wayland, using editor in a different workspace, etc. I was able to confirm that putting VSCode in another workspace stopped the issue from happening. This looks like at least in my case it's not a VSCode-specific issue at the moment.
As @dmblack surmises, it appears that this is an Electron bug. A related Atom issue has provided steps to reproduce the issue. It seems that Electron is receiving scroll events of Chromium applications that are on top of the Electron application and then replaying them after a scroll event on the Electron application.
Updating Electron seems to fix the issue though, so it's up to the vscode team to fix.
@rebornix May we have your input (Tagging as it's assigned to yourself). Looks like this may be out of our hands otherwise.
Thanks all others involved so far!
I'm having this issue. It's painful. VSCode is listening to mouse scroll event even while it is not active in the window.
I came to learn that this is a bug from Chromium project and so affecting VScode for being based on electron which use Chrome engine under the hood.
I just filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=807187
Not sure if they are taking this seriously.
I wonder if this really is an Electron bug. The Atom editor does not have this issue, and the current Atom version (1.23.3 ) is using a much older version of Electron:
ares: "1.10.1-DEV"
atom-shell: "1.6.15"
chrome: "56.0.2924.87"
electron: "1.6.15"
http_parser: "2.7.0"
modules: "53"
node: "7.4.0"
openssl: "1.0.2j"
uv: "1.10.1"
v8 : "5.6.326.50"
zlib: "1.2.8"
````
vs code 1.19.3 :
ares: "1.10.1-DEV"
atom-shell: "1.7.9"
chrome: "58.0.3029.110"
electron: "1.7.9"
http_parser: "2.7.0"
microsoft-build: "1.7.9"
modules: "54"
node: "7.9.0"
openssl: "1.0.2k"
uv: "1.11.0"
v8: "5.8.283.38"
zlib: "1.2.11"
```
If this is an issue in Electron, I suspect much more users would be impacted.
Is there a common extension or tool that triggers this behavior ?
It still happens to me when running vs code with: code --disable-extensions
but not when running vscode and chrome on a clean install, without any extensions installed.
I also use PlatformIO and wakatime as extenions, perhaps I should try to install my extensions one by one and see when the issue starts popping up.
Anyway, this is becoming such a productivity drag that I don't see another option short of switching editors. If anyone has found a workaround, please share.
update:
The issue is somehow related to libinput. As a workaround, you can replace the libinput with evdev, in ubuntu with xorg it's:
"sudo apt remove xserver-xorg-input-libinput && sudo apt install xserver-xorg-input-evdev". But probably you will need to manually configure the mouse.
@arenddeboer
There's a link earlier in this thread in which Atom demonstrates same, or similar, symptoms - posted by @vacantgeologist and @tranhl
Regarding your 'scroll up' first notes; In my experience; the editor will scroll up or down, entirely depending on your behavior in other applications. As per my testing; I found that this was happening in any application, or even just my desktop - not just other 'Electron' applications.
Regarding a workaround; there are some notes, kindly clarified by @Fullpan. I have not tested them, however; I'd be interested in your experience/result if you give this a go. Please pay close attention to their note regarding potential manual configuration of your mouse.
@mariusa
Could you please update the description / original information to include some additional information found by other users here. This will avoid other posts by users that may miss or misunderstand other content of this now much longer thread.
I'd encourage information or status updates by some of the appropriate developer stakeholders, but we do not seem to have much traction from them.
@dmblack done
@ramya-rao-a Would you please assign to a more responsive developer?
@dmblack thanks for the feedback.
@Fullpan thank you for the libinput / xorg reference.
It made me realize I had WaylandEnable=false
set in /etc/gdm/custom.conf. Switching back to Wayland solved the issue for me.
The same here in manjaro gnome when I scroll in chrome and then I press alt+tab to vs code, the scroll put me the end.
DISTRIB_RELEASE=17.1.2
kernel version 4.9.77-1-MANJARO
version vs code 1.19.3
version libinput 1.9.4-1
This happens consistently when using synergy. It's very annoying. Relevant issue: https://github.com/symless/synergy-core/issues/6038
If you're using Ubuntu 17.10 with latest GNOME desktop environment you'll notice this bug too. I tried to install old Ubuntu DE "Unity" and use VSCode on it and I didn't noticed this bug. Everything worked as expected without any errors.
Linux 4.13, X11 with GNOME (not Wayland session)
Another victim of that bug here too, however I have been using zen mode and I'm getting a lower chance of that happening to me, also restarting chrome and VsCode seems in my case to help to "disconnect" the apps scroll events.
System is manjaro KDE plasma 5
This keeps happening to me too. Ubuntu Gnome 16.04. When I scroll in any application and then switch to either vscode or chrome it scrolls relative to whatever I scrolled in the other application. This is obviously very distracting. Anyone having any luck with the workarounds?
Super annoying problem. I'm now getting this problem in Antergos with GNOME.
I've had to put my main opened apps into their own separate workspaces and have a keyboard binding to flip between those.
Does anyone gets this error on zen mode? I'm been using it all the time and I had been 4 days without the issue, I don't know if this may be relevant but guess it couldn't hurt to look into it.
FWIW, I can reproduce this issue in Chrome, VSCode and Atom (using Fedora). But only under X11.
I've experienced this for a while too. If I'm in another application for a while then switch back to vscode, the slightest tough on the touchpad or mouse wheel causes the editor to jump to a new position. I'm on Debian 9.
I can confirm this issue happening on Ubuntu 17.10 on kernel version 4.15.8-041508-generic as well.
I can confirm that this is still occurring for me on Ubuntu 18.04 LTS, VS Code Insiders:
Version 1.24.0-insider
Commit 2404210629c744e6237a14d7b5fa852e24c6e898
(X11)
Damn, it's very annoying bug, switching to browser, scroll something there, then back in VS, one scroll and voila! I'm at the bottom of my file.
Ubuntu 17.10
this annoying issue is occurring on ubuntu 18.04 LTS, and when i switch to wayland or use alt+f2 and r
to reload gnome, it seems working good again. Maybe it's a workaround for you.
This needs to be fixed. It's annoying as hell.
@sevenryze It definitely does not apply to Wayland. I'd totally jump ship to Wayland but I get poor performance, odd multi-monitor behaviour and non-existent NVIDIA driver support (for now!).
However, restarting GNOME most definitely does not have an effect.
I wonder; for anyone that is using VSCode (or Atom, or any Chromium/Electron based application) and _not_ suffering from this bug; what desktop environment are you using?
As an aside, I believe using evdev instead of libinput (on X11) also avoids this issue.
I am using Ubuntu 16.04 with Gnome. None other electron app has this issue.
Confirming on Debian 9 / Mate.
Lubuntu 18.04 user here - I also have some weird scroll behaviour on chrome based apps - slack, vscode, chrome itself. I do not get random scrolls, but rather those apps skip some scroll events. The funny thing here is that LXTerminal is also skipping scroll events. Firefox for example is working totally fine.. it is really annoying. Btw this mix of apps point to direction of the underlying infrastructure - on lubuntu 16.04 i did not had any issues, but after upgrade to 18.04 all hell broke loose..
Same here on Xubuntu 18.04.
But!
Can reproduce only if I switch between VS Code and another window with alt+tab combination, if I switch via click on window on taskbar scroll doesn't jump.
40 comments since June 2017 and still no solution? As a consequence I need to change my IDE.
@rebornix I'm not having the issue anymore since using zen mode, but is there a possibility to add this as a milestone or higher priority for next releases?
VSCode it's all great but this bug it's just too darn annoying, I understand there are a lot of issues and road maps are settled to take on improvements and bugs the best you guys can, and I'm petty happy overall on how you guys iterate on the editor, however I really think that this issue is not being given the needed importance as its a visual glitch that happens to break and seriously disturb the developers workflow.
This makes VSCode basically unusable because you cannot switch windows via alt+tab and that's a basic root functionality of the app.
@Esteban-Rocha I can reproduce bug in Zen Mode.
Please stop spamming this bug. VSCode is open source, if you want it fixed, fix it!
There is no value in adding comments demanding a fix from someone else.
@smehrbrodt We are creating awareness.
@smehrbrodt It's not spamming dude, you should first understand how OSS works and specifically how VS Code team works.
@fotonmoton Ohh that sucks :( ! I may be lucky then, if that's the case this means the issue it's even worst as there is no hack around it
As an aside, I can confirm that Atom has resolved this issue for my setup since updating to Electron 2.0.0 (https://github.com/atom/atom/pull/17273). So, noting the work in https://github.com/Microsoft/vscode/issues/45542 I thought this may have also resolved this issue.
However I've tested for this bug on the exploratory builds from that issue and unfortunately it still appears to suffer from it.
edit:
Scratch that, I was not testing Atom layered underneath another window; I was able to replicate it in Electron 2.0.0 powered Atom.
My observation. The issue still exists with the google chrome so, it's hopeless to see it being fixed anytime soon in VS code.
Okay.. from what I found out so far it looks like it has something to do with input coming from different virtual input devices. Installing and running imwheel
without any additional configuration fixes the issue for all affected applications.
@dr0p
It's probably important to mark this as a workaround, and not a fix.
Appreciate your feedback. I'll be looking at implementing a functional workaround until this is addressed by the appropriate resources.
This happens to me when I'm on Ubuntu 18 LTS. Really annoying and effects my productivity.
UPDATE: :angry:
Came here after noticing the same, standard Ubuntu 18.04 installation (fresh), VSCode installed from the Ubuntu Software "store". I have the same behaviour if I scroll up and down in VSCode and then switch to Chrome (e.g. this long page) and scroll I get a jump. I also have the same issue with the Slack app which is built on top of Electron I believe, but only when using Alt-Tab - clicking on the dock or the application (if visible) seems to not cause this behaviour.
VSCode version info:
Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
Can confirm that installing and running imwheel
is a workaround, just have to remember to start imwheel
after installing it. Sadly though I notice that running imwheel
in its default configuration seems to stop Ctrl-Mousewheel from working as zoom control.
To all the linux falks here, there is very easy hack. you can install imwheel and it will fix this issue. I have been using this hack for a while now and haven't noticed any issues. if you are on ubuntu its as easy as sudo apt install imwheel
and then add that into your system startup programs by opening startup applications gui and adding program/usr/bin/imwheel
.
Hi there...
I'm using Debian 9 with Mate desktop. From https://forums.linuxmint.com/viewtopic.php?t=241431, as a workaround, disable smooth scrolling from Chrome. Works for me...
I've been having the same issue since Ubuntu 16.04 LTS with unity, had it on Ubuntu 17.10 with gnome and now on 18.04 LTS with gnome. It's happening also with Sublime Text 3, and some other programs. I am using mostly the trackpad 2 finger scrolling, tho I am fairly certain it happens with a mouse as well.
I just installed and run imwheel
as per @hardikdangar suggestion, and first results are positive.
It does suggest that the behavior is not related to vscode directly, but rather something to do with the way the X stuff interprets the mouse or something.
FYI guys, there's a 'Subscribe' button. It doesn't serve much of a purpose to say 'Happening to me too' in comment unless you have more input to add to the problem. Please don't take offense to this. I just know it bothers folks who actually write code for open source projects when they get spammed for no reason.
I am using Mate on Antergos distro and am observing this problem. I am always running chrome and vscode on seperate workspaces.The imwheel doesnt work nice for touchpads with precision scrolling, so that is not an acceptable workaround for me.
I have worked around my problem by using xdotool for workspace switching, by overriding default shortcuts.
I do it this way:
Move to workspace to the left:
xdotool set_desktop --relative -- -1
Move to workspace to the right:
xdotool set_desktop --relative -- 1
Hope it helps until this issue is resolved...
imwheel cause a horrible scroll behavior.
I know this is a frustrating bug for many users to deal with (myself included), but let's try not to take that out on the vscode devs. From my understanding this is a bug in chromium, and therefore is making itself known in Electron as well. The vscode devs do amazing work but it could be argued this is out of the scope of their responsibilities. If we want a fix faster the linux community needs to get involved, as the chromium team is actively asking for our help here. Not trying to offend I just really appreciate the vscode teams hard work
same problem here. vscode interacts badly with chrome.
In my case my cursor always jumps towards the top of the page. It's very annoying because it distracts you from reading and can leads to losing focus. Is it related to the same issue?
Ubuntu 18.04, Chrome Version 70.0.3538.67 (Official Build) (64-bit)
Oh no I managed to trigger it with electron 3 on ubuntu 18.04.1. I don't know how but it definitely happens less often in exploration.
Version: 1.29.0-exploration
Commit: 8fc99c65d2f01e7b413cde2d3bf7785356778381
Date: 2018-10-30T11:31:30.266Z
Electron: 3.0.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
Architecture: x64
I've done a tiny bit of testing with different desktop environments, and I found that this bug occurs while using Gnome and XFCE4, but not in LXQT or KDE Plasma. Not sure if this is an isolated case, but at least for now, to me, it seems like GTK-based desktop environments are suffering from this bug, while QT-based desktop environments don't.
Can people having this issue vote on the chromium bug? This one is still open: https://bugs.chromium.org/p/chromium/issues/detail?id=807187
I've done a tiny bit of testing with different desktop environments, and I found that this bug occurs while using Gnome and XFCE4, but not in LXQT or KDE Plasma. Not sure if this is an isolated case, but at least for now, to me, it seems like GTK-based desktop environments are suffering from this bug, while QT-based desktop environments don't.
Thanks for mentioning this. Today I have installed KDE plasma and this bug no longer exists in my new environment.
Scrolling, in general, is a lot smoother as well in KDE.
in ubuntu 18.04 and latest vscode, after alt+tab to opera, alt+tab to vscode editor scrolls down to bottom or top document.
update: imwheel cause a horrible scroll behavior.
Hello Guys, Does anyone knows how to fix this issue? or any workaround until VS Code fixes it?
I switched to firefox, with IE going chromium it’s the best thing for the web as well. 😊
Other than that though, no real workaround so far, and I tried a lot of things. The ‘imwheel’ tool mentioned above works, but it causes more problems than it solves.
@Epskampie Should be noted here of course, that swapping to Firefox doesn't help! The window you scroll on before swapping back to VS Code (or Atom etc.) _does not need to be Chromium based._
I can reliably replicate this with Firefox + VS Code (my daily driver browser) just as well as with Chrome + VS Code.
I can even, in fact, replicate this with Firefox + Chrome, by:
You will not observe the opposite, though; Firefox doesn't suffer from the issue itself, just Chromium (Chrome, Atom, VS Code).
Of course this isn't that big of an issue for two browsers. It is definitely an issue for a code editor like VS Code or Atom, where you will commonly be swapping to a web browser (Firefox, or Chrome) and perform plenty of scrolling. Eventually you will swap back to your editor, scroll even a single line and skip to the end of your file!
Definitely hurts the experience.
Antergos with gnome happens too. Code to chrome and vice-versa, happens. Chrome to sublime, dont.
[UPDATE] imwheel fix it.
The root cause is this: https://bugs.chromium.org/p/chromium/issues/detail?id=608246
OMG I thought there's something wrong with my mouse but I can reproduce what is posted here https://github.com/Microsoft/vscode/issues/28795#issuecomment-350631888
@yuritoledo could you describe how imwheel fix it plz? what parameters or so. thnx
@aleksanderd you should install imwheel
and put it to start with your system. Simple like that :D
If you have a mouse with more buttons than the traditional, you can use imwheel -b 45
I get the same scrolling issue with vscode and chrome on xubuntu 18.04.
I've just tried the imwheel workaround, as suggested above, and the scrolling is no longer influenced by other applications. However now when I scroll very slowly in VSCode the scrolling is not smooth at all, it moves in small steps.
I am using Mate on Antergos distro and am observing this problem. I am always running chrome and vscode on seperate workspaces.The imwheel doesnt work nice for touchpads with precision scrolling, so that is not an acceptable workaround for me.
I have worked around my problem by using xdotool for workspace switching, by overriding default shortcuts.I do it this way:
Move to workspace to the left:
xdotool set_desktop --relative -- -1Move to workspace to the right:
xdotool set_desktop --relative -- 1Hope it helps until this issue is resolved...
for precision touchpads try this after installing imwheel
create config file for imwheel
gedit ~/.imwheelrc
then paste:
None, Up, Button4, -1
None, Down, Button5, -1
Control_L, Up, Control_L|Button4
Control_L, Down, Control_L|Button5
Shift_L, Up, Shift_L|Button4
Shift_L, Down, Shift_L|Button5
now, if you use a precision touchpad, keep the two -1 values.
if you are using a mouse, change them both to 1.
seems to be a workaround for one of the the options - mouse or touchpad.
@geoffroy-noel-ddh
Try to add this guy in your vscode settings: "editor.smoothScrolling": true,
@yuritoledo Actually it didn't work.
@pwaterz about what problem?
Same issue. If chrome is active, then alt tab to vscode then scroll, it jumps to the bottom or top. It's a pretty annoying bug. From what I gathered the issue is in libinput that gnome requires or possibly in the version of electron the vs code uses. I read that atom ide fixed the same issue by updating electron.
@pwaterz I'm on atom and it doesn't work
@pwaterz you should install imwheel
and put it to start with your system. Simple like that
To all the linux falks here, there is very easy hack. you can install imwheel and it will fix this issue. I have been using this hack for a while now and haven't noticed any issues. if you are on ubuntu its as easy as
sudo apt install imwheel
and then add that into your system startup programs by opening startup applications gui and adding program/usr/bin/imwheel
.
THANK YOU hardidangar and dr0p. Linux Newbie, here. Hope to pay back the community in the future.
The issue that I have found with the imwheel
workaround is that it alters the scroll behaviour and adds a small but noticeable delay when scrolling (especially noticeable if you don't use smooth scrolling everywhere).
I also want to point out the imwheel isn't a perfect solution. I've noticed some odd behavior since switching to it. I think the issue with imwheel are less of annoyance than the scroll jumping issue prior but I would not consider it a fix, it's more a band-aide.
Have that problem on Arch Linux with Gnome using Chrome and VSCode. After switching from Xorg to Wayland, this does not appear anymore. I was using Xorg for compatibility reasons.
Since for me imwheel causes other problems, tried alternatives and workaround I found is: Don't use alt+tab, instead for example use win+1, win+2. These shortcuts will actually change back and forth to first and second applications in your dock, similar experience without scroll issues.
I guess some of you might not like this since alt+tab is unchangeable, but I can't handle this scroll issue.
Same problem occur on:
Ubuntu 18.04.2 LTS
Xfce 4.12 Desktop or Gnome 3.28.2 Desktop
Occur when I scroll Thunar 1.6.15 or Chrome 70.0.3538.77 (Official Build) and alt-tab to Visual Studio Code my code jump the scroll when I start to scroll the code opened.
As if the jump occurred the same size as I did in the other software.
This issue plagues me on Gnome 3.2. However, I can do xdotool windowactivate <window-id>
and not experience the scroll jump.
If someone has experience writing gnome plugins, you might be able to override alt-tab
and instead of doing the normal focus behavior, send the window id to xdotool windowactivate <window-id>
or some other command
I was attempting to make alt-tab trigger an additional, hidden scroll down and up using xdotool
but unfortunately that didn't seem to work for me. Something along those lines might just be the hack we need.
This issue has been fixed, we just need someone to make little tutorial how
to compile the latest mutter from source.
That would be greatly appreciated.
On Sat, Feb 23, 2019, 13:20 Luke <[email protected] wrote:
I was attempting to make alt-tab trigger an additional, hidden scroll down
and up using xdotool but unfortunately that didn't seem to work for me.
Something along those lines might just be the hack we need.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/28795#issuecomment-466621373,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-WqlTj3XZ_wUHB43CVnZVoSyUZz48dks5vQN3FgaJpZM4N66mN
.
What do you mean this has been fixed? Can you point to a commit or another thread?
@pwaterz I think @mayaru is referring to this issue in mutter: https://gitlab.gnome.org/GNOME/mutter/issues/401
One of the more salient comments on that issue:
It doesn't happen in Wayland, just in Xorg but again, only in Mutter based WMs.
If it just happens on Xorg, IMHO it's a strong indication it's not really mutter's fault (if anything, it's doing the focus change in a way the application didn't cater of, but there's nothing to "fix" about it)
With Xorg smooth scrolling, scroll axes are transmitted as 2 dx/dy axes, which accumulate the scroll performed thus far. The catch is that this state is global to the whole session, if you scroll on an app, go somewhere else and scroll, and go back to the app, it will see values affected by the scrolling outside.
Toolkits (I'll include electron here) must be smart about this, and reset their own state when the pointer enters the application so that the changes in dx/dy that happened since the last time are ignored.
This is a known issue with XI2.3 smooth scrolling.
That analysis sounds about right, as this problem plagues both code
and chrome
. Details were added to this issue (first opened in May 2016!): https://bugs.chromium.org/p/chromium/issues/detail?id=608246
IMO, the appropriate thing to do now is put pressure on the chromium team to fix their bug.
It is not just from Chromium, I reproduced it on my file manager (Ubuntu 18.04) and even on a blank desktop, just scroll on any page and return to vscode and scroll again, all the previous scroll events fire.
There are two things to note tho-
I also noted that this isn't just with vs code, you can scroll on vs code and return to Chrome the same burst will happen. Notably, this won't happen if you switch between different windows of the same application.
It is not just from Chromium, I reproduced it on my file manager [...]
Right, it's Chrome-based apps not handling those scroll offsets correctly -- it doesn't matter which app you scroll in before alt-tabbing over to code
/chrome
/etc. Chrome needs to reset its internal scroll state in this scenario (edit: and by "Chrome", I mean the shared code base used by Electron apps / Chrome / Opera(?) / etc -- I _didn't_ mean just the Chrome/Chromium app).
This issue plagues me on Gnome 3.2. However, I can do
xdotool windowactivate <window-id>
and not experience the scroll jump.If someone has experience writing gnome plugins, you might be able to override
alt-tab
and instead of doing the normal focus behavior, send the window id toxdotool windowactivate <window-id>
or some other command
If this is true then it should be possible to write a gnome shell extension to hack the built-in alt-tab switcher:
https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/ui/altTab.js
and replace it with xdotool
. I've been trying to do that with no success, for I have very little experience in gnome extension developing... If someone succeeded please share it! The scroll jumps are really driving me crazy now.
mayaru in 1.32.2 problem not fixed...
I'm sorry, you are tight I got confused about another bug about the refresh
rate of the monitor. My bad :)
But in any case someone posted before a workaround fix. You can use
imwheel, and update the config file with -1 values for touchpads and 1
values for mouse. Would be nice for someone to make a script so that one it
switches bet the two settings when a mouse is detected. Now I'm switching
manually and it's working fine.
On Thu, Mar 14, 2019, 13:27 Maxim <[email protected] wrote:
mayaru in 1.32.2 problem not fixed...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/28795#issuecomment-472720388,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-Wqp0Uaqq34k_2zv3RbasG2zk49V9Tks5vWevAgaJpZM4N66mN
.
imwheel not help...
Change the config file.
On Thu, Mar 14, 2019, 20:27 Maxim <[email protected] wrote:
imwheel not help...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/28795#issuecomment-472852588,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV-WqruE1HadxIcHuKBehM07-nDvxlEFks5vWk43gaJpZM4N66mN
.
imwheel just moves the problem. When I installed it, it did stop the scroll from jumping in vscode, but when I moved to chrome, postman, and slack it would then jump there. Note all those applications use chromium.
Same problem here.
Ubuntu 18.04
VSCode: 1.32.2
Chrome: 73.0.3683.75
I think Github should have a bounty system similar to the one in StackOverflow to fund interest in solving issues like these.
It's up to the project: https://github.com/bountysource/core/wiki/Frequently-Asked-Questions
It is not just from Chromium, I reproduced it on my file manager (Ubuntu 18.04) and even on a blank desktop, just scroll on any page and return to vscode and scroll again, all the previous scroll events fire.
There are two things to note tho-
- The amount of scroll in vscode is exactly equal to the number of scroll events you fired in the other window.
- The scroll burst gets cancelled if you change the device i.e using mouse wheel to scroll other windows and use touch pad for the first scroll in vs code will cancel it.
I also noted that this isn't just with vs code, you can scroll on vs code and return to Chrome the same burst will happen. Notably, this won't happen if you switch between different windows of the same application.
I do observe exact same scenario. Still, now I can't find any solutions. Please update us if anyone find one.
Same problem here.
Ubuntu 18.04
VSCode: 1.32.3
Chrome: 73.0.3683.86
Switch to ubuntu on wayland to solve the problem
Same problem here.
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic
Chrome: Version 73.0.3683.86 (Official Build) (64-bit)
VSCode
Version: 1.32.3
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:38:49.842Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.0-16-generic
Experiencing the same issue.
Ubuntu 18.04.2
VSCode: 1.32.3
Chrome: 73.0.3683.86
Teaching my self to use win+1, win+2 and so on in the meantime.
According to https://bugs.chromium.org/p/chromium/issues/detail?id=807187#c20 and some of my preliminary testings on Manjaro 18.0.4, this bug seems to be fixed (_miraculously!_) in GNOME (mutter) 3.32.0.
I can confirm it's fixed in latest mutter!
>
Same here it's fixed in fedora rawhide (which uses gnome 3.32)
Awesome to see that it's fixed. I hope VSCodium updates soon. :)
Too bad for Debian users. 2021 not too far away... :(
Oh, come on, it's been 2 years and now i'm back to js development on VSCode, and you still doesn't fix this scroll bug?
Oh, come on, it's been 2 years and now i'm back to js development on VSCode, and you still doesn't fix this scroll bug?
I believe this is an open source project. No one is obligated to fix something. We report and discuss the problem politely.
Anyone else running Ubuntu 18.04 with VS 1.33.1 and Slack 3.3.8 64-bit? I am still experiencing the issue. Scrolling down in Slack/Chrome and switching back to VSC and clicking/scrolling will input the late scrolling events.
Yes, this is still an active issue for ubuntu 18.04.
Have same issue
Gnome 3.30.2
Ubuntu 18.10
edit - Upgraded to 19.04 which comes with Gnome 3.32.1 and it seems to be fixed.
It's got worse on Fedora 29, code-1.33.0
I think it has to do with code formatting plugins, which change content before save. Now cursor often jumps at end of file on each save, while the viewport remains in place. But if you press up/down arrow keys, scroll jumps to end of file too.
@alexandrudima Alex, any chance to please have a look at this?
Just upgraded to 19.04 and the issue is finally fixed.
Have same issue
Gnome 3.30.2
Ubuntu 18.10edit - Upgraded to 19.04 which comes with Gnome 3.32.1 and it seems to be fixed.
Will try to update and check if it fixes.
edit: upgraded to Ubuntu 19.04 and Gnome 3.32.1 and it's fixed. Ty so much
I have a new T480 with Debian 9.9 which still faces the same issue. Kernel 4.9.144-3.1
I can also confirm I no longer have this issue on ubuntu 19.04.
Hello !
I'm experiencing this issue as well on Ubuntu 18.04. (Hardware Enablement Stack installed). Any chances the fix will be backported to gnome 3.28 ? Or do I have to upgrade to 18.10 then 19.04 to fix the issue ?
I know each version of Ubuntu freezes its packages once in the release phase, but maybe they backport import fix such as this one ?
Hello Guys! Because of this bug I moved to KDE recently, and so far it looks very good: Bug has disappeared and as addition there are many shiny plasmoid widgets.
Ubuntu 18.04
I'm also observing this behavior on my machine:
OS: Ubuntu 18.04.2 LTS
Desktop Env: Gnome 3.28.2
Chrome Version: 75.0.3770.100 (Official Build) (64-bit)
--- VS Code
Version: 1.35.1
Commit: c7d83e57cd18f18026a8162d042843bda1bcf21f
Date: 2019-06-12T14:27:31.086Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.0-25-generic snap
Just to follow up. This is still fixed when running ubuntu 19.04 with stock gnome.
Is this Os issue or vscode it self?
Because face in other application also, between text editor and chromium
Having Ubuntu 18.04
VS Code 1.34.0
Chromium Version 75.0.3770.90
Also i noticed it's not random scroll, it scroll same as i did on other application. Up or down and how i scroll. Like it's managing state with each other, need to find a option to switch it off.
$ sudo apt-get install imwheel
$ imwheel
Worked for me.
Version: 1.36.1
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:55:08.091Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.0.0-20-generic Ubuntu 19.04
Seems to be fixed in Ubuntu 19.04 & latest MacOS.
@vishal112logistic But the scrolling is not smooth.
Updating to ubuntu 19.04 is the best fix.
I am using Ubuntu 18.04 and I have this problem when I switch tabs from Chrome to VS Code. I tried with Chrome + Terminal and I could reproduce the same behavior when I alt+tab from Terminal to Chrome (Chrome scroll bar jumps), but not the opposite (Terminal scrolls fine).
I was using Ubuntu 19 before and didn't have this problem, so I am upgrading to Ubuntu 19 now.
It seems nobody mentioned this, but the scrolling isn't random. If I scroll to the bottom of the page on Chrome and alt+tab to VS Code, the page jumps to the bottom proportionally to how much I scrolled on Chrome. From VS Code to Chrome is also the same. And from the Terminal to Chrome too.
PS: Ubuntu 19 is OK. I don't think this is a problem of VS Code, since I had the same using Ubuntu 18 between Chrome and the Terminal windows.
Okay, So as people are reporting it doesn't reproduce in 19.04.
1) I'm on 18.04 LTS, which I can't upgrade to non LTS,
2) Some people find this in windows and OSX as well
So I would really appreciate if we get some fix for it.
Note: I'm not very technical so please be kind and go easy on people like me.
Dear @mariusa
Could you please further elaborate/update the inital post with some clarifications, in efforts to avoid further noise in this. At the bottom of the post may help?
Perhaps some key points;
Fix; Does not yet exist.
Linux Workarounds (Not to be confused with a fix);
Note: Ubuntu 1904 (Desktop) appears to be using Wayland.
I'm not sure we will see further updates in here, which is a bit disappointing from the developers. I would like to have some official guidance, even if it's pointing us to other resources. As mentioned; it does not seem to be an issue with VSCode itself, but rather Electron.
Ubuntu: 19.04
VsCode:
Version: 1.38.1
Date: 2019-09-11T13:30:08.229Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 4.15.0-64-generic
The error remains :(
@vishal112logistic method worked form me in Ubuntu 18.04
$ sudo apt-get install imwheel
$ imwheel
@vishal112logistic method worked form me in Ubuntu 18.04
$ sudo apt-get install imwheel
$ imwheel
This solution is not complete. It disables the zoom by Ctrl + wheel in applications (Firefox, Chromium, LibreOffice, PDF reader...). You were able to fix side problems mentioned above? I will be grateful for this information.
Added: I found a solution to fix side problems. To do this, change imwheel config. More info here: https://wiki.archlinux.org/index.php/IMWheel
It disables the zoom by Ctrl + wheel in application
Whoa, I even don't know that shortcut for whole time :P
Running imwheel
causes a really horrible scrolling experience for me- very rough/jumpy especially when scrolling slowly.
Anyone able to actually determine what imwheel is doing to avoid the scroll bug described in this issue? I'd love to find the software/package actually responsible and find/open an issue with them directly.
@sensiloles @uphlewis I just agreed, I noticed that I was used Ctrl + wheel for zoom on Inkscape, but it isn't works after using imwheel. What should I do :(
@sensiloles @uphlewis I just agreed, I noticed that I was used Ctrl + wheel for zoom on Inkscape, but it isn't works after using imwheel. What should I do :(
Create or edit ~/.imwheelrc
A line ".*" in the file means that the settings will be applied to all programs.
Thank you so much, it works, so far so good.
I'm using ubuntu 18.04, but your link for arch, and I configured following way on my system:
".*"
Control_L, Up, Control_L|Button4
Control_L, Down, Control_L|Button5
imwheel --kill --buttons "4 5"
Now, my zoom works fine and scroll didn't jumps.
I have the same error and I don't know what happens because the other electron-based editors do not seem to have it when one has the pointer selecting another line of code and one scrolls later with alt-tab I change the window back to vscode and skip almost a 200 lines of code randomly throws or down more than everything has happened to me down nose if I have something to do with the mouse cursor in which position this
One big downside of using imwheel
: two-finger scrolling on a trackpad is choppy as hell (in 18.04). The solutions I've seen online for this is to kill imwheel
, but then we have the random scrolling issue again in VSCode. It seems like there's no way to win. :disappointed:
mark this issue,
Thank you so much, it works, so far so good.
I'm using ubuntu 18.04, but your link for arch, and I configured following way on my system:
- Add following lines to ~/.imwheelrc and save
".*" Control_L, Up, Control_L|Button4 Control_L, Down, Control_L|Button5
- Add following command to Startup Application Preferences
imwheel --kill --buttons "4 5"
Now, my zoom works fine and scroll didn't jumps.
this is work for me,i am use archlinux.
imwheel
definitely still feels like it adds delay and choppiness to scrolling... System wide.
Same problem for me (Debian 10)
VSC version: 1.40.2
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.19.0-6-amd64
I'm using imwheel and will try @khaschuluu solution...
Can confirm this doesn't occur when running Ubuntu 19.10, so it must be mitigated/resolved by a fix in GNOME/Mutter at least as early as that which ships with 19.10.
So the folks following along on an LTS release should only need to wait until April next year for 20.04 LTS to include these fixes.
I'm on Manjaro 4.19 LTS with Xfce. Not sure when/if I can switch to Wayland. So for a real fix I must wait for an Electron/Chrome fix? Is there an according bug ticket to watch in the Chromium project?
@thegitfather I don't believe 19.10 (updated GNOME and Mutter) is running on Wayland, I certainly am not. So it must be resolved in a later update of Mutter.
So fed up, i upgraded from 18.04 to 19.04. Touchpad definitely "feels" different (accelleration/sensitivity) but the scroll jumping appears to be fixed. Good luck all.
I did that but after some weeks my laptop kept on formatting after every restart so back again to 18.04
I tried using imwheel
and it worked fine, except it somehow broke my extensions tab on VSCode. See https://github.com/microsoft/vscode/issues/86583 for more details.
Still happens on linux, XUbuntu 19.04 5.0.0-38-generic, XFCE desktop
Version: 1.42.1
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:50:36.977Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 5.0.0-38-generic snap
(snap version c47d83b2)
Hello, is there any progress in this bug? It really annoys me :D
Only 155 comments since Jun 15, 2017. We should be patient.
I can reproduce that at debian 10
i'm waiting solution. Somebody?
Still can reproduce this issue very easily the same way as others above. Ubuntu 18.04 tabbing between apps like Firefox and VS Code, then using my scroll wheel in code causes me to go to the bottom of the file. Mostly a productivity bug, have not found a way to workaround/prevent this from happening - if anyone knows one please share it! Happy to help reproduce the bug with a video or a video sharing session/call.
@chriswernette I found a workaround: install the program imwheel
and run it. It should fix the bug as long as your computer is on. Please note that adding this command to your rc file might break vscode. You should run it manually in your CLI whenever you start your computer... Hoping they will fix this bug someday.
By the way, only alt + tab causes this problem. Switching between tabs with the mouse pointer did not cause this problem for me. Also I realized that Firefox solved this issue whereas it still exists in Chrome.
Can confirm repro of the bug as described: 1) on chrome view a tab, scrolling up or down substantially on one page, 2) alt-tab to vscode, barely touch the scroll wheel and it jumps up or down replaying the scrolling on the chrome window.
On ubuntu .
By the way, only alt + tab causes this problem. Switching between tabs with the mouse pointer did not cause this problem for me. Also I realized that Firefox solved this issue whereas it still exists in Chrome.
FYI, I am using Firefox on Ubuntu 18.04 and still having the issue. Can confirm that using the mouse instead of alt+tab seems to be a workaround.
Hi mates.
I'm also among the victims.
It is absolutely annoying.
But this is an issue between Electron and Browser.
In my case, it is happening between Chrome and VSC, and Chrome and Slack also.
Ubuntu 18.04
Does anyone know if this really is some problem going back to 2016 or beyond?
These are pointing to webkit
https://bugs.chromium.org/p/chromium/issues/detail?id=807187
https://bugs.chromium.org/p/chromium/issues/detail?id=608246
Not sure if this was directly link above but looks like the best:
Can anyone on this thread confirm it is fixed on 19.04 Ubuntu ? Am thinking of upgrading to see or spinning up a VM
I've upgraded to 19.10 and it seems to be gone. Lots of other stuff (drivers) unrelated to this broke so take that into consideration.
Can anyone on this thread confirm it is fixed on 19.04 Ubuntu ? Am thinking of upgrading to see or spinning up a VM
I am on XUbuntu 19.04 for a month now, bug is still here, see my comment above https://github.com/microsoft/vscode/issues/28795#issuecomment-590056590
@miro-janosik try 19.10. It seems to be fixed for me now.
I confirm this bug happening on Ubuntu 18.04.4 LTS
My VSCode about info:
Version: 1.43.2
Commit: 0ba0ca52957102ca3527cf479571617f0de6ed50
Date: 2020-03-24T07:52:11.516Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.3.0-42-generic snap
@miro-janosik try 19.10. It seems to be fixed for me now.
Updated to XUbuntu 19.10 eoan, 5.3.0-42-generic, VSCode 1.43.2. and problem is still there.
Steps to reproduce:
click in VSCode text editor window, alt+tab to Firefox (blank page), scroll down twice, alt+tab to VSCode, click into code, scroll down - it jumps down a lot.
@miro-janosik What version of Mutter are you running? (mutter --version
)
Since moving to Ubuntu 19.10, which seems to bring with it Mutter 3.34, this issue has gone away for me.
@miro-janosik What version of Mutter are you running? (
mutter --version
)Since moving to Ubuntu 19.10, which seems to bring with it Mutter 3.34, this issue has gone away for me.
It shows nothing, as I don't have mutter installed. I see that "Mutter is a Wayland display server". As I use XUbuntu which means XFCE frontend instead of GNOME and it does not use Wayland.
Right, somehow I missed that you were running Xubuntu.
In any case, I'm not running a Wayland session, just bog standard X11. What this might indicate is that GNOME developers have addressed this Chromium bug with a workaround at their end in Mutter.
Of course, that doesn't really help you out on XFCE, sorry. You might want to look for the Mutter fix (or issue at least -- I believe it was linked earlier in this thread) and report this on XFCE or maybe XFWM4.
I upgrade / update ubuntu 18.04.4 and bug is still here...
To reproduce the issue consistently, while switching to the browser, you need to scroll a fair amount of time. When you head back to VsCode and try to scroll, it will jump. It's quite annoying... I'm on Ubuntu 18.04.3.
However, I strongly believe this error is specific to whatever uses Chromium. So I'm facing the issue on Google Chrome as well.
I don't know if we can consider that as a workaround. But, since after having scrolled on the browser on another window, it looks to me the scroll you performed is kept in memory and on the next scroll it jumps on vscode. So, somehow having an empty tab, where to drop that excessive jump, should reset that scroll in memory. I'm not an expert, so apologies, if that sounds, garbages for you.
Ubuntu 18 is supposed to be an LTS, why hasn’t this extremely annoying
issue, which is fixed in 19+, been backported to 18? Please guys, we’re all
suffering here!
On Thu, Apr 2, 2020 at 2:44 AM Blair Jersyer notifications@github.com
wrote:
To reproduce the issue consistently, while switching to the browser, you
need to scroll a fair amount of time. When you head back to VsCode and try
to scroll, it will jump. It's quite annoying... I'm on Ubuntu 18.04.3—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/28795#issuecomment-607653635,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGEHKX3JWCBB5FI4TSLJFTRKQX4RANCNFSM4DPLVGGQ
.
Please guys, we’re all suffering here!
Pain is weakness leaving the body... Sorry :) I feel you and im binding now:
wmctrl -a Code
in my window manger to ALT+1 or something to focus vscode. This works! Meaning somebody could write a shell script with remembering last focused Window to replace X11 Tab behaviour. Or am I missing something?
Ubuntu 18 is supposed to be an LTS, why hasn’t this extremely annoying issue, which is fixed in 19+, been backported to 18? Please guys, we’re all suffering here!
…
On Thu, Apr 2, 2020 at 2:44 AM Blair Jersyer @.*> wrote: To reproduce the issue consistently, while switching to the browser, you need to scroll a fair amount of time. When you head back to VsCode and try to scroll, it will jump. It's quite annoying... I'm on Ubuntu 18.04.3 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28795 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGEHKX3JWCBB5FI4TSLJFTRKQX4RANCNFSM4DPLVGGQ .
So upgrading to 19 fixes the issue ? If yes, I'll upgrade then.
The issue with imwheel is that it prevents me from being able to hold CTRL and zoom in (Figma)...
And there feels like a delay with my mouse back and forward buttons.
Wow, this was open almost 3 years ago. I just upgraded to Ubuntu 18.04.4 LTS and I can still produce this bug. This was not a problem on my Ubuntu 16.04.
So the answer is just hidden in the comments https://github.com/microsoft/vscode/issues/28795#issuecomment-391258341.
For Ubuntu 18.04.4 LTS just install imwheel
package. sudo apt install imwheel
. Make sure to run it as well.
So the answer is just hidden in the comments #28795 (comment).
For Ubuntu 18.04.4 LTS just installimwheel
package.sudo apt install imwheel
. Make sure to run it as well.
And when you read on you will see that imwheel
is crappy... My workaround (alttab
) looks ugly but works like a charm... https://github.com/microsoft/vscode/issues/28795#issuecomment-608751048
also, while running imwheel "as is" do the trick, setting it to not disabled back/forward buttons with imwheel -b 45
does not work as a workaround
@thegitfather tnx for the ugly workaround, it seems to make vscode freeze for a moment preventing the jumping problem (which sometimes makes me want to throw my computer off the balcony).
do you think it's possible to exclude the desktop application from alttab?
the desktop always being the first or second app seems to prevent me from regular alttab behaviour like switching back and fourth without pressing tab multiple times.
also alttab is responding very slowly, did you manage to do something about that?
when I alttab to a console window, it doesn't receive focus, is there a fix for that?
edit: maybe not receiving focus "fixes" the problem.
Fix for missing logo (ubuntu 18.04)
sudo cp ~/Downloads/code.png /usr/share/icons/hicolor/256x256/apps/code.png
After upgrading to Ubuntu 20.04 LTS Focal Fossa I can confirm that this annoying bug disappeared for me. VS Code feels like heaven once more!
After upgrading to Ubuntu 20.04 LTS Focal Fossa I can confirm that this annoying bug still present with all extensions disabled.
I'm on Ubuntu 18.04.
Here's my band-aid for this irritating bug: every time I switch to VS Code (w/ ALT+TAB), I do one quick scroll regardless of direction while holding SHIFT, and then continue normal scrolling. No jumps.
ممكن افهم تفاصيل اكثر
In Ubuntu 18.04 just install imwheel.
sudo apt-get install imwheel
This worked for me. Thanks @shamim-42
@shamim-42 absolutely killed it. Had this bug for years, first in Atom, then in VSCode, then in other Electron-based apps. Never found a fix, until I read your post today.
After installing imwheel
I added it to my session startup items, and it worked.
No idea if there are side effects yet, as I've only tested the particular "annoying" use case though.
Thanks a lot for the temporary fix, @shamim-42 !
This is really annoying bug!
It looks like imwheel
itself has an issue with jumps during the scrolling by using a touchpad :( Tested on 18.04.2.
Confirmed, the imwheel fix only works for me using an external mouse. On
trackpad it's all stuttering.
On Thu, 11 Jun 2020, 15:33 Oleksandr Shlinchak, notifications@github.com
wrote:
This is really annoying bug!
It looks like imwheel itself has an issue with jumps during the scrolling
by using a touchpad :( Tested on 18.04.2.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/28795#issuecomment-642698120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGI5FMXFEVJPFCQYKXWOHTRWDTM3ANCNFSM4DPLVGGQ
.
So annoying bug and so simple fix - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/181/diffs?commit_id=5a71ed44115f730263086218316839fad006b71c
For updating Gnome I had to upgrade to Ubuntu 20.04. Now all works fine as it should have been :v:
Hi, the issue is fixed from Ubuntu 19.04 (that I'm currently using). If that's too annoying for you and don't want to use third-party solutions, then upgrade your Ubuntu.
Ubuntu 19 is not the LTS, 18 is. Many people cannot upgrade because of
this. I should not have to leave the LTS to fix an extremely annoying bug.
imwheel makes the trackpad unusable on a laptop and is not a good
solution.
On Wed, Jun 17, 2020 at 7:51 AM Blair Jersyer notifications@github.com
wrote:
Hi, the issue is fixed from Ubuntu 19.04 (that I'm currently using). If
that's too annoying for you, then upgrade your Ubuntu.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/28795#issuecomment-645326887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGEHKUOGUI5KWNTEOYYZYDRXCU25ANCNFSM4DPLVGGQ
.
I can confirm that it's not fixed on 20.04. I use Xubuntu.
On Wed, 17 Jun 2020, 12:54 James Guillochon, notifications@github.com
wrote:
Ubuntu 19 is not the LTS, 18 is. Many people cannot upgrade because of
this. I should not have to leave the LTS to fix an extremely annoying bug.
imwheel makes the trackpad unusable on a laptop and is not a good
solution.On Wed, Jun 17, 2020 at 7:51 AM Blair Jersyer notifications@github.com
wrote:Hi, the issue is fixed from Ubuntu 19.04 (that I'm currently using). If
that's too annoying for you, then upgrade your Ubuntu.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/vscode/issues/28795#issuecomment-645326887
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ABGEHKUOGUI5KWNTEOYYZYDRXCU25ANCNFSM4DPLVGGQ.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/28795#issuecomment-645328184,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGI5FOQBD6JMBHXUTDXF5DRXCVGBANCNFSM4DPLVGGQ
.
Ubuntu 19 is not the LTS, 18 is. Many people cannot upgrade because of this. I should not have to leave the LTS to fix an extremely annoying bug. imwheel makes the trackpad unusable on a laptop and is not a good solution.
…
On Wed, Jun 17, 2020 at 7:51 AM Blair Jersyer @.*> wrote: Hi, the issue is fixed from Ubuntu 19.04 (that I'm currently using). If that's too annoying for you, then upgrade your Ubuntu. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28795 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGEHKUOGUI5KWNTEOYYZYDRXCU25ANCNFSM4DPLVGGQ .
As I've said... from Ubuntu 19 the issue is fixed. This includes Ubuntu 20.04. There are solutions available for you, further complaints are pointless. I had Ubuntu 18.04 on my Laptop and PC where I was facing the issue, I've upgraded both to 19.04 and 20.04 and the issue is solved.
Anyway, I'm unsubscribing to this issue as it's no more relevant for me. Good luck people.
@Blair2004 We are too using 20.04 and the problem still persists, at least for trackpads - and the imwheel
option doesn't play nice with trackpads. I'm curious, did the problem get fixed on 20.04 for you on trackpad too?
Oh and maybe this is helpful - we don't use Gnome, we use XFCE.
@Blair2004 We are too using 20.04 and the problem still persists, at least for trackpads - and the
imwheel
option doesn't play nice with trackpads. I'm curious, did the problem get fixed on 20.04 for you on trackpad too?Oh and maybe this is helpful - we don't use Gnome, we use XFCE.
That's probably the reason, I'm using Gnome.
Issue present using xfce+ubuntu 20.04 (actually ubuntustudio)+trackpad
Issue present using xfce+ubuntu 20.04 (actually ubuntustudio)+trackpad
Similar platform (Xubuntu 20.04) and issue for me, but happens with mouse too.
Having the issue with Linux Mint MATE (GNOME2 fork). Interestingly I've only noticed it since I updated to Linux Mint 20; when I was on Linux Mint 18 (with an older version of VS Code) I didn't have this problem.
This is bugging me for quite some time, and I think I can reproduce it. It only happens (to me at least) if there is the mini search box at the top right corner of the editor. If I dismiss it, the scrolling disappears.
EDIT: I'm on Windows & OSX.
Same here (Xubuntu)
Reproduced on Debian 10 + gnome-shell 3.30.2-11~deb10u2
Reproduces very often on my system as well (Ubuntu MATE 20.04.01). I work mostly with keyboard and mouse.
Installing (and running) imwheel
didn't workaround the issue - I just had one occurrence.
I suspect (hard to say, since I've never paid attention to the cause) that it happens when I switch desktop workspace (via hotkeys) and/or switch foreground (again, via hotkeys, in this case, Alt+Tab
.
This issue instantly disorients me as I'm flung into a random chunk of code, and have to find my way back. :dizzy:
@Microsoft VS-Code crew: whatever you're doing to address this clearly isn't working.
Time to put together a tiger-team and tackle this one :tiger2: :runner: -- for the sake of all our sanity. :face_with_head_bandage:
I can confirm that the root cause of this problem is the underlying stack (Electron?) as I was able to find similar problems outside of VSCode.
I'll just bump this thread as this issue is indeed frustrating.
Happens to me in Visual Studio Code after alt+tabbing to firefox browser. Any scrolling performed in Firefox will buffer and be applied as soon as I do any scrolling back in the VS-window. Super frustrating to scroll back to the code-section I'm working on every time.
Edit: Firefox*, not Chrome..
Reproduced with Vscodium 1.47 and Gedit too.
Steps to reproduce:
1.Open a long document with Vscode, another one with Gedit
Config: Debian 10 + gnome-shell 3.30.2-11~deb10u2
Pointer: Lenovo trackpoint keyboard
VsCodium Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T15:51:39.791Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.7.0-3-amd64
@iootaa imwheel seems to fix the issue.
@yuriy-chumak It doesn't work for trackpads.
Yes, I'm using a trackpoint and imwheel is dedicated to mice
@hickscorp , yup. And the mouse-pointer
also jump randomly (somewhere to the bottom) whenever i use mouse and or trackpad. I was thinking that my mouse faulty.
With Ubuntu 18.04 and VScode 1.50.1,
~: sudo apt install imwheel
~: imwheel
INFO: imwheel started
really works.
I doubt it is an OS problem because it happens to other applications...
Most helpful comment
Okay.. from what I found out so far it looks like it has something to do with input coming from different virtual input devices. Installing and running
imwheel
without any additional configuration fixes the issue for all affected applications.