Closed Bug 1786533 Opened 2 years ago Closed 2 years ago

Dragging and dropping an image from the firefox snap to an external application doesn't work

Categories

(Firefox Build System :: Third Party Packaging, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1799380

People

(Reporter: jerry, Unassigned)

References

(Blocks 2 open bugs)

Details

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

Steps to reproduce:

On Ubuntu (Xubuntu 22.04.1), drag and drop an image from Firefox (snap) into Thunar (file manager) or Gimp (image editor).

Actual results:

An error is shown in a popup saying the file /tmp/dnd_file-1/... cannot be found.

Expected results:

Image dropped as file in file system or as image in image editor.

When discussed in the snapcraft.io forum, someone wrote this:

The relevant code indeed writes the file to /tmp which in the context of the firefox snap is a private directory (/tmp/snap.firefox/tmp) which isn’t accessible to other apps like gimp.

That relevant code is here:
https://searchfox.org/mozilla-central/source/widget/gtk/nsDragService.cpp#1607

Save Image As works, but that takes so much longer.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: snap
Summary: drag and drop does not work with snap version → Dragging and dropping an image from the firefox snap to an external application doesn't work
Component: Widget: Gtk → Release Automation: Snap
Product: Core → Release Engineering
Version: Firefox 103 → unspecified
Component: Release Automation: Snap → Third Party Packaging
Product: Release Engineering → Firefox Build System

My user agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
OS: Xubuntu 22.04.1

I'm having an issue in the reverse direction, i.e. dragging and dropping files from /tmp/ into firefox page (google drive etc.) is NOT recognized. Each time I have to do that, I have to move the file to another directory and try again OR use the upload button provided by the website.

Not sure if this should be reported as a separate ticket. Please advise.

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(lissyx+mozillians)

(In reply to Magesh from comment #2)

My user agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
OS: Xubuntu 22.04.1

I'm having an issue in the reverse direction, i.e. dragging and dropping files from /tmp/ into firefox page (google drive etc.) is NOT recognized. Each time I have to do that, I have to move the file to another directory and try again OR use the upload button provided by the website.

Not sure if this should be reported as a separate ticket. Please advise.

That sounds like the intended behavior of Snap's sandboxing, I am not sure how we could solve that on our side.

Flags: needinfo?(lissyx+mozillians)
Blocks: snap-sandbox
Severity: -- → S3
Priority: -- → P3

After an unfortunate Xubuntu 22.04 update I have started experiencing this issue as well. This is highly frustrating as one of my common workflows consists of dragging images from Firefox into Thunar for use in notetaking software. Having to use an intermediate save dialog, possibly browsing to a folder, is significantly slower.

The current broken state is especially frustrating because the result is a vague file system error within the target application, which is unlikely to result in useful web search results.

For now I have given up on the default Snap Firefox install and am running the standalone download version, which can drag and drop images just fine. I very much hope this continues to be supported as Firefox is the only browser capable of drag and drop on my system.

(In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-15/01/2023] from comment #5)

https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.FileTransfer.xml

I have no idea what I am supposed to do with this file.

(In reply to vs from comment #6)

For now I have given up on the default Snap Firefox install and am running the standalone download version, which can drag and drop images just fine. I very much hope this continues to be supported as Firefox is the only browser capable of drag and drop on my system.

I think I am going to do that as well. I am dragging images to Thunar way too often, and right-click, Save As, find location (because the Snap version does not even remember the last location :( ) with several clicks takes way too much time.

Oh! And when I do Save Image As, it appears that the files is first saved in a temporary location and then, I assume, copied to the location I wanted. Why can't the drag and drop do the same?

It's getting more and more annoying not to be able to drag from a website into Thunar and why the snappy Firefox does not remember the folder I last saved an image in - it all takes so much more time.

But I found an interesting difference when dragging from Thunar into a website.

Example of where it works:
On MusicBrainz you can add cover art images to a release. This is a release page:
https://musicbrainz.org/release/f4a8aa35-da90-33d8-9307-c630d38a2bed
If you can edit, you can go to Cover Art, which is this:
https://musicbrainz.org/release/f4a8aa35-da90-33d8-9307-c630d38a2bed/cover-art
and then click Add Cover Art. The drop area there works as expected.

Example of where it does NOT work:
Go to https://www.google.com/ and go to Images and then click on the camera icon to open the drop area. Then drop an image from Thunar and you will see this message:
Can't upload. Use an image in one of these formats: .jpg, .png, .bmp, .tif or .webp
(Of course the image I tried to drop was one of those formats.)

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1799380
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.