kfilemime (x-mox-file) transferable flavor does not have code to deal with drag and drop.
There's no real opportunity in TB3 or I believe FF to test drag and drop of a local file. This patch creates a fake method. With this patch installed, in TB3 select a message and drag to the o/s desktop. The message normal drag is disabled and simply a simple file is created on c:\root directory and the nsIFile is set in the transferable for dragging. When executed the drag does nothing. It should drag to drop location.
kfilemime is enabled for dragging per https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types#file
1.9.1 is out the door already...
This isn't going to block 188.8.131.52. Can someone explain why this bug is important enough to take in a maintenance release? Is it a regression from something? It's not clear to me that it shouldn't just be included in 1.9.2...
Besides to bring up our code to meet the docs on FF 3.5 drag and drop, I have a patch for enhancement bug 462172 that would depend on this bug. That may not qualify for earlier then 1.9.2. The other bugs in the dependency tree would allow drag and drop images to an image editor like mspaint, like IE.
Comment on attachment 382912 [details] [diff] [review] enable drag if local file I'm going to correct nsDataObj::GetFile() in another bug then resubmit this fix.
the temp file was not properly loaded up into windows IDataObject::GetData for files.
Attachment #382912 - Attachment is obsolete: true
This is in the middle of a tree of patches so it probably won't get review before 338478. If the other bugs/patches in this tree catch any interest, I can update them after 338478 is resolved.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CF_HDROP
You need to log in before you can comment on or make changes to this bug.