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)?
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.