After 1.66 update scroll speed is faster

[MariuzM]

After i have done 1.66 update using MacBook Pro M1 Max trackback noticed that in code window scrolling is faster.

Version: 1.66.0 Electron: 17.2.0 Chromium: 98.0.4758.109 Node.js: 16.13.0 V8: 9.8.177.11-electron.0 OS: Darwin arm64 21.4.0

[UCetinkaya94]

Yes, I just updated and immediately noticed this as well

[deepak1556]

/gifPlease

[MariuzM]

@deepak1556 explain to me how you expect me to provide screenshot or something when this is about scrolling? Maybe please try to understand the issue first before just randomly slapping bot

[deepak1556]

I believe https://github.com/microsoft/vscode/issues/146403#issuecomment-1084567553 covers it all since the issue lacks context. If you are seeing a difference in scrolling compared to the previous stable version, please share a screen recording comparing the differences.

[UCetinkaya94]

Here is a very unscientific comparison:

Version 1.65

https://user-images.githubusercontent.com/67158575/161095598-240bebd6-a12c-4120-956f-4b43707d127c.mp4

Version 1.66

https://user-images.githubusercontent.com/67158575/161095741-76102f9e-46b7-4d70-97eb-c2ac928c0096.mp4

[deepak1556]

Can you follow the steps below for both 1.66 and 1.65 and attach the generated profile,

• Run Developer: Toggle Developer Tools from the command palette
• Go the Performance tab
• Click the record button or Cmd+E
• Perform the scrolling
• Stop the recording

[chen-hongzhi]

For now, you could set the "editor.mouseWheelScrollSensitivity" to (or below) 0.5 to slow down the scrolling speed. Also: workbench.list.mouseWheelScrollSensitivity terminal.integrated.mouseWheelScrollSensitivity

[KristianBalaj]

+1, noticing this, too.

[patrick-fu]

For now, you could set the "editor.mouseWheelScrollSensitivity" to (or below) 0.5 to slow down the scrolling speed. Also: workbench.list.mouseWheelScrollSensitivity terminal.integrated.mouseWheelScrollSensitivity

This option works, but it doesn't feel smooth.

Especially on 120Hz MacBook, after reduce the mouseWheelScrollSensitivity, the frame rate of the scrolling screen is significantly reduced. 🤨

Hope that VS Code can fix this issue instead of letting users manually change this sensitivity option.

[josexy]

I also noticed that after updating the 1.66 version, the scrolling code is faster than before, not so smooth

[varog-norman]

The same issue here for MacBook

[deepak1556]

It would be helpful if anyone facing this issue can provide the logs mentioned in https://github.com/microsoft/vscode/issues/146403#issuecomment-1084795587, otherwise the issue cannot move forward with identifying the root cause.

[MariuzM]

Sorry but just going to say, this is typical Indian Customer Service response... only following the script. A lot of people are facing this, so why cant you just ask the creators if they have same issue is beyond me.

[KristianBalaj]

Even after lowering the mouseWheelSensitivity setting the rocket speed scrolling remains with jupyter notebooks in VS Code.

Also, the same applies to all the tabs (Explorer, Extensions, etc.)

EDIT: I'm on MacOS Intel arch.

[MariuzM]

@KristianBalaj for me when i lowered the setting it did help, i'm using 0.7 and feels ok, but choppy because not 120hz smooth as it was before but i can live with that

[KristianBalaj]

I have this setting lowered to 0.4, but it really does not feel like it felt before the update.

I've modified only the Editor: mouseWheelScrollSensitivity and it works only in a classical editor - not even with the jupyter notebooks.

[KristianBalaj]

@deepak1556 Here is the profile.

At first I've scrolled in the editor (classic text file) and then I've scrolled in the Explorer.

https://easyupload.io/7dt5ws

[bmalehorn]

Here is a very unscientific comparison:

Version 1.65

1.65.mp4 Version 1.66

1.66.mp4

Hi all, here's a simpler reproduction.

On 1.65.2, scrolling down once on the scroll wheel moves the screen by 9 lines:

https://user-images.githubusercontent.com/3344958/161851371-7628cee8-4aa0-4b1f-8c38-a24d96348c21.mp4

1.65.2.json.zip

On 1.66.0, scrolling down once on the scroll wheel moves the screen by 18 lines:

https://user-images.githubusercontent.com/3344958/161851395-428c4dda-1774-45f7-b0e4-38175ed4fe3d.mp4

1.66.0.json.zip

I'm guessing whatever issue is affecting the scroll wheel is also affecting the trackpad.

@deepak1556 I've attached recordings of both 1.65.2 and 1.66.0.

[deepak1556]

Thanks for the traces @bmalehorn , I don't see any difference in the smooth scrolling stack traces /cc @alexdima has there been any changes in core with scrolling code path ? Although I do notice the number of idle frames are different between 1.65 and 1.66 for the same test, I think this should be addressed with https://github.com/electron/electron/pull/33618. Will check back on this once we update to Electron 17.4.0

@bmalehorn can you perform one more test and see if the issue repros with https://vscode.dev/ with same workspace settings.

[bmalehorn]

@bmalehorn can you perform one more test and see if the issue repros with https://vscode.dev/ with same workspace settings.

@deepak1556 Sure. With the same settings, on vscode 1.66 on vscode.dev, scrolling down once on the scroll wheel moves the screen by 18 lines:

https://user-images.githubusercontent.com/3344958/162035523-f190a6ec-7f7d-4913-99a8-8898b0f5c34f.mp4

[fxck]

had to change these to 0.3 to make it feel about the same as before

[deepak1556]

Can anyone check if the issue persists with latest insiders https://code.visualstudio.com/insiders that comes with a newer version of the runtime which contains the fix linked in https://github.com/microsoft/vscode/issues/146403#issuecomment-1089703207

[bmalehorn]

Can anyone check if the issue persists with latest insiders https://code.visualstudio.com/insiders that comes with a newer version of the runtime which contains the fix linked in #146403 (comment)

@deepak1556 on the latest insiders 1.67, scrolling down once still scrolls the screen by 18 lines:

https://user-images.githubusercontent.com/3344958/162499111-23042d17-c682-4798-b444-1e01557aad16.mp4

It probably wouldn't be too hard to reproduce this issue if you have a mouse lying around, or some way of simulating a mouse scroll input within vscode.

[deepak1556]

@bmalehorn thanks for testing, the fix in 17.4.0 was a backport from newer chromium versions and will not have affect your scenario since you were also able to repro with stable chrome on vscode.dev. I will follow up on the scroll wheel issue.

It would be great to confirm, if others seeing the issue on M1 macs are still able to repro with latest insiders ?

[klanchman]

I'm also still seeing the issue on the latest Insiders build on an M1 Mac @deepak1556 👍

Version: 1.67.0-insider Commit: b84feecf9231d404a766e251f8a37c730089511b Date: 2022-04-11T05:29:24.197Z Electron: 17.4.0 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin arm64 21.4.0

[stodan]

Same here, but an additional observation: If I move the window to external display (just a regular 1080p), then the behavior is as expected (the same is true for 1.66).

Version: 1.67.0-insider Commit: b84feecf9231d404a766e251f8a37c730089511b Date: 2022-04-11T05:29:24.197Z Electron: 17.4.0 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin arm64 21.4.0

[fxck]

Don't believe it's specific to M1, I have a regular pro and have this problem.

[MariuzM]

@deepak1556 have you carried out any testing from your end, are you able to replicate?

[moritzsternemann]

The issue also still occurs for me in the Insider build on an Intel Mac.

Version: 1.67.0-insider Commit: b84feecf9231d404a766e251f8a37c730089511b Date: 2022-04-11T05:16:55.090Z Electron: 17.4.0 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.4.0

[klanchman]

If I move the window to external display (just a regular 1080p), then the behavior is as expected (the same is true for 1.66).

Interesting, I'm using a 4K external display scaled to 1440p and see the fast scrolling issue. If I set the resolution to unscaled 4K, scrolling seems to work as expected in 1.66 and 1.67.

[deepak1556]

Thanks @klanchman @stodan that might hint the underlying issue, can you also confirm the value for following vscode settings

"editor.smoothScrolling"
"window.zoomLevel"

Also, from the terminal, run the following

> system_profiler SPDisplaysDataType | grep Resolution
> /usr/libexec/PlistBuddy -c "Print DisplayAnyUserSets:0:0:UnmirroredWidth" -c "Print DisplayAnyUserSets:0:0:UnmirroredHeight" /Library/Preferences/com.apple.windowserver.plist

@MariuzM nope I was not able to repro the issue on my end so far, very likely due to the device scale factor. I will test with the information from https://github.com/microsoft/vscode/issues/146403#issuecomment-1095214093.

@alexdima with chromium 98, https://bugs.chromium.org/p/chromium/issues/detail?id=716231 ensures devicePixelRatio is affected by zoom level on macOS as well. It is very likely we need https://github.com/microsoft/vscode/commit/1d8fdcab15cda8c46c640c037777b56b1d7c08f7 to address this issue.

[stodan]

Thanks for looking into this @deepak1556. I have defaults for the config (smoothScrolling disabled, zoom 0), no noticeable changes after enabling smoothScrolling (using trackpad, no mouse).

> system_profiler SPDisplaysDataType | grep Resolution
          Resolution: 3024 x 1964 Retina
          Resolution: 1920 x 1080 (1080p FHD - Full High Definition)

I don't have the specified plist, but I guess you are looking for this:

> /usr/libexec/PlistBuddy -c "Print" /Library/Preferences/com.apple.windowserver.displays.plist
... snip ...
            Array {
                Dict {
                    UnmirrorInfo = Dict {
                        IsLink = false
                        High = 1.000000
                        OriginY = 0.000000
                        Scale = 1.000000
                        OriginX = 0.000000
                        Depth = 4
                        Wide = 1.000000
                        Rotation = 0
                        Hz = 60.000000
                    }
                    UUID = 37D8832A-2D66-02CA-B9F7-8F30A301B230
                    Rotation = 0.000000
                    CurrentInfo = Dict {
                        IsLink = false
                        High = 982.000000
                        OriginY = 0.000000
                        Scale = 2.000000
                        OriginX = 0.000000
                        Depth = 8
                        Wide = 1512.000000
                        Rotation = 0
                        Hz = 120.000000
                    }
                }
                Dict {
                    UnmirrorInfo = Dict {
                        IsLink = false
                        High = 1.000000
                        OriginY = 0.000000
                        Scale = 1.000000
                        OriginX = 0.000000
                        Depth = 4
                        Wide = 1.000000
                        Rotation = 0
                        Hz = 60.000000
                    }
                    UUID = 0DE77A5A-6133-42DC-B595-6F86F09B5D30
                    Rotation = 0.000000
                    CurrentInfo = Dict {
                        IsLink = false
                        High = 1080.000000
                        OriginY = -1080.000000
                        Scale = 1.000000
                        OriginX = -203.000000
                        Depth = 4
                        Wide = 1920.000000
                        Rotation = 0
                        Hz = 63.000000
                    }
                }
            }

Changing display preferences on built-in screen does not affect Scale, e.g.

15c15
<                         High = 982.000000
---
>                         High = 1169.000000
20c20
<                         Wide = 1512.000000
---
>                         Wide = 1800.000000

[klanchman]

@deepak1556 I've also got zoom level 0 and smooth scrolling disabled.

System profiler:

$ system_profiler SPDisplaysDataType | grep Resolution
          Resolution: 5120 x 2880 (5K/UHD+ - Ultra High Definition Plus)
          Resolution: 3456 x 2234 Retina

Plist entry for built-in MacBook monitor:

$ /usr/libexec/PlistBuddy -c "Print DisplayAnyUserSets:Configs:0:0:UnmirrorInfo:Wide" -c "Print DisplayAnyUserSets:Configs:0:0:UnmirrorInfo:High" /Library/Preferences/com.apple.windowserver.displays.plist
1728.000000
1117.000000

Plist entry for external monitor (scaled resolution like I normally use it):

$ /usr/libexec/PlistBuddy -c "Print DisplayAnyUserSets:Configs:0:1:UnmirrorInfo:Wide" -c "Print DisplayAnyUserSets:Configs:0:1:UnmirrorInfo:High" /Library/Preferences/com.apple.windowserver.displays.plist
2560.000000
1440.000000

Plist entry for external monitor (unscaled resolution):

$ /usr/libexec/PlistBuddy -c "Print DisplayAnyUserSets:Configs:0:1:UnmirrorInfo:Wide" -c "Print DisplayAnyUserSets:Configs:0:1:UnmirrorInfo:High" /Library/Preferences/com.apple.windowserver.displays.plist
3840.000000
2160.000000

[deepak1556]

@klanchman @stodan @bmalehorn can you check if the issue is better with the following build. Once you launch the application, add the setting "update.mode": "none" and continue testing. Ensure that build has following Commit info

Version: 1.67.0-insider (Universal)
Commit: 3e00fca504dce0d2d5d651da7d9e2198b7ba9118
Date: 2022-04-19T18:13:31.957Z
Electron: 17.4.0
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0

[klanchman]

@deepak1556 Unfortunately that build still seems to have the same issue for me 😓 Let me know if there's any other info I can grab to help debug!

[alexdima]

@deepak1556 The change https://github.com/microsoft/vscode/commit/1d8fdcab15cda8c46c640c037777b56b1d7c08f7 only helps when scrolling using a physical mouse wheel and configuring editor.smoothScrolling.

The background is: we have a setting called editor.smoothScrolling. When set to true, the editor will perform an animation when changing the scroll position using the keyboard (e.g. page up/page down) or when changing the scroll position using a physical mouse wheel. The classifier used there is used to detect if the scroll is done via a physical mouse wheel or via the trackpad. If the scroll is done via the physical mouse wheel, then the editor's animation should kick in, otherwise not, because it looks weird, as the trackpad usually has its own animation and us adding ours on top feels dizzy. That said, the animation itself does not affect in any way the scroll distance.

Given this issue is about the scroll distance and it reproduces without editor.smoothScrolling, I don't think those particular calls to that classifier play any role. I think that the values we receive via wheelDeltaX and wheelDeltaY might be different now.

[milosivanovic]

What's the status of this issue? Is there anything I can do to help troubleshoot and move it along?

[jakedel]

Hi,

I have a vision issue, so I use a high zoom level when editing lots of text.

The previous scroll speed was great — it matched the rest of macOS. For the past few months, this bug means it's hard to follow my code as I scroll, as it moves too fast for my zoom level.

In addition, since this bug began, scrolling is a lot choppier — especially at lower sensitivity values. I'm on an 120hz MacBook (M1 Max), but scrolling never reaches the full frame rate. This means lowering sensitivity doesn't work for me, because scrolling simply becomes more jagged and hard to follow.

I'd appreciate if a solution for this bug can be prioritized. I believe it's a major issue in the app's expected behavior for Mac users — when such a frequent interaction behaves incorrectly, and less smoothly, compared to other apps.

[Omoeba]

I can still reproduce this issue in 1.69.0. However, one interesting thing I noticed is the scrolling speed is still normal in the release notes window. Can anyone else reproduce this?

[lightbreakerD]

I can still reproduce this issue in 1.69.0. However, one interesting thing I noticed is the scrolling speed is still normal in the release notes window. Can anyone else reproduce this?

You're right, the release notes windows scrolls as smooth as before 1.66.0. The other windows scroll too fast and if I adjust the speed in settings manually to the old scrolling speed, scrolling becomes choppy and feels unnatural.

[benjamin-warner]

I picked up an old project today that I use VS code for and instantly noticed this problem myself. I'm also using M1 MacBook.

Hope this can be resolved soon, but in the meantime I thought I'd leave a tip for others encountering the problem. Setting "editor.mouseWheelScrollSensitivity": 0.3 and "editor.smoothScrolling": true helped a lot. Others hadn't mentioned smoothScrolling, but I found it was the key as the sensitivity alone didn't feel quite right. I set the sensitivity value kinda arbitrarily, so may be worth fiddling with it get it to preference.

Things feel more natural now, though I don't know how it'd be for 120hz screens users, and unfortunately, many other areas such as Settings and the file explorer still scroll too fast.

[M00N-MAN]

I have the same issue Version: 1.69.1 Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a Date: 2022-07-12T08:21:51.333Z Electron: 18.3.5 Chromium: 100.0.4896.160 Node.js: 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin x64 19.6.0

When the PY or CPP file is opened and currently being rendered in the editor tab, switching between dark+ and light+ themes (daily I'm doing it two times in the morning and evening) makes scrolling in this file tab unresponsive and laggy for a few seconds.

https://user-images.githubusercontent.com/7201157/180653725-f8bf788b-7030-4731-b8ad-798eb038c6a3.mov

In this video lack of scrolling after the second switching of the theme hadn't been captured correctly (perhaps renderer impacts on window server somehow): lack in scroll makes you feel that window/tab becomes unresponsive at all

[M00N-MAN]

btw, the issue still persists on macOS same behavior: the scrolling becomes unresponsive after switching the color theme

Version: 1.71.2 Commit: 74b1f979648cc44d385a2286793c226e611f59e7 Date: 2022-09-14T21:05:37.721Z Electron: 19.0.12 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin x64 19.6.0 Sandboxed: No

Why and how to get rid of it?

[northerneyes]

Yeah, same for me, interesting that this https://github.com/microsoft/vscode/issues/146403#issuecomment-1179845370 is indeed true:

the scrolling speed is still normal in the release notes window

Version: 1.72.2 (Universal) Commit: d045a5eda657f4d7b676dedbfa7aab8207f8a075 Date: 2022-10-12T22:16:30.254Z Electron: 19.0.17 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: No

[friendship1]

I am in the totally same situation as https://github.com/microsoft/vscode/issues/146403#issuecomment-1291208559. For now, I can solve this problem following https://github.com/microsoft/vscode/issues/146403#issuecomment-1189076955. I changed the scroll speed to 0.2 not only for editor(editor.mouseWheelScrollSensitivity) but also workbench(workbench.list.mouseWheelScrollSensitivity) and terminal(terminal.integrated.mouseWheelScrollSensitivity).

[milosivanovic]

@friendship1 is 0.2 an estimate or is that the exact same speed as when scrolling in release notes?

[friendship1]

@milosivanovic To me, empirically, in the editor window, around 0.4 seems to be the closest to a 'release note'. I just wanted to inform that scroll speed can be adjusted separately not only in editor, but also in terminal and workbench.

[h3110w0r1d-y]

M1 MacBook Pro running macOS 13

I tried use Chrome 91/95/97/98/107 to open https://vscode.dev, before chrome 98, scroll speed was normal, but when I use v98 and later, scroll speed become too fast. Same issue was append to other web editors which was using mousewheel Event to scroll.

[netique]

We've stumbled upon this behavior in RStudio, which recently has moved from Qt to Electron, effectively updating underlying Chromium to v98+ and as @h3110w0r1d-y pointed out, causing the issue (https://github.com/rstudio/rstudio/issues/11578). RStudio uses Ace (Ajax.org Cloud9 Editor) and was affected in the same way as Monaco editor used by VSC. It was solved by allowing the user to change the scroll speed multiplier, similar to VSC. However, the rest of RStudio was not affected at all. Perhaps it does not utilize mousewheel Event. AFAIK, the GUI is build on Google's GWT. In addition, there is another editor mode resembling jupyter notebook which is built, I believe, on prosemirror and it doesn't suffer from the issue. May be worth exploring.

[h3110w0r1d-y]

I have submitted this issue to Chromium.

https://bugs.chromium.org/p/chromium/issues/detail?id=1404833