Pane resize handle feels too small Linux, Electron fails to update mouse cursor

[shew82]

On vscode v1.28.2 (and presumably other versions) there is a very small region to "grab" a pane separate in order to resize the pane (e.g. make integrated terminal smaller, etc). This can make resizing panes very difficult.
resize handle is hard to grab.mkv.zip

Commit: 7f3ce96
Date: 2018-10-17T00:20:56.183Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64
OS: Ubuntu 18.04

[isidorn]

@shew82 Thanks for the video.
@joaomoreno We could increase the default size of the sash to be +1 px.
Not sure how smart it would be to always do that, or we should do it per monitor - does elecetron give us some API so we could figure this out?

[joaomoreno]

Yeah I often hit this too. We currently use 4px for sashes: https://github.com/Microsoft/vscode/blob/master/src/vs/base/browser/ui/sash/sash.css#L19

@isidorn Careful when updating that, there's other measurements on that file which depend on those 4px, so adjustments would need to be made. One idea to improve here would be to use CSS variables and math, or just move everything to JS.

[isidorn]

@joaomoreno ack. Let's put it to on-deck and debt and when we have time we can tackle it.
Would you go up to 6px, or based on monitor?

[joaomoreno]

You know... there's also another issue: Electron on Linux is pretty bad at updating the mouse cursor, especially in high DPI, known issue. So, often it seems that the cursor isn't over the sash (cause the cursor type doesn't change) when in fact pressing down and dragging would actually resize it.

@shew82 Can you confirm this?

[dwelle]

@joaomoreno sometimes happens to me, too (windows 7), but even when not, the sash is too narrow for my liking.

WTBS, couldn't vscode do something like chrome devtools?

(the area highlighted in yellow can be dragged to resize → i.e. if there's no button, the whole header acts as a handle)

There's a lot of space for vscode's terminal to do the same:

[shew82]

You know... there's also another issue: Electron on Linux is pretty bad at updating the mouse cursor, especially in high DPI, known issue. So, often it seems that the cursor isn't over the sash (cause the cursor type doesn't change) when in fact pressing down and dragging would actually resize it.

@shew82 Can you confirm this?

In the video I attached, this actually happens between the 5 and 10 second mark - the pane is resized while the cursor remains an arrow.

[joaomoreno]

WTBS, couldn't vscode do something like chrome devtools?

Yeah I really like how devtools does that, we could try something like that, what do you think @isidorn?

In the video I attached, this actually happens between the 5 and 10 second mark - the pane is resized while the cursor remains an arrow.

Yeah... it's a sad bug. We should actually check whether Electron 3 fixes it.

[isidorn]

Yeah, that is a neat idea.
The only downside is that I am not sure we can do this in other places where we use sashes, but looks like an elegant solution for panels.
Should we also do this for viewlet title area to be dragged left / right? Might work imho

[IgorKrupenja]

I can also reproduce this with with an experimental Electron 3 build. Behaviour is the same basically: the cursor does not change on hovering over the sash but pressing LMB down and dragging would actually resize the pane.

Ubuntu 18.10, GNOME, default cursor theme, scaling set to a factor of 1.5 using xrandr.

VSCode:

Version: 1.30.0-exploration
Commit: 790b0c90a8967f39130084d0bf8e4e299b559413
Date: 2018-11-27T07:36:43.428Z
Electron: 3.0.10
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.18.0-11-generic

[QbicFox]

Same issue here, I'm using ubuntu 18.10 with 200% scaling factor and 3200 * 1800 resolution.

Except small pane resize handle, mouse cursor does not change properly to text in some part of editor.

Version: 1.31.0-exploration
Commit: c6b2329
Date: 2018-12-21T08:38:10.793Z
Electron: 4.0.0
Chrome: 69.0.3497.106
Node.js: 10.11.0
V8: 6.9.427.24-electron.0
OS: Linux x64 4.18.0-13-generic

[SvenTo]

You know... there's also another issue: Electron on Linux is pretty bad at updating the mouse cursor, especially in high DPI, known issue. So, often it seems that the cursor isn't over the sash (cause the cursor type doesn't change) when in fact pressing down and dragging would actually resize it.

@joaomoreno I can confirm this on 200% scaling factor: It is the cursor issue, not the size. I increased the size of the sash to 40px and even that "feels hard to grab." I've made a little demo with the Developer Tools, which shows the problem pretty clear:
demo-2019-01-10_20.03.56.zip

I think it could make sense to increase the size of the sash to 6px. Here is a screenshot with 4px (vertical) and 6px (horizontal):

Version: 1.30.2
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:49:48.319Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Linux x64 4.20.0-arch1-1-ARCH

[mikeseese]

Very curious if there would be a common solution to both this and #65294 where high DPI Linux screens will only render the text cursor on the top left corner of the window within the editor

[mirao]

I have the same issue with:

• VSCode 1.30.2
• Ubuntu 18.10
• HP Envy Skylake 13.3" 3200x1800, with 200% scale in display settings.

Very hard to catch right position of mouse cursor in edge between windows.

[isidorn]

fyi @sbatten since you are looking into panel layout these days

[paleo]

Same issue issue on Xubuntu 18.04 (XFCE) and VSCode 1.30.2 with a HiDPI display.

[tomsihap]

Same issue here https://imgur.com/a/Z8SbOsb

Version: 1.30.2
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:49:48.319Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Linux x64 4.18.0-13-generic

Resolution: 3200x1800px
Scale: 200%

[QbicFox]

In full screen mode everything is ok.

[paleo]

In full screen mode everything is ok.

That's right, for me too.

[Akiyamka]

Look like cursor not changing even you under right position
https://www.useloom.com/share/4a2ca406c6604a12be1e094c534c3825

Manjaro Linux x86_64 - 4.19.20-1-MANJARO
Resolution: 3840x2160
DE: GNOME 3.30.2

[QbicFox]

Seems this issue depends on custom title bar functionality ...
If you change title bar style to native in vscode settings you can see everything works as it should.

[hwinkler]

Seems this issue depends on custom title bar functionality ...
If you change title bar style to native in vscode settings you can see everything works as it should

I confirm this. Maybe VS Code ought not suggest this when you start up native title bar:
"If you experience hard to read text in the menu bar, we recommend trying out the custom title bar."

[sbatten]

@hwinkler With the next release, that notification will disappear https://code.visualstudio.com/docs/setup/linux#_using-the-custom-title-bar

[mirao]

OK, the issue is mentioned in VScode docs.

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!