832994 - Copy and D&D should use the download uri instead of the target file uri, for their text flavors

Status: NEW

(Firefox :: Downloads Panel, defect)

Description

[Asaf Romano (gone)]

In the new downloads view, both copy-to-clipboard functionality and drag & drop functionality are implemented.  However, while copying a download copies the download url to the clipboard, dragging a download sets the target file url (if any) as the drag data.

This is somewhat unexpected. I don't know of any other UI that works this way. Modifier-less drag is usually mapped to work just like cut (if available) or copy.

Apparently (at least on OS X), the legacy manager "solved" the dilemma by not implementing the standard accel+c keyboard shortcut at all. One could copy the download url only by using the context menu item for this command.

Comment 1

[Marco Bonardo [:mak]]

I like your suggestion to use the source url for text flavors and the target file for file flavors, this gets the best of the 2 worlds. I don't think there's need for ux here it's mostly an implementation detail.

Comment 2

[Marco Bonardo [:mak]]

soft blocking, I think would be good to have this fixed, should be an easy fix.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v1

This patch changes the drag and drop behaviour so that we provide the source URI for a download for targets that accept text.

Was I correct in interpreting that this is the approach we wanted to take?

Comment 4

[Asaf Romano (gone)]

Comment on attachment 709072 [details] [diff] [review]
Patch v1

First, I'm pretty sure that by removing the file uri from the url list, you're making it so one cannot drag the download as a file to the system file manager. That's why we only want to change the data for text/plain.

Second, once we "drag" the download url, we don't need to abort drag for anything. It's just that download's with no target file would only have text/plain data.

Third, I already have a patch for this. Sorry I didn't note that here earlier.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 709072 [details] [diff] [review]
Patch v1

Oh, in that case, ignore this patch. :)

Comment 6

[Marco Bonardo [:mak]]

what's the ETA here?

Comment 7

[Asaf Romano (gone)]

I was wrong about the first point. It's application/x-moz-file that does this magic, and it seems it's not supported for clipboard operations. Thus we can only fix the drag issue.

Comment 8

[Asaf Romano (gone)]

Taking this off the blockers list for now.

It turns out that at least on mac application/x-moz-file is totally broken, and the only reason we didn't know about it is that we also set the file uri as another flavor.

I'll file the back end bug (or bugs) soon.

Comment 9

[Marco Bonardo [:mak]]

(In reply to Mano from comment #8)
> Taking this off the blockers list for now.
> 
> It turns out that at least on mac application/x-moz-file is totally broken,
> and the only reason we didn't know about it is that we also set the file uri
> as another flavor.
> 
> I'll file the back end bug (or bugs) soon.

did you ever file that bug?