374593 - Implement bug 178513 on Windows (translucent drag feedback)

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement, P2)

Description

[Neil Deakin]

Comment 1

[Dão Gottwald [:dao]]

1.9beta1 is coming closer. will somebody work on this in the near future?

Comment 2

[Neil Deakin]

Hopefully, a Windows guru will step up. It should be a fairly small patch using the Windows IDragSourceHelper::InitializeFromBitmap API. I've tried to implement it but haven't had much luck.

Comment 3

[Mike Connor [:mconnor]]

Jim, can you take a look here?

Comment 4

[Jim Mathies [:jimm]]

Can somebody give me a good example of how to reproduce this? In 178513 I'm seeing references to dragged email items and text dragging in editors like gmail. Everything I drag around in Firefox acts as I would expect it to on windows (images, text), and email items in thunderbird appear to be working as expected as well.

Comment 5

[Martijn Wargers (dead)]

Huh? It just doesn't work for me on any text or image with current trunk Firefox build on windowsXP or windows Vista.
How is it possible that it works for you?

Comment 6

[Jim Mathies [:jimm]]

Maybe I'm miss interpreting the problem - in 178513 they seem to be talking about some sort of transparency issue when dragging images and text around in HTML editors like gmail. The description of the bug is "Make text, images translucent while dragging instead of outline."  

Comment 7

[Dão Gottwald [:dao]]

Jim, there's no problem. This bug is an enhancement request. Please just grab a trunk build on Linux (has opaque drag feedback) or Mac OS (should have translucent drag feedback) and drag stuff around.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's the Mac behaviour that you really want to emulate...

Comment 9

[Neil Deakin]

Jim, were you going to work on this? Let me know if you need any help, as I really like this fixed for 1.9

Comment 10

[Jim Mathies [:jimm]]

Hey - wouldn't mind getting to it, though I have some priorities that come before it - 377419, 372111 & 371355.  Seeing as how this isn't default windows behavior for drag and drop - I didn't stack up too high on the priority list. I also have a networking enhancement that I'd probably put above it.  

Comment 11

[Dão Gottwald [:dao]]

Explorer as the file browser as well as the shell (Start menu, Desktop) does this all over the place. So this is actually default Windows behavior.

Comment 12

[Jim Mathies [:jimm]]

> Please just grab a trunk build on Linux (has opaque drag feedback) or Mac OS > (should have translucent drag feedback) and drag stuff around.

I don't have a mac nor a linux box. Could someone give me a step by step, or a screenshot or something? I'm still not sure what feature we're trying to implement here.

I do see icons with partial transparency dragged around on Vista, say when dragging a file from one window to another. Not sure how that fits in with firefox though. Would this have something to do with link drags where the dragged link dispays an html icon rather than a standard drag box?

Comment 13

[Neil Deakin]

Attachment: image

When an element is dragged, a translucent rendition of what it being dragged is drawn with the cursor as it moves about. For example, currently on Windows dragging a tab just changes the icon, but on Mac/Linux an image of the tab is dragged. This is shown in the attached image (although the mouse cursor doesn't appear it would be over the dragged tab). Similar for bookmarks, toolbar buttons while customizing, text that is selected, or images.

Comment 14

[Dão Gottwald [:dao]]

For a limited preview, you can also install Opera or Safari on Windows. They don't implement this for all elements but for images only. Also, if you tear off a tab in Safari, it shows a thumbnail of the tab, which is interesting but not directly what this bug is about.

Comment 15

[Jim Mathies [:jimm]]

Ok, this is making sense now, thanks. Starting in on it today.

Comment 16

[Jim Mathies [:jimm]]

Attachment: drag-n-drop patch v.1

75% of the way there, this patch adds support for application -> dekstop dragging and the backend support for drop source image rendering. Next up I need to add the other half of inter-application dragging which requires modifying drop target handlers.

Note, this is not a final patch, I still need to do some cleanup on it. I'm also wondering if we should block certain types of xul and html nodes from being rendered. For example text selections, which can look cool but I'm not sure they communicate much to the user. Tabs might be better replaced with the default system URL link icon instead of the actual tab. (see screenshot) 

Can anybody fill me in on how these types of elements are being handled on other operating systems?

Comment 17

[Jim Mathies [:jimm]]

Attachment: dekstop drag screenshots

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #16)
> Can anybody fill me in on how these types of elements are being handled on
> other operating systems?

On Linux it's as in your screenshot, minus the alpha transparency. Frankly, dragged text looks a bit ugly this way, because translucent anti-aliasing pixels become opaque.

Comment 19

[Jim Mathies [:jimm]]

Attachment: drag-n-drop patch v.2

Added drop target support for inter-application and desktop -> application drag image support, and cleanup.

Comment 20

[Jim Mathies [:jimm]]

Attachment: tab drag screenshot

Comment 21

[Jim Mathies [:jimm]]

Attachment: drag-n-drop path v.3

Minor update - disabled some debug output I left on, and added a null set on m_spdth in nsNativeDragTarget's constructor which would have caused problems if CoCreateInstance failed on older systems. Also took out some unneeded debug commenting.

Comment 22

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #18)
> (In reply to comment #16)
> > Can anybody fill me in on how these types of elements are being handled on
> > other operating systems?
> 
> On Linux it's as in your screenshot, minus the alpha transparency. Frankly,
> dragged text looks a bit ugly this way, because translucent anti-aliasing
> pixels become opaque.

I would suggest that on all platforms we should clear the canvas to white, not to transparency -- maybe even better clear it to white with a smooth fade out to transparent around the edges or something.  I guess we should only do that for non-image content (or make sure that we draw images with OPERATOR_SOURCE instead of OVER).  That way content that doesn't clear the background itself (e.g. the text) will still get a background and won't look ugly and jagged, whereas content that does will just overwrite it.

Comment 23

[Neil Deakin]

Jim, this looks great, but it doesn't seem to work properly on my machine. I get the drag image, but it just appears over the tab or whatever I'm dragging and doesn't follow the cursor. It seems to only update when I moved the mouse outside the window border or between the content and chrome area (possibly this is only when a native mouse exit occurs).

Comment 24

[Jim Mathies [:jimm]]

>Jim, this looks great, but it doesn't seem to work properly on my machine. I
>get the drag image, but it just appears over the tab or whatever I'm dragging
>and doesn't follow the cursor. It seems to only update when I moved the mouse
>outside the window border or between the content and chrome area (possibly this
>is only when a native mouse exit occurs).

Hey, can you clarify a bit? I'm not 100% on what you're describing. 

"doesn't follow the cursor." 
It's static in one place, and doesn't move at all with the mouse?

"It seems to only update when I moved the mouse outside the window border"
So it works inter-application but not when you drag out to the desktop?

Also, can you tell me what os are your using?
 

Comment 25

[Jim Mathies [:jimm]]

> I guess we should only do that for non-image content

Hey Vlad,

You klnow I was messing around with a way to identify what type of element it was that was being dragged, but couldn't figure out how to do it without a bunch of tag string compares - 

  PRUint16 nodeType = 0;
  GetNodeType(&nodeType);
  if (nodeType == nsIDOMNode::ELEMENT_NODE) {
    nsAutoString tagName;
    aDOMNode->GetTagName(tagName);
    PRNTDEBUG2("Tag Name: '%s'\n", NS_ConvertUTF16toUTF8(tagName).get());
    if (tagName.Equals("HREF")) {
    }
  }

any better ideas?

Comment 26

[Neil Deakin]

This is Windows XPSP2. The dragimage appears but doesn't move around while the mouse cursor is moved.

> So it works inter-application but not when you drag out to the desktop?

No, it doesn't move at all except when the mouse is moved across the border of a window. When that happens, the drag image jumps and appears at the mouse pointer.   But then it doesn't move again until the mouse goes across a border again.

For border, this also includes the boundary between the chrome area and the content area, presumably because a different native widget is used to display that area. From the behaviour I'm seeing, it suggests that the drag image is only being updated when the OS sends an mouse enter or mouse exit event.

Comment 27

[Martijn Wargers (dead)]

This looks cool!
I see the same problem as Neil. I'm on windowsXP.
In general, the drag image doesn't follow the mouse cursor, unless outside the window. Then it's suddenly working fine.
I wonder if it has something to do with the fact that timers don't fire on windows, while dragging (bug 203573).

Also, in nsDragService.h, could this part be removed:
+#include <shobjidl.h>
It doesn't seem to be necessary and causes a build error in mingw.

Comment 28

[Dão Gottwald [:dao]]

(In reply to comment #22)
> I would suggest that on all platforms we should clear the canvas to white, not
> to transparency -- maybe even better clear it to white with a smooth fade out
> to transparent around the edges or something.  I guess we should only do that
> for non-image content (or make sure that we draw images with OPERATOR_SOURCE
> instead of OVER).  That way content that doesn't clear the background itself
> (e.g. the text) will still get a background and won't look ugly and jagged,
> whereas content that does will just overwrite it.

This would mean that the text color would have to be forced to be black, otherwise you could get white on white.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Forcing the text color to black doesn't work if the content has an explicit black background.

Personally I quite like the transparency of the dragged content and it avoids opening this can of worms. I think Linux users should just deal with the fringing until they get translucent dragging too.

Comment 30

[Jim Mathies [:jimm]]

Attachment: drag-n-drop path v.4

Ok, found the problem and confirmed it's working on XP.

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 281389 [details] [diff] [review]
drag-n-drop path v.4

sorry, I don't really know this code

Comment 32

[Martijn Wargers (dead)]

Thanks, it all seems to work fine now.
I still get a build error with this in mingw:
+#include <shlobj.h>
+#ifndef IDropTargetHelper
+#include <shobjidl.h> // Vista drag image interfaces
+#endif
But that doesn't seem to make any sense, so I guess there is something wrong with my mingw setup (IDropTargetHelper is defined just fine in shlobj.h.

Comment 33

[Neil Deakin]

Looks great now. Thanks for doing this! Two comments:

1. Are you changing the alpha transparency? For large images or selections, the drag image becomes harder to see. This is very noticable when two lines of text are dragged.

2. When I tried unsuccessfully to implemenent this I needed to modify a configure parameter to indicate that IE5 was needed for building as the drag component required it. We should find out if that's still the case. cc'ing bsmedberg in case.

Comment 34

[Neil Deakin]

Also I notice that there's some code you're adding which scales the image. Is there a reason for doing this? The cross-platform code already does scaling down of large images, and I'm a bit worried that the extra level of scaling will affect the calculations which position the image relative to the mouse cursor. That is, the API lets one specify a custom image for the drag and the x,y offsets where it should be positioned relative to the mouse cursor.

Comment 35

[Jim Mathies [:jimm]]

Hey Neil - 

On scaling - there was no scaling taking place when I implemented this the first time on Vista. Large, desktop sized images were dragged out without any changes. It really didn't look right to me, and the larger image also obscured the stuff underneath enough so that it was hard to tell where you were dropping it. You can control the size of the scaling using the DRAGIMG_DIM define at the top of nsDragService.

On the mouse position - I choose to put the image directly in the center, because I couldn't find a mouse offset in the data I had. If anybody knows where I can find that (the relative offset on the element for the mouse when the left button is presses) I can adjust the code to use that. Overall though the offset in the center seems to work well from my testing.

On minimum requirements - in order for this to work, the os needs shell32.dll version 5.0 and higher. That will be available on 2K and up with IE5 installed. If for some reason it's not, this patch should fail passively. (see CoCreateInstance of CLSID_DragDropHelper in nsDragService and nsNativeDragTarget.) I haven't tested this but I believe our minimum requirements these days are 2K and up so we shouldn't be running on officially sanctioned os's that don't have DragDropHelper support. Our current SDK requirements on builds also insure the interfaces will be defined.

"Are you changing the alpha transparency?" - No Windows decides that value, I'm setting the alpha channel to 0xFF in the DIB. I agree XP is quite dim, but that's the OS default. Vista does a much better job of this.

Comment 36

[Jim Mathies [:jimm]]

Martijn - maybe use CLSID_DragDropHelper in that ifndef? I can't test this so if you have the time would appreciate the help in figuring out how to properly ifndef that so cygwin doesn't have any issues.

Comment 37

[Jim Mathies [:jimm]]

Related - bug 396592 in case anyone is testing on Vista.

Comment 38

[Neil Deakin]

(In reply to comment #35)

> On the mouse position - I choose to put the image directly in the center,
> because I couldn't find a mouse offset in the data I had. If anybody knows
> where I can find that (the relative offset on the element for the mouse when
> the left button is presses) I can adjust the code to use that. Overall though
> the offset in the center seems to work well from my testing.

When DrawDrag is called, aScreenDragRect will be set to the screen rectangle where the image should appear (x and y are the screen coordinates, width and height are the size). We definitely want to use this, that way dragging, for example a tab, causes the image of the tab to appear exactly where the tab is, so that it looks more like the user is picking it up and moving it.

> 
> On minimum requirements - in order for this to work, the os needs shell32.dll
> version 5.0 and higher. That will be available on 2K and up with IE5 installed.

Actually I was referring to build requirements. When building I needed to set a flag that set IE5 was the minimum needed.

> "Are you changing the alpha transparency?" - No Windows decides that value, I'm
> setting the alpha channel to 0xFF in the DIB. I agree XP is quite dim, but
> that's the OS default. Vista does a much better job of this.
> 

That sounds ok then.

Comment 39

[(not currently active) Ted Mielczarek]

Enn: I think I already took care of the IE5 requirement:
http://lxr.mozilla.org/mozilla/source/configure.in#564

Comment 40

[Ere Maijala (slow)]

Comment on attachment 281389 [details] [diff] [review]
drag-n-drop path v.4

Works great, but please name at least the new member variables to something sensible (like mDropHelper instead of m_spdth). Also pay attention to the interCaps style. Could you also make the helper functions members of nsDataObj? As far as I can see they also don't need to be static. I know this is mostly from MSDN, but still.

Comment 41

[Jim Mathies [:jimm]]

will do. I'll try to get another patch posted later today.

Comment 42

[Jim Mathies [:jimm]]

Attachment: drag-n-drop path v.5

Comment 43

[Jim Mathies [:jimm]]

>Also I notice that there's some code you're adding which scales the image. Is
>there a reason for doing this? The cross-platform code already does scaling
>down of large images, and I'm a bit worried that the extra level of scaling
>will affect the calculations which position the image relative to the mouse
>cursor. That is, the API lets one specify a custom image for the drag and the
>x,y offsets where it should be positioned relative to the mouse cursor.

That would be correct, and I need a minor update on v.5 to address this. Thanks for pointing this out.

Comment 44

[Jim Mathies [:jimm]]

Attachment: drag-n-drop v.6

added if scale < 1, just default to centering the image on the mouse.

Comment 45

[Ere Maijala (slow)]

Comment on attachment 282318 [details] [diff] [review]
drag-n-drop v.6

The latest patch doesn't apply cleanly to nsNativeDragTarget.cpp.

Comment 46

[Jim Mathies [:jimm]]

Attachment: drag-and-drop path v.7

updated

Comment 47

[Jim Mathies [:jimm]]

Comment on attachment 282991 [details] [diff] [review]
drag-and-drop path v.7

must remember to do a diff on the patch first!

Comment 48

[Jim Mathies [:jimm]]

Attachment: drag-and-drop path v.7

updated

Comment 49

[Ere Maijala (slow)]

Comment on attachment 282993 [details] [diff] [review]
drag-and-drop path v.7

The patch was missing one pt -> ptl change in DragOver. With that fixed, looks good to me. r=emaijala.

Comment 50

[Ere Maijala (slow)]

Comment on attachment 282993 [details] [diff] [review]
drag-and-drop path v.7

Sorry, I'll take that back. Doesn't work properly in all cases. Try for example dragging the Mozilla.org logo with the lizard from the mozilla.org home page. The image is very small and way to the right from the mouse cursor.

Comment 51

[Jim Mathies [:jimm]]

Can someone point me to a broken drag image? I can't seem to reproduce. I did notice once the cursor being off, but this was from a "sudden, quick drag" of an image, and didn't seem to be related to this code. 

Comment 52

[Jim Mathies [:jimm]]

never mind, really tall images seem off. I'll take a look.

Comment 53

[Jim Mathies [:jimm]]

Ok, after a recompile and some testing on google images, i'm not seeing any problems. I couldn't find the lizard image on mozilla.org - all I see there are a couple round iconic images. So if anyone knows of a broken image, please post it. This is working afaict.

Comment 54

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #53)
> I couldn't find the lizard image on mozilla.org

I think Ere means the "dinosaur head" image on the top left, attached to the "mozilla.org" text in the top blue banner.

Comment 55

[Jim Mathies [:jimm]]

Hmm, so basically grabbing a massively long div element which gets resized. This is going to be tough to tweak across all element block types that are dragable. I guess I can just turn off scaling, or maybe disable it in cases where at least one dimension is smaller than the max value at which scaling kicks in?

Comment 56

[Neil Deakin]

I still don't understand why you're doing additional scaling. The existing platfor independant code already does this and has been tested. If we need to adjust it, we should do so for all platforms in a followup bug.

Comment 57

[Jim Mathies [:jimm]]

The scaling was added because nsBaseDragService::DrawDrag doesn't do any scaling. I only added that after testing this patch without it. At that point, large images were rendered in DrawDrag full size, which made the feature pretty much worthless. But I can disable the scaling and post another patch so folks can try it out. 

I'm curious though on other platforms, what happens when you drag a very large image (hieght/width > 1000px) out to the desktop? Is it scaled?

Comment 58

[Jim Mathies [:jimm]]

Attachment: drag-and-drop path v.8

Ok, here's a new one that has one change - scaling will trigger only when both dimensions of the element are larger than DRAGIMG_DIM. This prevents the scaling of blocks like the mozilla.org header, which had dimensions of around 1280x200.

Comment 59

[Jim Mathies [:jimm]]

Attachment: mozilla.org header drag screenshot

Comment 60

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #57)
> I'm curious though on other platforms, what happens when you drag a very large
> image (hieght/width > 1000px) out to the desktop? Is it scaled?

It is, on Mac. So I agree with Neil that the cross-platform drag code should be taking care of all scaling.

Comment 61

[Neil Deakin]

Images that are larger than half the screen size are scaled down to that size in PresShell::PaintRangePaintInfo. There's also scaling code in nsBaseDragService::DrawDragForImage for drawing custom drag images. Unfortunately I don't have a test for that latter case with large images currently, but can create one if desired. It will become more important once what-wg drag and drop is implemented.

Comment 62

[Ere Maijala (slow)]

Comment on attachment 284328 [details] [diff] [review]
drag-and-drop path v.8

Looks good to me now. r=emaijala

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 284328 [details] [diff] [review]
drag-and-drop path v.8

DrawDrag should be scaling things down so they fit in a reasonable size. It does on Mac. We need to figure out why that's not working and make it work instead of adding new scaling code.

Comment 64

[Jim Mathies [:jimm]]

>DrawDrag should be scaling things down so they fit in a reasonable size. It
>does on Mac. 

Are we sure about that? I have no access to a Mac system so if someone on that platform could step through the code and find where the scaling is actually occuring, I might be able to find the problem on windows. I've looked over the DrawDrag code and stepped through it, and I don't see where the scaling should occur. Any help would be appreciated.. I've got some M10 stuff to work on but would love to close this out before if possible.

Comment 65

[Neil Deakin]

(In reply to comment #64)

> I've looked over the
> DrawDrag code and stepped through it, and I don't see where the scaling should
> occur. Any help would be appreciated..

Jim, I answered this in comment 61.

Comment 66

[Jim Mathies [:jimm]]

Hey Neil,  

On the windows side of things, nsBaseDragService's mImage is null when dragging an image, so nsBaseDragService::DrawDragForImage is never called during the operation. InvokeDragSessionWithImage is invoked from nsContentAreaDragDrop::DragGesture, but the nsIDOMNode* aImage is empty. DragGesture specifically sets this to null. I don't see how this would be different on the mac.

I'll go ahead and post a new patch sans my custom scaling here in a sec. I'm all for rolling the scaling discussion out into another bug. :)

Comment 67

[Jim Mathies [:jimm]]

I think I see the problem here. I'm assuming more scaling needs to occur. I just ran this without my scaling and dragged a very large image out of the content area, it did get moderately scaled in PaintRangePaintInfo, just not an much as I would have preferred.

Comment 68

[Jim Mathies [:jimm]]

Attachment: cross platform scaling

current scaling without native scaling code.

Comment 69

[Jim Mathies [:jimm]]

Attachment: drag-and-drop path v.9

Comment 70

[Neil Deakin]

(In reply to comment #66)
> Hey Neil,  
> 
> On the windows side of things, nsBaseDragService's mImage is null when dragging
> an image, so nsBaseDragService::DrawDragForImage is never called during the
> operation.

DrawDragForImage is only used when someone calls the InvokeDragSessionWithImage with a custom image, so that a customized image can be used in place of what was clicked on. There isn't anywhere in Mozilla currently using this as far as I know. But in the future, this would be used to implement the whatwg spec, and for instance, we might implement the Safari-like method of dragging a box with a title and url in it when dragging a link.

Comment 71

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+#if 0
+#define PRNTDEBUG(_x) printf(_x);
+#define PRNTDEBUG2(_x1, _x2) printf(_x1, _x2);
+#define PRNTDEBUG3(_x1, _x2, _x3) printf(_x1, _x2, _x3);
+#define PRNTDEBUG4(_x1, _x2, _x3, _x4) printf(_x1, _x2, _x3, _x4);
+#else
+#define PRNTDEBUG(_x) // printf(_x);
+#define PRNTDEBUG2(_x1, _x2) // printf(_x1, _x2);
+#define PRNTDEBUG3(_x1, _x2, _x3) // printf(_x1, _x2, _x3);
+#define PRNTDEBUG4(_x1, _x2, _x3, _x4) // printf(_x1, _x2, _x3, _x4);
+#endif

Use PR_LOG instead of all this.

Use nsTArray instead of mDataEntry/mDataEntryCount. It's easier, safer, and more efficient.

+  bmih.bV5Width       = dragRect.width;
+  bmih.bV5Height      = -dragRect.height; // flip vertical

Is there a problem if either of these is zero? Bitmap-related code in cairo has special code to avoid using 0 here.

Otherwise looks good.

Comment 72

[Jim Mathies [:jimm]]

Are folks here interested in seeing scaled drag image size broken out into another bug, or are we happy with the way we are handling this? IMHO it's not correct - very large drag images obscure the target on XP and on Vista we fail to emulate local os behavior seen in explorer.

Comment 73

[Robert O'Callahan (:roc) (email my personal email if necessary)]

File a follow-up bug on that. If we need to change the scaling behaviour we should do it where the scaling already happens. If we need per-platform behaviour then we should add pref(s) to control it.

Comment 74

[Dão Gottwald [:dao]]

(In reply to comment #72)
> Are folks here interested in seeing scaled drag image size broken out into
> another bug, or are we happy with the way we are handling this? IMHO it's not
> correct - very large drag images obscure the target on XP

That's even more a problem for Linux, because dragged images are opaque there.

Comment 75

[Jim Mathies [:jimm]]

Attachment: drag-and-drop path v.10

- removed the debug stuff, it was chatty and really only needed in the work I did here.
- added a zero width/height check and ducked out if either exists
- added nsTArray support

Comment 76

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 285902 [details] [diff] [review]
drag-and-drop path v.10

a=endgame drivers for after M9 freeze

Comment 77

[ronin.achilles]

Is this targeted for B2?

Comment 78

[Dão Gottwald [:dao]]

Any reason why this wasn't landed yet?

Comment 79

[Reed Loden [:reed]]

Checking in widget/src/windows/nsDataObj.cpp;
/cvsroot/mozilla/widget/src/windows/nsDataObj.cpp,v  <--  nsDataObj.cpp
new revision: 1.86; previous revision: 1.85
done
Checking in widget/src/windows/nsDataObj.h;
/cvsroot/mozilla/widget/src/windows/nsDataObj.h,v  <--  nsDataObj.h
new revision: 1.38; previous revision: 1.37
done
Checking in widget/src/windows/nsDragService.cpp;
/cvsroot/mozilla/widget/src/windows/nsDragService.cpp,v  <--  nsDragService.cpp
new revision: 1.57; previous revision: 1.56
done
Checking in widget/src/windows/nsDragService.h;
/cvsroot/mozilla/widget/src/windows/nsDragService.h,v  <--  nsDragService.h
new revision: 1.29; previous revision: 1.28
done
Checking in widget/src/windows/nsNativeDragTarget.cpp;
/cvsroot/mozilla/widget/src/windows/nsNativeDragTarget.cpp,v  <--  nsNativeDragTarget.cpp
new revision: 1.41; previous revision: 1.40
done
Checking in widget/src/windows/nsNativeDragTarget.h;
/cvsroot/mozilla/widget/src/windows/nsNativeDragTarget.h,v  <--  nsNativeDragTarget.h
new revision: 1.13; previous revision: 1.12
done

Comment 80

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111705 Minefield/3.0b2pre

Comment 82

[Mike Beltzner [:beltzner, not reading bugmail]]

Is there any reason why this has a radial fadeout effect on text? Grab a large chunk of text and drag it, and you'll see what I mean: it's faded on the edges in an oval pattern.

Comment 83

[Jim Mathies [:jimm]]

Yes, I believe so. XP displays radial fades in Explorer when dragging a large block of files between folders. AFAICT with Vista the effect hasn't changed, although I've not seen a specific example of a large drag image - most of the vista apps now shrink everything down to 256x256 thumbnails.

Comment 84

[Mike Beltzner [:beltzner, not reading bugmail]]

Neil Deakin basically told me the same thing, as well as the fact that "Windows drag and drop APIs suck."

Alas.