Open Bug 564738 Opened 14 years ago Updated 3 years ago

Can't drag files from Firefox directory view to destinations within Firefox

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

1.9.2 Branch
x86
All
defect

Tracking

()

People

(Reporter: karlt, Unassigned)

References

Details

STR:

1) In one browser window, open a directory view with files.
   e.g. file:///C:/some/path/

2) In another browser window, begin composing a message in Gmail.

3) Drag a file from the directory view and drop on "Attach a file" in Gmail.

Expected results:
Gmail attaches the dragged file.

Actual results:
Nothing

Files can be dragged from the directory view to the desktop to copy,
and files can be dragged from the OS file manager to Gmail to attach.
However, apparently there are some differences

a) between what the desktop accepts as a file drag and what Gmail recognizes
   as a file drag, and 

b) between what the Firefox directory view presents for a file drag and what
   the OS file manager presents.
I see something similar on Linux (Gmail attachments are not working at all on Linux) when dragging image files from a file:///home/karl/tmp/ directory view to http://demos.hacks.mozilla.org/openweb/uploadingFiles/.
It works across different browser instances but not within browser instances.

Should DragDataProducer::AddStringsToDataTransfer for nsContentAreaDragDrop
explicitly add kFileMime (or kFilePromiseMime) when the url is a local file?
(It uses kFilePromiseMime even for non-local images IIUC.)

Or should nsDOMDataTransfer handle the conversion from local uri-list members
to files (which would also simplify widget level code)?
OS: Windows XP → All
Summary: Can't drag files from Firefox directory view to attach to Gmail messages → Can't drag files from Firefox directory view to destinations within Firefox
Hmm.  I guess dragging an anchor that happens to point to a local file perhaps should not necessarily provide the files to a web page.

I wonder how we can tell when the user intends that a dragged uri should provide a file that would not otherwise be available.
I think it should be added in DragDataProducer::AddStringsToDataTransfer as I'm not sure that converting a url to a file should be an automatic process, but I can't think of a specific case where you wouldn't want to.

When the file is added, we can check it's principal to see whether the page it's linked from has access to that file and not add the file in this case.
See Also: → 860857, CVE-2016-5266

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.