Need mouse-pointer coordinates in the dragend event

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
P1
normal
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: mano, Assigned: enndeakin)

Tracking

({verified1.9.1})

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

In order to make the tab-to-window code a bit more encapsulated and much less buggy (esp. in order to implement behaviors as described in bug 465332 comment 9), I need screenX and screenY data for the dragend event, currently they're set to 0. I suppose a side effect might be negative clientX and clientY data when the drag ends outside the window, is that OK?
Flags: blocking1.9.1?
Version: unspecified → Trunk
Screen coordinates of what? The dragend doesn't occur at a specific point, it just fires on an element.
Wherever the mouse was released (as with dragover).
Blocks: 465186
This is fairly simple for drops on the same window (assuming that the drop event coordinates are correct).

For drops on a different window, this is a bit harder due to the possibility of the coordinates/scales being different.

I can't answer how feasible this is for drops on other applications. It depends on whether the OS provides this information.

Whether an element should be able to receive coordinates outside its window is another question.
Neil: we're looking for the screen co-ordinates from the operating system, I think, so that we can position the new window from a tear-off-tab.
Flags: blocking1.9.1? → blocking1.9.1-
I don't need this immediately anymore (but it could certainly help a little, thus I'm keeping the bug open).
Assignee: mano → nobody
Status: ASSIGNED → NEW
OK, I have a simple implementation on Mac, but it doesn't look to be possible to get the final coordinate on Linux or Windows when dropping on another application. I thought I had seen a means on Windows, but can't see it anymore. On Windows, at least, a hack might be to just get the current mouse position. Maybe Jim might know more.
(In reply to comment #8)
> OK, I have a simple implementation on Mac, but it doesn't look to be possible
> to get the final coordinate on Linux or Windows when dropping on another
> application. I thought I had seen a means on Windows, but can't see it anymore.
> On Windows, at least, a hack might be to just get the current mouse position.
> Maybe Jim might know more.

After we drop out of DoDragDrop we can get the cursor position in screen coordinates using GetCursorPos. There's some async code in there I'd have to look at to see where it comes into play. In typical drops though I don't believe it has any effect.
Can't see a means to get the drag end position on Linux, but this works on Windows and Mac (although on Mac, the upper-left corner of the image is used rather than the mouse pointer position).

Changes the drag service api a bit, although not functions anyone should be calling.
Mano, does this patch work in some way for you?
I didn't test this yet, but this is the sort of change that I cannot rely on at all if it's not implemented on all supported platforms.
Vlad: can we reconsider blocking here, as this really makes tab-drag-and-drop a lot easier for Mano to execute on, which is a blocker.
Flags: blocking1.9.1- → blocking1.9.1?
Assignee: nobody → enndeakin
Attachment #357967 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #371873 - Flags: superreview?(roc)
Attachment #371873 - Flags: review?(joshmoz)
Attachment #371873 - Flags: review?(joshmoz) → review+
Attachment #371873 - Flags: superreview?(roc) → superreview+
Why can't we get the current pointer position on X and use that just like we do for Windows?
Posted patch linux patchSplinter Review
Attachment #372433 - Flags: superreview?(roc)
Attachment #372433 - Flags: review?(roc)
Attachment #372433 - Flags: superreview?(roc)
Attachment #372433 - Flags: superreview+
Attachment #372433 - Flags: review?(roc)
Attachment #372433 - Flags: review+
Comment on attachment 372433 [details] [diff] [review]
linux patch

+    if (GDK_IS_DISPLAY(display)) {

I don't think we need this.

One thing I just noticed in the original patch that we should fix: mEndDragPoint and SetDragEndPoint should be nsIntPoint, since they're pixels.
This blocks a P1 blocker, and so is a P1 blocker. Is the patch safe for branch, or does it change interfaces?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Keywords: checkin-needed
Whiteboard: [needs 1.9.1 landing]
Enn: can we get this landed on trunk and branch today, please?
Whiteboard: [needs 1.9.1 landing] → [needs m-c, 1.9.1 landing]
Only the Linux patch (https://bugzilla.mozilla.org/attachment.cgi?id=372433) isn't checked in.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs m-c, 1.9.1 landing]
The linux patch was now checked into trunk (http://hg.mozilla.org/mozilla-central/rev/77a7c0eed364).
I see the windows+mac part going into 191 here:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c3ab13ffbcd8

but no 191 changeset for the linux part yet. Is this really fixed1.9.1?
I haven't checked that in to 1.9.1 yet. The linux part probably should have been a different bug or have some indicator on the first patch that means 'fixed1.9.1'.
Neil, what blocks landing this on the branch?
Depends on: 488984
I've now checked in the linux fix.
The 1.9.1 checkin for this bug (which purportedly caused the Txul regression) was http://hg.mozilla.org/releases/mozilla-1.9.1/rev/970bee033ed0

Looks like the only changes in that cset that could affect WinXP are the s/nsPoint/nsIntPoint/ changes.... that doesn't seem particularly significant, but perhaps our nsPoint code was slightly more efficient or something?
The patches here only run when dragging which cannot be done without human intervention, so the performance tests shouldn't be exercising this code.
Open this file and drag the div at the top of the page, you should get an alert telling you where the drag ended.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090702 Minefield/3.6a1pre
and
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

V. Fixed
Status: RESOLVED → VERIFIED
Nochum, those bugs should be verified on all platforms not only windows. I did this for OS X and Linux with your testcase. It looks good. Verified fixed too.
Flags: in-testsuite?
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.