Closed Bug 374593 Opened 13 years ago Closed 12 years ago

Implement bug 178513 on Windows (translucent drag feedback)

Categories

(Core :: DOM: Drag & Drop, enhancement, P2)

x86
Windows XP
enhancement

Tracking

()

VERIFIED FIXED
mozilla1.9beta2

People

(Reporter: enndeakin, Assigned: jimm)

References

(Depends on 2 open bugs)

Details

(Keywords: platform-parity, Whiteboard: parity-opera, parity-safari)

Attachments

(4 files, 12 obsolete files)

25.94 KB, image/png
Details
60.12 KB, image/pjpeg
Details
41.80 KB, image/pjpeg
Details
24.97 KB, patch
beltzner
: approvalM9-
beltzner
: approval1.9+
Details | Diff | Splinter Review
 
OS: Mac OS X → Windows XP
Target Milestone: --- → mozilla1.9beta1
1.9beta1 is coming closer. will somebody work on this in the near future?
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.
Keywords: helpwanted
Jim, can you take a look here?
Assignee: nobody → jmathies
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.
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?
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."  
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.
Severity: normal → enhancement
It's the Mac behaviour that you really want to emulate...
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
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.  
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.
Keywords: pp
Whiteboard: parity-opera
Whiteboard: parity-opera → parity-opera, parity-safari
> 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?
Attached image 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.
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.
Ok, this is making sense now, thanks. Starting in on it today.
Status: NEW → ASSIGNED
Attached patch drag-n-drop patch v.1 (obsolete) — Splinter Review
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?
Attached image dekstop drag screenshots (obsolete) —
(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.
Attached patch drag-n-drop patch v.2 (obsolete) — Splinter Review
Added drop target support for inter-application and desktop -> application drag image support, and cleanup.
Attachment #281225 - Attachment is obsolete: true
Attachment #281242 - Flags: review?(dougt)
Attached image tab drag screenshot
Attached patch drag-n-drop path v.3 (obsolete) — Splinter Review
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.
(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.
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).
>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?
 
> 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?
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.
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.
Attachment #281242 - Flags: review?(dougt)
(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.
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.
Attached patch drag-n-drop path v.4 (obsolete) — Splinter Review
Ok, found the problem and confirmed it's working on XP.
Attachment #281242 - Attachment is obsolete: true
Attachment #281286 - Attachment is obsolete: true
Attachment #281389 - Flags: review?(cbiesinger)
Comment on attachment 281389 [details] [diff] [review]
drag-n-drop path v.4

sorry, I don't really know this code
Attachment #281389 - Flags: review?(cbiesinger) → review?(emaijala)
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.
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.

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.
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.
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.
Related - bug 396592 in case anyone is testing on Vista.
(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.
Enn: I think I already took care of the IE5 requirement:
http://lxr.mozilla.org/mozilla/source/configure.in#564
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.
Attachment #281389 - Flags: review?(emaijala) → review-
will do. I'll try to get another patch posted later today.
Attached patch drag-n-drop path v.5 (obsolete) — Splinter Review
Attachment #281389 - Attachment is obsolete: true
Attachment #282155 - Flags: review?(emaijala)
>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.
Attached patch drag-n-drop v.6 (obsolete) — Splinter Review
added if scale < 1, just default to centering the image on the mouse.
Comment on attachment 282318 [details] [diff] [review]
drag-n-drop v.6

The latest patch doesn't apply cleanly to nsNativeDragTarget.cpp.
Attached patch drag-and-drop path v.7 (obsolete) — Splinter Review
updated
Attachment #282155 - Attachment is obsolete: true
Attachment #282318 - Attachment is obsolete: true
Attachment #282991 - Flags: review?(emaijala)
Attachment #282155 - Flags: review?(emaijala)
Comment on attachment 282991 [details] [diff] [review]
drag-and-drop path v.7

must remember to do a diff on the patch first!
Attachment #282991 - Attachment is obsolete: true
Attachment #282991 - Flags: review?(emaijala)
Attached patch drag-and-drop path v.7 (obsolete) — Splinter Review
updated
Attachment #282993 - Flags: review?(emaijala)
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.
Attachment #282993 - Flags: review?(emaijala) → review+
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.
Attachment #282993 - Flags: review+ → review-
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. 
never mind, really tall images seem off. I'll take a look.
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.
(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.
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?
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.
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?
Attached patch drag-and-drop path v.8 (obsolete) — Splinter Review
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.
Attachment #282993 - Attachment is obsolete: true
Attached image mozilla.org header drag screenshot (obsolete) —
Attachment #284328 - Flags: review?(emaijala)
(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.
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 on attachment 284328 [details] [diff] [review]
drag-and-drop path v.8

Looks good to me now. r=emaijala
Attachment #284328 - Flags: review?(emaijala) → review+
Attachment #284328 - Flags: superreview?(roc)
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.
Attachment #284328 - Flags: superreview?(roc) → superreview-
>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.
(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.
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. :)
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.
Attached image cross platform scaling
current scaling without native scaling code.
Attachment #281226 - Attachment is obsolete: true
Attachment #284330 - Attachment is obsolete: true
Attached patch drag-and-drop path v.9 (obsolete) — Splinter Review
Attachment #284328 - Attachment is obsolete: true
Attachment #285379 - Flags: superreview?(roc)
(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.

+#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.

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.
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.
(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.
- 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
Attachment #285379 - Attachment is obsolete: true
Attachment #285902 - Flags: superreview?(roc)
Attachment #285379 - Flags: superreview?(roc)
Attachment #285902 - Flags: approval1.9?
Attachment #285902 - Flags: superreview?(roc) → superreview+
Keywords: helpwanted
Target Milestone: mozilla1.9 M8 → ---
Attachment #285902 - Flags: approvalM9?
Comment on attachment 285902 [details] [diff] [review]
drag-and-drop path v.10

a=endgame drivers for after M9 freeze
Attachment #285902 - Flags: approvalM9?
Attachment #285902 - Flags: approvalM9-
Attachment #285902 - Flags: approval1.9?
Attachment #285902 - Flags: approval1.9+
Priority: -- → P2
Is this targeted for B2?
Any reason why this wasn't landed yet?
Keywords: checkin-needed
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
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M10
Flags: in-litmus?
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111705 Minefield/3.0b2pre
Status: RESOLVED → VERIFIED
Depends on: 404702
Depends on: 405089
Depends on: 406084
Duplicate of this bug: 406220
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.
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.
Neil Deakin basically told me the same thing, as well as the fact that "Windows drag and drop APIs suck."

Alas.
Depends on: 420070
No longer depends on: 441420
Depends on: 457803
No longer depends on: 470532
QA Contact: drag-drop
Blocks: 732733
You need to log in before you can comment on or make changes to this bug.