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

[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.

[nickdiego]

Could someone confirm if this does still repro with the most recent electron version? I've just learned that obsidian pane/tab dnd got fixed after upgrading it to 1.7.5 electron 32 (using Arch package), so I wonder if that works for vscode as well.

If not, I'd suggest filing an upstream bug at https://issues.chromium.org/new and cc me on it ([email protected]). Thanks

[Bryan2333]

@nickdiego I am using code oss from Arch Linux repo, and I can confirm that this issue still exists.

[carwyn]

@nickdiego still happening on Fedora 41 with the Microsoft RPM. My workaround is to start without the ozone flags (i.e. use X11), drag my panes around, then restart with the flags. Without using ozone on a fractionally scaled display the X11 rendering produces blurry fonts.

[nickdiego]

@nickdiego I am using code oss from Arch Linux repo, and I can confirm that this issue still exists.

The latest version seems broken, I'm getting this crash (bt bellow) when clicking on the main window:

#5  0x000059f995d82873 in logging::NotReachedError::~NotReachedError() ()
#6  0x000059f995d829dd in logging::NotReachedError::TriggerNotReached() ()
#7  0x000059f996d75884 in ui::Accelerator::ApplyLongFormModifiers(std::__Cr::basic_string<char16_t, std::__Cr::char_traits<char16_t>, std::__Cr::allocator<char16_t> > const&) const ()
#8  0x000059f996d75562 in ui::Accelerator::GetShortcutText() const ()
#9  0x000059f9979890ca in views::MenuConfig::ShouldShowAcceleratorText(views::MenuItemView const*, std::__Cr::basic_string<char16_t, std::__Cr::char_traits<char16_t>, std::__Cr::allocator<char16_t> >*) const ()
#10 0x000059f997979c29 in views::MenuItemView::CalculateDimensions() const ()
#11 0x000059f9979797fa in views::MenuItemView::GetDimensions() const ()
...

(which means electron 32 needs to be updated, specifically it lacks this chromium patch).

@nickdiego still happening on Fedora 41 with the Microsoft RPM. My workaround is to start without the ozone flags (i.e. use X11), drag my panes around, then restart with the flags.

I've just tested on my local Arch box with latest official vscode 1.95.1 (using @visual-studio-code-bin AUR) on both Gnome Shell 47 and Sway 1.10 and see no issue. At least when reordering and rearranging tabs into new panels, etc, as can be seen in the attached screencast.

Screencast.From.2024-11-06.15-17-22.mp4

[xmatthias]

@nickdiego similar setup - arch on KDE with wayland, using the visual-studio-code-bin from AUR 1.95.1.

Unfortunately, reordering tabs worked since quite a while - what doesn't work is reordering the side-pane buttons (files / vsc / ...), or reordering the tabs in the bottom menu (e.g. switch terminal and debug console around).

It's not crashing immediately - but does core-dump and "hangs" (no further ui interaction possible) until i kill the code instance.

[vially]

Most of the dragging operations seem to work. However, one thing that seems to consistently fail is dragging an item from the main activity bar to the right sidebar.

2024-11-06.mp4

[xmatthias]

@vially can you try reordering the items in the activity bar (instead of dropping them to the right sidebar) ? (that's what's failing me ... and bothering me the most)

[vially]

@xmatthias Nope, reordering items in the activity bar does not seem to work either.

reorder-items.mp4

[nickdiego]

Oh, ok. Thanks all for clarifying!

I can reproduce it even with https://vscode.dev using chrome's wayland backend, which is rather not reproducible with the X11 backend (even through XWayland). That likely indicates an upstream chromium issue. I'll look into it!

[nickdiego]

OK, I've figured out the root issue: It seems no data/type is being set for those draggable items, as explained in [1], which leads to no mime types being offered and accepted at Wayland protocol level. As can be seen in this wayland debug log excerpt (collected upon drop event):

[...]
[1676869.941]  -> wl_data_offer#4278190082.set_actions(2, 2)
[1676886.644] wl_data_device#21.motion(4822119, 1276.84765625, 325.04687500)
[1676886.989]  -> wl_data_offer#4278190082.set_actions(2, 2)
[1676902.653] wl_data_device#21.motion(4822133, 1277.42187500, 325.04687500)
[1676902.896]  -> wl_data_offer#4278190082.set_actions(2, 2)
[1677506.020] wl_data_source#45.cancelled()
[1677507.245]  -> wl_data_source#45.destroy()
[1677507.264]  -> wl_data_offer#4278190082.destroy()
[...]

That leads to the dnd session to fail (cancelled) which is why the visual item does not get moved. Quoted below is what the Wayland protocol says about it:

For objects of version 3 or newer, this request determines the final result of the drag-and-drop operation. If the end result is that no mime types were accepted, the drag-and-drop operation will be cancelled and the corresponding drag source will receive wl_data_source.cancelled. Clients may still use this event in conjunction with wl_data_source.action for feedback.

Further context at https://wayland.app/protocols/wayland#wl_data_offer:request:accept

Thus, it must be fixed at app level (ie: vscode), by associating data and type to those draggable items.

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API#the_basics

[nickdiego]

After digging into it a bit more and considering that W3C dnd spec does not mandate drag data to be necessarily assigned by the application, I believe that's something we must address at chromium level. It's being tracked under https://issues.chromium.org/377760837. The wip fix is under review here and will hopefully land soon. thanks

[nickdiego]

The fix has landed upstream chromium yesterday and started shipping in version 132.0.6826.0 (canary channel). Please test and report back, I didn't test it on KDE, for example. Feel free to ping me over mail or matrix if needed. thanks!

[deepak1556]

@nickdiego thanks a lot for taking the time to investigate and address this issue! I will test change in Electron and backport it to our release lines.

EDIT: verified the fix and backported at electron/electron#44753

[joshspicer]

Tested on a Framework 13 laptop, NixOS with Plasma (wayland) desktop. I launched insiders with --enable-features=UseOzonePlatform --ozone-platform=wayland and was able to drag around tabs and see the animation.