Implement bug 178513 on Windows (translucent drag feedback)

VERIFIED FIXED in mozilla1.9beta2

Status

()

Core
Drag and Drop
P2
enhancement
VERIFIED FIXED
10 years ago
5 years ago

People

(Reporter: Neil Deakin (not available until Aug 9), Assigned: jimm)

Tracking

(Depends on: 2 bugs, {pp})

Trunk
mozilla1.9beta2
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-opera, parity-safari)

Attachments

(4 attachments, 12 obsolete attachments)

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
(Reporter)

Updated

10 years ago
Target Milestone: --- → mozilla1.9beta1

Comment 1

10 years ago
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.

Updated

10 years ago
Keywords: helpwanted
Jim, can you take a look here?
Assignee: nobody → jmathies
(Assignee)

Comment 4

10 years ago
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?
(Assignee)

Comment 6

10 years ago
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

10 years ago
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
(Assignee)

Comment 10

10 years ago
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.

Updated

10 years ago
Keywords: pp
Whiteboard: parity-opera

Updated

10 years ago
Whiteboard: parity-opera → parity-opera, parity-safari
(Assignee)

Comment 12

10 years ago
> 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?
Created attachment 275381 [details]
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.
(Assignee)

Comment 15

10 years ago
Ok, this is making sense now, thanks. Starting in on it today.
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 16

10 years ago
Created attachment 281225 [details] [diff] [review]
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?
(Assignee)

Comment 17

10 years ago
Created attachment 281226 [details]
dekstop drag screenshots
(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.
(Assignee)

Comment 19

10 years ago
Created attachment 281242 [details] [diff] [review]
drag-n-drop patch v.2

Added drop target support for inter-application and desktop -> application drag image support, and cleanup.
Attachment #281225 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #281242 - Flags: review?(dougt)
(Assignee)

Comment 20

10 years ago
Created attachment 281254 [details]
tab drag screenshot
(Assignee)

Comment 21

10 years ago
Created attachment 281286 [details] [diff] [review]
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.
(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).
(Assignee)

Comment 24

10 years ago
>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?
 
(Assignee)

Comment 25

10 years ago
> 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.
(Assignee)

Updated

10 years ago
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.
(Assignee)

Comment 30

10 years ago
Created attachment 281389 [details] [diff] [review]
drag-n-drop path v.4

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.
(Assignee)

Comment 35

10 years ago
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.
(Assignee)

Comment 36

10 years ago
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.
(Assignee)

Comment 37

10 years ago
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 40

10 years ago
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-
(Assignee)

Comment 41

10 years ago
will do. I'll try to get another patch posted later today.
(Assignee)

Comment 42

10 years ago
Created attachment 282155 [details] [diff] [review]
drag-n-drop path v.5
Attachment #281389 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #282155 - Flags: review?(emaijala)
(Assignee)

Comment 43

10 years ago
>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.
(Assignee)

Comment 44

10 years ago
Created attachment 282318 [details] [diff] [review]
drag-n-drop v.6

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

Comment 45

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

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

Comment 46

10 years ago
Created attachment 282991 [details] [diff] [review]
drag-and-drop path v.7

updated
Attachment #282155 - Attachment is obsolete: true
Attachment #282318 - Attachment is obsolete: true
Attachment #282991 - Flags: review?(emaijala)
Attachment #282155 - Flags: review?(emaijala)
(Assignee)

Comment 47

10 years ago
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)
(Assignee)

Comment 48

10 years ago
Created attachment 282993 [details] [diff] [review]
drag-and-drop path v.7

updated
Attachment #282993 - Flags: review?(emaijala)

Comment 49

10 years ago
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 50

10 years ago
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-
(Assignee)

Comment 51

10 years ago
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. 
(Assignee)

Comment 52

10 years ago
never mind, really tall images seem off. I'll take a look.
(Assignee)

Comment 53

10 years ago
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.
(Assignee)

Comment 55

10 years ago
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.
(Assignee)

Comment 57

10 years ago
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?
(Assignee)

Comment 58

10 years ago
Created attachment 284328 [details] [diff] [review]
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.
Attachment #282993 - Attachment is obsolete: true
(Assignee)

Comment 59

10 years ago
Created attachment 284330 [details]
mozilla.org header drag screenshot
(Assignee)

Updated

10 years ago
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 62

10 years ago
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+
(Assignee)

Updated

10 years ago
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-
(Assignee)

Comment 64

10 years ago
>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.
(Assignee)

Comment 66

10 years ago
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. :)
(Assignee)

Comment 67

10 years ago
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.
(Assignee)

Comment 68

10 years ago
Created attachment 285378 [details]
cross platform scaling

current scaling without native scaling code.
Attachment #281226 - Attachment is obsolete: true
Attachment #284330 - Attachment is obsolete: true
(Assignee)

Comment 69

10 years ago
Created attachment 285379 [details] [diff] [review]
drag-and-drop path v.9
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.

(Assignee)

Comment 72

10 years ago
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.
(Assignee)

Comment 75

10 years ago
Created attachment 285902 [details] [diff] [review]
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
Attachment #285379 - Attachment is obsolete: true
Attachment #285902 - Flags: superreview?(roc)
Attachment #285379 - Flags: superreview?(roc)
(Assignee)

Updated

10 years ago
Attachment #285902 - Flags: approval1.9?
Attachment #285902 - Flags: superreview?(roc) → superreview+

Updated

10 years ago
Keywords: helpwanted
Target Milestone: mozilla1.9 M8 → ---

Updated

10 years ago
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+
(Assignee)

Updated

10 years ago
Priority: -- → P2

Comment 77

10 years ago
Is this targeted for B2?
Any reason why this wasn't landed yet?
(Reporter)

Updated

10 years ago
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
Last Resolved: 10 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

Updated

10 years ago
Depends on: 404702

Updated

10 years ago
Depends on: 405089

Updated

10 years ago
Depends on: 406084

Updated

10 years ago
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.
(Assignee)

Comment 83

10 years ago
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.

Updated

9 years ago
Depends on: 420070
Depends on: 441420

Updated

9 years ago
No longer depends on: 441420
Depends on: 457803
Depends on: 470532
No longer depends on: 470532
QA Contact: drag-drop
(Assignee)

Updated

5 years ago
Blocks: 732733
You need to log in before you can comment on or make changes to this bug.