Open Bug 832994 Opened 8 years ago Updated 3 years ago
Copy and D&D should use the download uri instead of the target file uri, for their text flavors
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.
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.
soft blocking, I think would be good to have this fixed, should be an easy fix.
OS: Mac OS X → All
Hardware: x86 → All
Summary: Dragging a download from the Library doesn't export the same data that would be copied to the clipboard → Copy should use the download uri, not the target file uri
Summary: Copy should use the download uri, not the target file uri → Copy and D&D should use the download uri instead of the target file uri, for their text flavors
Assignee: nobody → mconley
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?
Attachment #709072 - Flags: review?(mak77)
Status: NEW → ASSIGNED
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.
Attachment #709072 - Flags: review?(mak77) → review-
8 years ago
Assignee: mconley → mano
Comment on attachment 709072 [details] [diff] [review] Patch v1 Oh, in that case, ignore this patch. :)
Attachment #709072 - Attachment is obsolete: true
what's the ETA here?
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.
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.
No longer blocks: ReleaseDownloadsPane
Target Milestone: --- → Firefox 22
(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?
You need to log in before you can comment on or make changes to this bug.