Drop doesnt work on Sway

[HappyCthulhu]

Describe the bug

Hello. I switched to sway few weeks ago. Im in love with CLI-tools, that allow me to drag&drop from CLI, but im expiriencing troobles with that on Wayland. Drag window shows up, but i cant drop anything. Sometimes i can, sometimes - cant. Can u suggest some solution for me? Or, at least, tell me, how to debug it properly.

Demonstration:

183dc8a3-3ce6-411d-a4ae-3a9c540ca0e9.mp4

To reproduce

• blobdrop fp
• drag it

Expected behavior

Dragged object dropped

[vimpostor]

That looks broken, the circular animation should also only show when you drop something in blobdrop (in sink mode) rather than the other way around (Edit: That was a regression apparently).

On Wayland things are a bit tricky, but your shown workflow should still work on Wayland. Is blobdrop started in XWayland or in Wayland mode? You can force the former with QT_QPA_PLATFORM=xcb, the latter with QT_QPA_PLATFORM=wayland.
Is Google Chrome running in Wayland or XWayland mode?

Edit: Given the other two issues you opened ([0] [1]), I suspect that this is not an issue in blobdrop but rather with Chrome running in XWayland, while blobdrop is running in native Wayland mode.
If that is the case, you can either try starting Chrome in native Wayland mode, or alternatively blame the Wayland folks for still not having fixed DnD between XWayland and Wayland in 2024.

[HappyCthulhu]

Thx for your answer! Sorry, indeed, i should clarify, that that is not specific problem of blobdrop.

Indeed, Chrome was launched with XWayland (i found out that with xeyes, xorg-xwininfo, extramaus)

I did, what u told me to do. I tried to set variable with set QT_QPA_PLATFORM wayland if my fish-shell, than - launched google-chrome-stable from this shell. This approach didnt work - google-chrome-stable continued to launch via XWayland. Then, in chrome://flags, i changed Preferred Ozone platform from Default option to Wayland.

After that issue resolved. Rn blobdrop and dragon works well, dropping part is happening)

P.S. Can u remind me, is there easyfix, that will force blobdrop opened as float-window, not as regular window? Dragon opens as float from the box, but blobdrop - not.
P.S.S Lets close this issue in few days, not rn, ok? Give me some time, mb issue will reproduce again later.

[vimpostor]

is there easyfix, that will force blobdrop opened as float-window, not as regular window?

It should do that by default now with ee4eac7.
You just need to update your blobdrop version, which depends on what distro you are using I guess.

[HappyCthulhu]

It should do that by default now with ee4eac7. You just need to update your blobdrop version, which depends on what distro you are using I guess.

Thix fix didnt rly work f me. I cloned your repo, build project and it still opens as regular program, not in float mode.

My system:

[I] user@t-t14 ~> neofetch
██████████████████  ████████   user@t-t14
██████████████████  ████████   ------------
██████████████████  ████████   OS: Manjaro Linux x86_64
██████████████████  ████████   Host: 21CGS1HJ00 ThinkPad T14 Gen 3
████████            ████████   Kernel: 6.1.80-1-MANJARO
████████  ████████  ████████   Uptime: 12 hours, 57 mins
████████  ████████  ████████   Packages: 1778 (pacman), 5 (flatpak)
████████  ████████  ████████   Shell: fish 3.7.0
████████  ████████  ████████   Resolution: 3840x2160
████████  ████████  ████████   WM: sway
████████  ████████  ████████   Theme: Adapta-Nokto-Eta-Maia [GTK2/3]
████████  ████████  ████████   Icons: Papirus-Adapta-Nokto-Maia [GTK2/3]
████████  ████████  ████████   Terminal: tmux
████████  ████████  ████████   CPU: AMD Ryzen 7 PRO 6850U with Radeon Graphics (16) @ 2.700GHz
                               GPU: AMD ATI Radeon 680M
                               Memory: 8621MiB / 30849MiB

[vimpostor]

This fix didnt really work for me.

Right, it will only work on X11 window managers. This is not a problem of blobdrop, but again a Wayland problem. Unlike X11, Wayland does not have support for window types that signal to the window manager that an app wants to be in floating state, see: rust-windowing/winit#862 (comment)

Some applications use a workaround to mark them as non-resizable, which will cause Sway to skip tiling them. But I explicitly want the window to be resizable, so I will not use this workaround.

Feel free to open a Merge Request to wayland-protocols. Maybe if you have luck, it won't be bikeshed for 3 years, before being ultimately closed because one party doesn't agree with such basic features for your secure display server.

In any case, this is all going beyond the scope of the original issue (which was about attempting to drag between Wayland and XWayland windows).

[trinitronx]

[...SNIP...] and it still opens as regular program, not in float mode.

@HappyCthulhu : This is to be expected in i3 & Sway (and probably other tiling window managers), regardless of X11 or Wayland. To configure an application to open a floating window, it should be configured in the window manager.

For example with Manjaro Sway Edition, there is now a default rule for dragon-drop:

/etc/sway/config.d/98-application-defaults.conf:

for_window [app_id="dragon-drop"] floating enable, sticky enable

[vimpostor]

This is to be expected in i3 & Sway, regardless of X11 or Wayland.

No, that's simply and blatantly false, blobdrop sets the appropriate NET_WM_WINDOW_TYPE flags, so that it is considered floating by default on all EWMH-compliant X11 window managers, including i3.
No further steps are required by the user to make blobdrop floating on any X11 window manager. Wayland does not offer support for an equivalent window flag like this.

To configure an application to open a floating window, it should be configured in the window manager.

No, not only are these workarounds only necessary on Wayland, this entire mindset of "We don't have a way to map this niche usecase in our spec" and "We can't be assed to complete another three year roundtrip of spec bikeshedding that at the end will be blocked anyway by one DE objecting against features that would be considered trivial by any sane person, so we just delegate the effort to the user" is completely backwards and contraproductive for the actual enduser.

[trinitronx]

This is to be expected in i3 & Sway, regardless of X11 or Wayland.

No, that's simply and blatantly false

Perhaps to be more accurate with words: If one is using a tiling window manager... one should likely expect most windows to be tiled by default. If one desires to ensure certain windows be always floating instead, one should configure it to be so. (or use applications + EMWH-compliant display server stacks).

There's certainly some nuance to navigate between the different display servers, and the support for EWMH and other traditional X11/Xorg features especially concerning Wayland compositors.

Clearly there are strong feelings here about this... I was just trying to be helpful to the original poster who appears to be using Manjaro Sway Edition which now has the window rules mentioned above to address this issue.

Hope it helps also for those finding this issue via search engine results. 😉

[vimpostor]

If one is using a tiling window manager... one should likely expect most windows to be tiled by default. If one desires to ensure certain windows be always floating instead, one should configure it to be so.

I know this is the Wayland way, but again, this is clearly the wrong mindset. What about notifications, menu bars, systrays, overlay panels, PiP windows etc?
These are all things that should be floating by default, and "one should configure it to be so" just doesn't cut it, if your display server is unable to provide a mechanism to make applications provide a hint to be floating without user intervention.
There is the wlr-layer-shell protocol, but it is not really intended to be used by applications like this and doesn't quite work the same as floating windows anyway. Even the request for always-on-top windows got closed, because apparently people unironically think it's the same as PiP windows, which in wayland fashion is still being bikeshed to this day.

Obviously the compositor (and with that the user with manual override rules) should have the last word over whether something is floating, but there should be a mechanism for applications to tell what window type they prefer.

There's certainly some nuance to navigate between the different display servers, and the support for EWMH and other traditional X11/Xorg features especially concerning Wayland compositors.

There is not even a little bit of nuance here. It's as simple as "It works in X11. It does not work in Wayland, because it doesn't offer a mechanism for this as per usual".

I was just trying to be helpful to the original poster

That's fine and manually providing a rule for sway is a good workaround when it does not work out of the box in Wayland. Similar, I was just trying to correct your wrong assessment that this rule would also be needed for i3 (or other X11 tiling WMs), whereas in reality it just works by default there.

[trinitronx]

I know this is the Wayland way, but again, this is clearly the wrong mindset. What about notifications, menu bars, systrays, overlay panels, PiP windows etc?
These are all things that should be floating by default, and "one should configure it to be so" just doesn't cut it, if your display server is unable to provide a mechanism to make applications provide a hint to be floating without user intervention.

Just to be clear: I didn't intend to add any fuel to the infinite flamewar that is Wayland vs. Xorg. Merely adding some (hopefully) helpful info relevant to the OP's issue for people to find.

Clearly you have some opinionated preferences regarding how Xorg's been designed. That's fine... it's still not going to change the current software design of Wayland, nor prevent people from using Wayland if that is their preference to do so.

Even the request for always-on-top windows got closed, because apparently people unironically think it's the same as PiP windows, which in wayland fashion is still being bikeshed to this day.

Obviously the compositor (and with that the user with manual override rules) should have the last word over whether something is floating, but there should be a mechanism for applications to tell what window type they prefer.

While I'd agree with you on technical grounds here that it would be nice if applications could express preferences regarding things like floating windows, etc...

As I'm sure we both know, these things are being discussed and worked out, and will likely continue to be worked out for years. It's not my place to criticize or defend those design decisions, nor do I want to participate in the flamewar or discuss future Wayland-related protocol or compositor designs. I only intend provide a sort of analysis of how things are working today and what users can do to work around some common issues such as this one.