Repository navigation
[Bug]: Drag'n'drop oddities #672
Description
Before reporting
- I'm on the latest release and the issue still happens.
- I searched existing issues and didn't find a duplicate.
What happened?
This might be me not knowing exactly what is expected, but I am having problems opening a new song by drag'n'drop.
When I drag an audio file and drop it into the input box at the top left of Stemdeck, and click 'Process, it gives the error - Failed to start job: URL must use http or https
When I drag the file elsewhere on the interface, it changes the whole interface screen to a simple player and plays the song. To get back to the main GUI I need to right click and choose back.
I can correctly load a file for splitting using the button at the end of the input box however
Steps to reproduce
In linux, open Stemdeck, open system file browser (Nemo). Drag'n'drop a file onto the Stemdeck interface
Operating system
Linux
StemDeck version
0.17.2
How did you install it?
Linux tar.gz
Logs / screenshots
Activity
thcp commentedon Sep 23, 2026
Thanks for this, and for separating the two behaviours. They have different answers.
The first one is already fixed and waiting on a release. Dropping a file into the box and then pressing Process gave "URL must use http or https" because the box was left holding the file's name, and that button submits whatever is in the box as a link. A filename is not a link, so it failed exactly as you saw. The box no longer holds anything that cannot be fetched, and the button acts on the track rather than on the box. That is merged and goes out in the next release.
The second one is a live bug, and your report is the first I have seen of it. A file dropped anywhere in the window should be caught and treated as a drop on the import box, precisely so the window never turns into the bare media player you had to right click out of. That guard has been in since before the version you are on, so something on your setup is getting past it. That is the part I want to chase.
Three things would help me find it, whenever you have a moment:
In the meantime the button at the end of the box is the reliable way in, as you found.
One thing worth saying plainly: you have opened several of these now and they have been consistently useful, including the one that turned out to be old recordings rather than StemDeck. Please keep going.
heyup1234 commentedon Sep 23, 2026
It seems to open the player no matter where I drop it outside the input box.
Yes, it pays the file dropped.
I am using Linux Mint, with Cinnamon desktop (most common standard setup I believe). I tried three different file managers - all produce the same behaviour.
thcp commentedon Sep 23, 2026
Thanks for checking all three file managers and confirming it plays the dropped file. That narrowed it down fast, and I was able to reproduce both behaviours with a real drag on Linux.
It turns out both are one bug, which also changes what I said earlier. The box problem is not fixed by the change I mentioned before. It has the same cause as the player.
On Linux, the app's web view never tells the page that a drag carries a file. It describes it as a link. The drop handling only acts on files, so it stepped aside and the web view did its own default thing. Over most of the window that means opening the file, which is the bare player you saw. Over the box it means typing the file's location into it as text, and Process then tried to use that as a web address. Windows and macOS describe the drag as a file, which is why it only happens on Linux.
The fix is in #680. On Linux the app now catches the drop itself and hands the file to the same place the button does. A file dropped anywhere in the window, including on the box, loads just like one picked with the button, and nothing opens in the window anymore. Dragging tracks around inside the library is unaffected.
It will be in the next release. Until then the button remains the way in. Let me know how it behaves once you have it.
Take file drops on Linux in the shell, where the WebView cannot see t…
thcp commentedon Sep 23, 2026
The fix is merged, and I tested it successfully on Linux with real drags from a file manager into the app. A file dropped anywhere in the window, including on the box, now loads just like one picked with the button. Nothing opens in the window anymore, and dragging tracks around inside the library still works as before.
It goes out with the next release. Thanks again for the careful reports. Let me know how it behaves on your setup once you have it.
heyup1234 commentedon Sep 24, 2026
All working well now. Drag'n'drop anywhere populates the input box and pressing the button splits them out with no errors.
Thanks !!