Closed Bug 1567505 Opened 4 years ago Closed 3 years ago

[wayland] drag and drop multiple files into google drive doesn't work

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
69 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla79
Tracking Flags:
Tracking Status
firefox79 --- fixed

People

(Reporter: luis.pabon, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1567505 [Wayland] Implement uri-list drop target on Wayland, r?jhorak
47 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

  • Load up a sway session
  • Open firefox in wayland mode
  • Load up google drive
  • Open nautilus
  • Drag and drop 2 or more files into google drive

Actual results:

Only the first file on the drag and drop selection is uploaded

Expected results:

All files are uploaded.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: wayland-sway
Priority: -- → P3

I can confirm the bug is not specific to Google Drive. When dragging more than one file, only the first one is picked up.

You can test this easily here: https://www.dropzonejs.com/

Moved to wayland tracker as it's not sway specific.

I think it's related to https://gitlab.gnome.org/GNOME/mutter/-/issues/1250
When this update hits mutter we may remove the custom D&D code we have in Firefox.
Robert, do you know which mutter version do have the fix mentioned at https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 ?
Thanks.

Flags: needinfo?(robert.mader)

@stransky How does that relate to the issue? The linked issue is mutter-specific, yet this issue is reproducible for us NOT running mutter.

Assignee: nobody → stransky
Attachment #9158230 - Attachment description: Bug 1567505 [Wayland] Implement uri-list, r?jhorak → Bug 1567505 [Wayland] Implement uri-list drop target on Wayland, r?jhorak

(In reply to Hugo Osvaldo Barrera from comment #5)

@stransky How does that relate to the issue? The linked issue is mutter-specific, yet this issue is reproducible for us NOT running mutter.

Firefox on Wayland has a custom D&D handler which was implemented due to https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 and it's broken (causes this bug). When https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 is fixed we can remove it.

(In reply to Martin Stránský [:stransky] from comment #7)

(In reply to Hugo Osvaldo Barrera from comment #5)

@stransky How does that relate to the issue? The linked issue is mutter-specific, yet this issue is reproducible for us NOT running mutter.

Firefox on Wayland has a custom D&D handler which was implemented due to https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 and it's broken (causes this bug). When https://gitlab.gnome.org/GNOME/mutter/-/issues/1250 is fixed we can remove it.

I didn't know FF only has a custom D&D handler just because Mutter was buggy - I'll look into it make sure we backport it to 3.36 if that didn't happen already.

Flags: needinfo?(robert.mader)

Ah, it's in 3.36.3 - Ubuntu 20.04 doesn't have it yet (but should get it soon), Fedora and Arch do. So should be fine to land.

So this feature is broken on other platforms due to Firefox having a Mutter-specific patch?

Doesn't it makes sense to drop the custom handler so that Firefox works on non-broken desktops, and just wait for mutter to catch up? It would seem that the workaround for Mutter breaks drag and drop for everyone else, right?

(In reply to Hugo Osvaldo Barrera from comment #10)

So this feature is broken on other platforms due to Firefox having a Mutter-specific patch?

Mutter/Plasma (KDE) be more precise.

Doesn't it makes sense to drop the custom handler so that Firefox works on non-broken desktops, and just wait for mutter to catch up?
It would seem that the workaround for Mutter breaks drag and drop for everyone else, right?

That would break Fedora 31/32 which use Gnome/Wayland and Firefox Wayland backend by default.

That would break Fedora 31/32 which use Gnome/Wayland and Firefox Wayland backend by default.

Wouldn't it make more sense for Fedora to provide a patched Firefox in their repositories, and upstream Firefox be unbroken?

As somebody who's NOT using Mutter, it's kinda annoying that Firefox makes a willing choice to have a feature broken so that compatibility with a broken compositor can stay in place.

Essentially, Firefox gives a better experience on faulty compositors, at the cost of a worse experience on non-faulty ones. It's also not pushing them to fix the underlying issue either.

I agree that fedora should carry their own patches for working around mutter and kwin's bugs, instead of knowingly break firefox upstream.

That being said, those who do the work get to decide where and what work is done.

(In reply to Hugo Osvaldo Barrera from comment #12)

As somebody who's NOT using Mutter, it's kinda annoying that Firefox makes a willing choice to have a feature broken so that compatibility with a broken compositor can stay in place

First of all you are of course right that this should not stay that way. However, please note that it's often not directly clear what's a compositor bug, what's a GTK bug etc. So at the moment, Fedora and Gnome developers are doing by far the most work on the Wayland port and thus occasionally it can happen that a workaround is introduced without the underlying issue being properly debugged. Had it been clear that there's a Mutter bug making the workaround necessary, Martin would have opened in issue about it back then, just how he does quite often when he's sure about the course of a bug. When the problem is understood, things get fixed. The reason why it makes sense here to wait a bit more (IMHO) is that Martin is at the same time the main FF Wayland dev and the Fedora FF maintainer. So any time he could now spend to get the fix out a little bit faster, while carrying an extra patch for Fedora, he can also work on other things and let Mutter devs role out the fix.

Also, please note that the Wayland backend is still experimental - as soon as things are declared stable things look a bit different.

Essentially, Firefox gives a better experience on faulty compositors, at the cost of a worse experience on non-faulty ones. It's also not pushing them to fix the underlying issue either.

See above. Of course we're striving for standard conformity - more helping hands make it easier to archive that :)

Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/84a1493e1a6b
[Wayland] Implement uri-list drop target on Wayland, r=jhorak

Martin: I backported the fixes to Mutter 3.34. The next release, 3.34.8, is due on july 4., so I expect Fedora 31 to get it soon afterwards.

https://hg.mozilla.org/mozilla-central/rev/84a1493e1a6b

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
status-firefox79: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

(In reply to Robert Mader [:rmader] from comment #16)

Martin: I backported the fixes to Mutter 3.34. The next release, 3.34.8, is due on july 4., so I expect Fedora 31 to get it soon afterwards.

Great, Thanks.

You need to log in before you can comment on or make changes to this bug.