Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

()

Core
Drag and Drop
7 years ago
9 months ago

People

(Reporter: karlt, Unassigned)

Tracking

1.9.2 Branch
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
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
(Reporter)

Updated

7 years ago
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
(Reporter)

Comment 2

7 years ago
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.
(Reporter)

Updated

9 months ago
See Also: → bug 860857, bug 1226977
You need to log in before you can comment on or make changes to this bug.