Open Bug 562344 Opened 14 years ago Updated 2 years ago

CF_HDROP should provide images in the same format as the IStream

Categories

(Core :: Widget: Win32, defect, P4)

x86
Windows XP
defect

Tracking

()

People

(Reporter: khuey, Unassigned)

Details

In https://bugzilla.mozilla.org/show_bug.cgi?id=494989#c72 jpotter points out that our CF_HDROP for image dragging hack should provide the same format as the other methods.  I wonder if we can just dump the contents of our contained IStream to disk rather than muck about with the stuff that we do now.

Tentatively assigning to myself, but this is relatively low priority for me (certainly below Bug 231062) so if anyone wants to steal this feel free!
Dumping the IStream should work. As an alternative, don't you already have the file on disk in the cache directory? Why can't you just pass the filename of the cache file in the CF_HDROP format? Or is that broken by things like the privacy mode?

Also, I have seen implementations of drag & drop where the file(s) referred to in in the DROPFILES structure are not actually written to disk until a client first calls GetData() for that format. If this isn't what you're doing already I would suggest adding that - particularly if you're changing it to simply dump the IStream. The GetData() method could handle that itself the first time CF_HDROP is asked for.
I don't know why kNativeImage needs to convert to bmp file. Maybe if the flavor being requested by target is CF_DIB.
I'd say just request a normal droptempfile for kNativeImage.  I think the frontend is setting kFilePromise and that is how it is getting to that point anyway but that is something that would be easiest for me to step through the code.
From what I remember in working on this code, there were two problems. One was that the drag object was handed a kFilePromise, but the apps receiving it expected the file to be written out completely. (Photoshop for one.) The other issue was making sure the app had the file open before the drag object was destroyed, at which point we delete the temp file.
(In reply to comment #3)
> From what I remember in working on this code, there were two problems. One was
> that the drag object was handed a kFilePromise, but the apps receiving it
> expected the file to be written out completely. (Photoshop for one.) The other
> issue was making sure the app had the file open before the drag object was
> destroyed, at which point we delete the temp file.

Phil Lacy hacked around the second one with a 10 second timer or something like that.  Don't remember the bug # off hand.
I think we can remove the conversion of kNativeImage to bmp files in nsDataObj, if that was originally intended for the drag image itself. The way I see it the drag image gets converted to bitmap appropriately here
  http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsDragService.cpp#258
and we just need to handle setdata and getdata of private formats in our nsDataObj for the shell's private use of displaying the drag image, which I haven't looked at to confirm.

I can't take this now either, but if I get a chance I may check out that code to be sure it handles the drag image ok.  What I don't know is maybe firefox has it's own way of handling dragimage and needs the conversion code.
Assignee: khuey → nobody
Assignee: nobody → netzen
Assignee: netzen → nobody
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.