Drag and drop does not work in Wayland

[paarthtandon]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.69.2
• OS Version: Manjaro Linux, Kernel: 5.15, Wayland, WM: sway

Steps to Reproduce:

1. Add --enable-features=UseOzonePlatform --ozone-platform=wayland to code-flags.conf
2. Open code
3. Attempt to drag tabs, files, or anything else
4. Does not give any indication that they are being dragged, and the elements to not get moved around

I am unable to re-order windows, create multiple panes with drag and drop, etc

It works if I do not add the flags. The issue is I need the flags for scaling in Wayland.

[pwohlhart]

I'm seeing the same (no drag&drop of any elements) on https://vscode.dev/ running in Chrome 103.0.5060.134 with Preferred Ozone platform set to wayland (same reason, need it for scaling).

[ozls]

Same. I am using Linux+sway and I am having the exact same issue since 1.69. I can reorder tabs without any problem after downgrading to 1.68. Related issue: #83568

[cartok]

I thought it must relate to #154693, labeled as insiders-released on AUR at least the insiders version is out of date though, so I could not test it yet.

[ozls]

It's clearly related to the switch to electron18 in the last versions, using the latest release but switching the electron binary to electron17 works just fine for me

[a-stewart]

It also effects vscode.dev which runs in the browser rather than electron? So I guess it is an issue with newer versions of Chromium.

[cartok]

It's clearly related to the switch to electron18 in the last versions, using the latest release but switching the electron binary to electron17 works just fine for me

Can you briefly explain how you run it with electron17? I tried to just set the version to latest 17 in the package.json but the build failed.

[vially]

For what it's worth, I can also reproduce this bug (on sway) but only when the title bar style setting is set to native. When using the custom title bar, drag-and-drop seems to work as expected.

[paarthtandon]

For what it's worth, I can also reproduce this bug (on sway) but only when the title bar style setting is set to native. When using the custom title bar, drag-and-drop seems to work as expected.

Thank you very much this solved my problem!

[lunar-natalie]

+1 on this issue. Although @vially's workaround works, it would be great if native title bars could be fixed as it's not ideal to have to work around this in a WM configured without title bars.

• VS Code Version: 1.70.1
• OS: Arch Linux
  • Kernel version: 5.18.6
  • Display protocol: Wayland
  • Window manager: Sway

[locture]

+1 on this. Drag-n-drop a file into vscode is currently a hit or miss on my machine. Sometimes it works, sometimes it gives out no response, sometimes it gives out a file not found error.

VS Code Version: 1.70.2
OS: Fedora 36
Kernel version: 5.18.17-200
Display protocol: Wayland
Window manager: GDM

[weedz]

It's clearly related to the switch to electron18 in the last versions, using the latest release but switching the electron binary to electron17 works just fine for me

Can you briefly explain how you run it with electron17? I tried to just set the version to latest 17 in the package.json but the build failed.

Using an electron binary (electron20 from official archlinux repository) i tried

electron /opt/visual-studio-code/resources/app

and it launched VSCode (with a few errors regarding native modules not compiled against NODE_MODULE_VERSION 107).

Runs successfully under wayland and drag-and-drop seems to work.

But app_id is set to "Electron". I found app.setDesktopName(string) which, when tested in a small electron app, sets the app_id to the provided string. I do not know if vscode with electron@19+ will fix this but this may be a viable solution to #154693 ?

[matejcik]

For me with the official build, drag&drop works mostly fine, except for certain operations.

Drag & drop selection = OK
Moving tabs around = OK
Creating split views from drag&drop = OK
Reordering sidebar tabs = fail
Moving to secondary sidebar = fail

[hiboudev]

Same on Manjaro Gnome 45.2. 18 months and it's still not fixed, a joke.

[ColonelPhantom]

I'm also seeing an issue like this with Plasma 6 RC2 on Wayland. Running vscode on XWayland does seem to work, but has other issues (like rendering glitches). A few things like text do work, but I can't drag a tab.

When I try, VSCode acts like it's working (you get the 'shine' that indicates the tab will get tiled, for example). But when I release my mouse, nothing happens.

The about window has the following:

Version: 1.86.2
Commit: 903b1e9d8990623e3d7da1df3d33db3e42d80eda
Date: 2024-02-13T19:41:37.860Z
Electron: 27.2.3
ElectronBuildId: 26908389
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Linux x64 6.6.13-gentoo-dist

[philippcou]

Having the same Problem on Plasma 6.0

Version: 1.86.2
Commit: 903b1e9
Date: 2024-02-13T19:41:37.860Z
Electron: 27.2.3
ElectronBuildId: 26908389
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Linux x64 6.7.7

I can drag Stuff, but when releasing (for example having 2 files side by side) nothing happens.

[ulrichSchreiner]

FYI: the same happens when i have a file .config/chrome-flags.conf with content

--enable-features=UseOzonePlatform --ozone-platform=wayland

and starting the chrome browser. the browser now runs native wayland and i cannot drag/drop any links inside chrome. removing the settings moves chrome back to x11 and drag/drop works again.

[phisch]

Revisited this today, I see dnd operation to work fine with latest insiders based on Electron 27 under Ubuntu 22.04 and Gnome 42.9. Can others confirm as well.

@deepak1556 I am pretty sure you opened vscode as xwayland client, rather than a native wayland client while testing and confirming that it works.

Yes, it works as an x11 client, but this issue is about drag/drop for the wayland client.

Please make sure your vscode is properly closed, and then open it using code --ozone-platform-hint=auto. Validate if you are indeed looking at a native wayland client by either running xprop or xwininfo and hovering your mouse over your vscode and clicking. If the cursor changes to a crosshair and clicking prints window intormation, it is still an x11 (xwayland) window. If it stays the default cursor and clicking it doesn't print any output, then it is a proper wayland client.

And once you made sure it is a wayland client, re-test drag and dropping a panel from the left to the right side.

edit: I am saying this because I just had someone on gnome test this with a wayland client, and drag and drop does not work for them.

[Igorgro]

The same issue on KDE 6 Wayland. Setting --enable-features=WaylandWindowDecorations or changing "window.titleBarStyle" doesn't help

[RafalDardzinski]

I can confirm the same. KDE Plasma 6 on Wayland, Electron v27.3.5.

[ulrichSchreiner]

FYI: there is a issue in KDE's bugzilla which i think is the same problem.

https://bugs.kde.org/show_bug.cgi?id=482142

so i think this is not really a VSCode problem (at least when using plasma6).

[NoTuxNoBux]

I am pretty sure you opened vscode as xwayland client, rather than a native wayland client while testing and confirming that it works.

Just in case there is any doubt: I'm using the Wayland version of Visual Studio Code (verified through looking glass) in GNOME 45.4 and it's also a problem for me.

I can't drag and drop docks around nor reorder cells in notebooks because of this.

[ulrichSchreiner]

FYI: Today i got updates for my system (Arch), now i have plasma 6.0.2 and also new vscode, and now drag/drop works with wayland

[phisch]

FYI: Today i got updates for my system (Arch), now i have plasma 6.0.2 and also new vscode, and now drag/drop works with wayland

@ulrichSchreiner did you test dragging a panel from one side to the other? Because that still doesn't work on my arch:

2024-03-14.11-27-45.mp4

[ulrichSchreiner]

@phisch you're right. i only tested drag/drop of files/editors, not drag/drop of panels. this still does not work in pure wayland, only as X11 window.

[agurenko]

FYI: Today i got updates for my system (Arch), now i have plasma 6.0.2 and also new vscode, and now drag/drop works with wayland

@ulrichSchreiner did you test dragging a panel from one side to the other? Because that still doesn't work on my arch:
2024-03-14.11-27-45.mp4

I've just tried it on my system and it works fine. I'm KDE Plasma 6.0.2 and Code running as a Wayland (with --enable-features=UseOzonePlatform --ozone-platform=wayland)

Screencast_20240314_125634.webm

[ulrichSchreiner]

the real funny part: it works for me too when i drag the view outside of vscode, move it over my desktop and then drop it to the right (or left).
Screencast_20240314_131952.webm

[ColonelPhantom]

I can confirm what is being said above. I found https://invent.kde.org/plasma/kwin/-/commit/61f65ce98d5dd0e8956a06f9f5f88a1aa0592f5f in the changelog for Plasma 6.0.2, which I believe could possibly be related.

[sandr01d]

I found https://invent.kde.org/plasma/kwin/-/commit/61f65ce98d5dd0e8956a06f9f5f88a1aa0592f5f in the changelog for Plasma 6.0.2, which I believe could possibly be related.

Does not seem to be a workaround from Plasma, it started working on Sway for me as well.

[caleb-allen]

the real funny part: it works for me too when i drag the view outside of vscode, move it over my desktop and then drop it to the right (or left). Screencast_20240314_131952.webm

I was hoping this would also work with sway but it does not; my current workaround is to launch vscode as an X11 application, making the panel drag & drop changes I want, closing vscode and re-opening it with the wayland flags re-enabled

[RLC92]

Seeing this struggle on Wayland using Hyprland as well, took a lot of time to figure out why this was happening, but toggling the flags does enable X11 and allow me to move things (admittedly the text is unreadable on X11).

[7jrxt42BxFZo4iAnN4CX]

the real funny part: it works for me too when i drag the view outside of vscode, move it over my desktop and then drop it to the right (or left). Screencast_20240314_131952.webm

It works

vscode 1.90.0 --enable-features=UseOzonePlatform --ozone-platform=wayland
+custom title bar
plasmashell 6.0.5

Edit: It only works if you carry it over the desktop, if you carry it through a window, for example firefox, then no

[stlaz]

This issue is tagged as upstream but is there an actual electron/chromium/wlroots bug that tracks it? Or is the breaking component unclear?

[phisch]

I just wanted to report, that after switching from sway to niri, drag and drop seems to work flawlessly:

1723641563.mp4

So this might be related to sway.

[matthewwardrop]

@phisch are you 100% sure it is not running under Xwayland? It doesn't even work under GNOME for me, do it's a bit surprising it would work under a smaller compositor?

[phisch]

@phisch are you 100% sure it is not running under Xwayland? It doesn't even work under GNOME for me, do it's a bit surprising it would work under a smaller compositor?

Yes, I am 100% sure. Just double checked, it is a native wayland client. I also would have noticed because I recorded that on a system with fractional scaling, and if it was an X11 client, it would be blurry. Works flawlessly on niri (smithay based wayland compositor).

[matthewwardrop]

@phisch Thanks! Just confirmed too. niri definitely works, but GNOME, Sway, and Hyprland do not. Maybe there is some interaction with a wayland protocol extension or something...

[heinwol]

the real funny part: it works for me too when i drag the view outside of vscode, move it over my desktop and then drop it to the right (or left). Screencast_20240314_131952.webm

@ulrichSchreiner, thanks for the workaround, lol. The only way to get things moving right now I guess...

`inxi -SG`:

System:
  Host: P429-nixos Kernel: 6.10.3 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.1.4 Distro: NixOS 24.11 (Vicuna)
Graphics:
  Device-1: Intel Alder Lake-P GT1 [UHD Graphics] driver: i915 v: kernel
  Device-2: Generic Integrated Camera driver: uvcvideo type: USB
  Display: wayland server: X.org v: 1.21.1.13 with: Xwayland v: 24.1.2
    compositor: kwin_wayland driver: gpu: i915 resolution: 2240x1400~60Hz
  API: Vulkan v: 1.3.283 drivers: N/A surfaces: xcb,xlib,wayland
  API: EGL Message: EGL data requires eglinfo. Check --recommends.

[FireWolves]

Currently, I'm using Arch Linux with Sway, and I've discovered that the bug only occurs when VSCode is running in native Wayland mode (rather than XWayland). I came up with a stupid but rather simplistic workaround:

1. Preparation:

   • Locate the configuration file, usually found at ~/.config/code-flags.conf.
   • Back up the contents of this file in case you need to restore it later.

2. Remove Startup Options:

   • Remove all startup options for VSCode (e.g., --ozone-platform-hint=auto) to force it to run under the X window system.

3. Launch VSCode:

   • Start VSCode, and you will find that all functionalities work correctly (except for some flickering with the input method).

4. Adjust the Layout:

   • Adjust VSCode to your desired layout.

5. Close VSCode and Restore Startup Options:

   • Close VSCode.
   • Restore the previously backed-up startup options.

6. Verify the Effect:

   • Since VSCode remembers the previous layout by default, the outline pane will appear in the auxiliary sidebar.

7. Repeat the Steps:

   • If you need to modify the layout or adjust it again, you can repeat the above steps.

[unlsycn]

Currently, I'm using Arch Linux with Sway, and I've discovered that the bug only occurs when VSCode is running in native Wayland mode (rather than XWayland). I came up with a stupid but rather simplistic workaround:

1. Preparation:

   • Locate the configuration file, usually found at ~/.config/code-flags.conf.
   • Back up the contents of this file in case you need to restore it later.

2. Remove Startup Options:

   • Remove all startup options for VSCode (e.g., --ozone-platform-hint=auto) to force it to run under the X window system.

3. Launch VSCode:

   • Start VSCode, and you will find that all functionalities work correctly (except for some flickering with the input method).

4. Adjust the Layout:

   • Adjust VSCode to your desired layout.

5. Close VSCode and Restore Startup Options:

   • Close VSCode.
   • Restore the previously backed-up startup options.

6. Verify the Effect:

   • Since VSCode remembers the previous layout by default, the outline pane will appear in the auxiliary sidebar.

7. Repeat the Steps:

   • If you need to modify the layout or adjust it again, you can repeat the above steps.

You can directly run the original VSCode executable instead of the wrapper script provided by Arch to run VSCode without arguments.