Closed Bug 424684 Opened 16 years ago Closed 16 years ago

GTK fires spurious drag exit event after a drop

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: neil, Assigned: neil)

References

()

Details

(Keywords: platform, platform-parity)

Attachments

(1 file)

nsEventStateManager fires a drag exit event after a drop. However the GTK code fires its own drag exit event. This confuses code that expects matching drag events. For instance, attachment 310239 [details] [diff] [review] in bug 420341 does not work on GTK builds. Note that it is possible to work around the problem (attachment 311270 [details] [diff] [review] does just that) but I don't think our events should differ between platforms.
Attached patch Proposed patchSplinter Review
Attachment #311282 - Flags: superreview?(roc)
Attachment #311282 - Flags: review?(roc)
Assignee: nobody → neil
Flags: blocking1.9?
'in‑testsuite=?':
I think checking what the events are and their order would be wanted, if possible.
For example, attachment 310239 [details] [diff] [review] in bug 420341 depends on getting only one DragExit event, and that it happens after the Drop event.
Flags: in-testsuite?
Keywords: platform, pp
Attachment #311282 - Flags: superreview?(roc)
Attachment #311282 - Flags: superreview+
Attachment #311282 - Flags: review?(roc)
Attachment #311282 - Flags: review+
Attachment #311282 - Flags: approval1.9?
Not blocking as it's not a regression.  Also, won't take the patch unless there are sufficient tests here per comment #2.
Flags: blocking1.9? → blocking1.9-
It seems that mochitest's synthesizeMouse is not sufficient to fool drag 'n drop.  I can trigger ondraggesture, but beyond that drag/drop code (conceivably in widget/) couldn't care less about the synthesized events (since it's working off the real cursor).
(In reply to comment #2)
>For example, attachment 310239 [details] [diff] [review] in bug 420341 depends on getting only one
>DragExit event, and that it happens after the Drop event.
If we check in that attachment with this patch, that could then become a litmus test in SeaMonkey for this bug; would that suffice?
Comment on attachment 311282 [details] [diff] [review]
Proposed patch

a=beltzner
Attachment #311282 - Flags: approval1.9? → approval1.9+
Sure, describing a Litmus case is fine ... just make sure to do it :)
Flags: in-litmus?
Fix checked in.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I added this as litmus testcase 5274
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: