[X11/KDE] Drag and drop of multiple files, only one file show up
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: moninsergei, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0
Steps to reproduce:
Until the last time, the drag and drop functionality worked just fine. The bug started to appear in firefox 128 (I think?), when I open dolphin file explorer (kubuntu 22.04, KDE plasma) and drag multiple files into drag and drop area, only one file appears. Try for yourself --> https://jsfiddle.net/9C2EF/ Select multiple files and drag into area. I tried in: firefox 128, firefox 130, also in private mode. Bug still appears. I tested in google chrome, everything works just fine.
Actual results:
Only one file appears in event.dataTransfer.files (I dragged 5 files)
Expected results:
Should be an array of files
Hmm, I tested in GNOME file explorer, everything works just fine. It looks like that the bug only appears in KDE/Dolphin 🙄
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•1 year ago
•
|
||
I can reproduce the issue on Nightly130.a1, Firefox128.0 kubuntu22.04 KDE plasma 5.24.7.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=936287e7cba7e0a07179c59e7c9c74adaefdb47c&tochange=68955533eb96b6d019d77be1ec753b353827d5d0
(If I use Nemo or pcmanfm instead of Dolphin file manager, the the drag drop works as expected.)
Comment 4•1 year ago
|
||
:stransky, since you are the author of the regressor, bug 1881229, could you take a look?
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Sounds like newer versions of Dolphin may have fixed this already. Do we have any contacts for getting this backported into 22.04 like the upstream bug suggests?
Comment 6•1 year ago
|
||
I think Alexandre is more involved with Canonical and he would know?
Comment 7•1 year ago
|
||
I don't think canonical manages kubuntu ?
Comment 8•1 year ago
|
||
Set release status flags based on info from the regressing bug 1881229
Updated•1 year ago
|
Comment 9•1 year ago
|
||
This happens to me also, using Arch Linux, firefox version 129.0-1 and Dolphin 24.05.2
so I don't think it's been fixed yet.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
We now have reports on other distros (ArchLinux, Debian)
Comment 13•1 year ago
|
||
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
Also I manually test FF nightly builds from https://ftp.mozilla.org/pub/firefox/nightly/2024/05/ and found point of bug first appears:
- firefox-128.0a1.en-US.linux-x86_64-2024-05-14-09-50-49 (dropped all items)
- firefox-128.0a1.en-US.linux-x86_64-2024-05-15-03-23-56 (dropped only first item)
- firefox-128.0a1.en-US.linux-x86_64-2024-05-17-21-53-59 (not dropped at all)
- firefox-128.0a1.en-US.linux-x86_64-2024-05-21-09-45-53 (not dropped at all)
- firefox-128.0a1.en-US.linux-x86_64-2024-05-31-21-30-29 (dropped only first item)
Comment 16•1 year ago
|
||
(In reply to aakumykov from comment #15)
Test case is https://dragdrop.com/test
Comment 17•1 year ago
|
||
Comment 18•1 year ago
|
||
Mozregression from good point 2024-05-01 result (full log is attached also):
6:11.62 INFO: Narrowed integration regression window from [936287e7, a1cad969] (3 builds) to [936287e7, 68955533] (2 builds) (~1 steps left)
6:11.62 INFO: No more integration revisions, bisection finished.
6:11.62 INFO: Last good revision: 936287e7cba7e0a07179c59e7c9c74adaefdb47c
6:11.62 INFO: First bad revision: 68955533eb96b6d019d77be1ec753b353827d5d0
6:11.62 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=936287e7cba7e0a07179c59e7c9c74adaefdb47c&tochange=68955533eb96b6d019d77be1ec753b353827d5d0
Comment 19•1 year ago
|
||
That's the same regressor which was already identified in this bug
Comment 20•1 year ago
|
||
Hello,
I confirm this.
Kubuntu Desktop running KDE with Dolphin and Firefox. Installed Thunar for test purposes.
Dragging multiple files into Firefox browser window from Thunar marks all files for upload.
Dragging multiple files into Firefox browser window from Dolphin only marks one file for upload.
I need this to work properly as I am using drag and drop almost daily...
Updated•1 year ago
|
| Assignee | ||
Comment 25•1 year ago
|
||
I do see that now. It's a bug in processing text/x-moz-url MIME type, we rear only first item from the list.
| Assignee | ||
Comment 26•1 year ago
|
||
The problem here is that Dolphin sends us only one file as text/x-moz-url but posts complete list as text/plain.
It's interesting that it affects X11 Plasma session only - if I run Dolphin under GNOME/XWayland it works.
Only issue is with X11/Plasma.
| Assignee | ||
Comment 27•1 year ago
|
||
Regression from Bug 1881229 causes that we don't try to get URI list from text/plain any more. That was a hack and I don't want to introduce it again. Let's see if we can use text/uri-list as first choice. I see dolphin supports:
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor text/uri-list
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor text/x-moz-url
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor text/plain
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor application/x-kde4-urilist
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor application/vnd.portal.filetransfer
[Parent 48324: Main Thread]: D/WidgetDrag [D 1][7f0aa0065100] adding drag context available flavor application/x-kde-source-id
so let's see if we can use something from it.
| Assignee | ||
Comment 28•1 year ago
|
||
Try to get text/uri-list first and then fallback to text/x-moz-url.
text/x-moz-url MIME tends to be poorly supported by third party apps,
we got only one file instead of file list or nothing at all.
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 29•1 year ago
|
||
As a simple fix we may uplift it to beta.
Comment 30•1 year ago
|
||
Comment 31•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
Comment 34•1 year ago
|
||
Do we need this on ESR128? Please nominate if so - it grafts cleanly.
| Assignee | ||
Comment 35•1 year ago
|
||
I'd need to test that on ESR first, not sure if we need another patch for it.
| Assignee | ||
Comment 36•1 year ago
|
||
Comment on attachment 9441772 [details]
Bug 1908196 [Linux] Drag&Drop - try to get text/uri-list first and convert it to text/x-moz-url r?emilio
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixed D&D file operation on multiple targets.
- User impact if declined: D&D for more than one file may fail.
- Fix Landed on Version: 135
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Updates order of MIME formats request, ask for wide supported format first.
| Assignee | ||
Comment 37•1 year ago
|
||
Tested the patch on ESR128 and it works as expected.
Comment 38•1 year ago
|
||
Comment on attachment 9441772 [details]
Bug 1908196 [Linux] Drag&Drop - try to get text/uri-list first and convert it to text/x-moz-url r?emilio
Approved for 128.7esr.
Updated•1 year ago
|
Comment 39•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Description
•