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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: neil, Assigned: neil)
References
()
Details
(Keywords: platform, platform-parity)
Attachments
(1 file)
737 bytes,
patch
|
roc
:
review+
roc
:
superreview+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•16 years ago
|
||
Attachment #311282 -
Flags: superreview?(roc)
Attachment #311282 -
Flags: review?(roc)
Updated•16 years ago
|
Assignee: nobody → neil
Flags: blocking1.9?
Comment 2•16 years ago
|
||
'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.
Attachment #311282 -
Flags: superreview?(roc)
Attachment #311282 -
Flags: superreview+
Attachment #311282 -
Flags: review?(roc)
Attachment #311282 -
Flags: review+
Updated•16 years ago
|
Attachment #311282 -
Flags: approval1.9?
Comment 3•16 years ago
|
||
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-
Comment 4•16 years ago
|
||
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).
Assignee | ||
Comment 5•16 years ago
|
||
(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 6•16 years ago
|
||
Comment on attachment 311282 [details] [diff] [review] Proposed patch a=beltzner
Attachment #311282 -
Flags: approval1.9? → approval1.9+
Comment 7•16 years ago
|
||
Sure, describing a Litmus case is fine ... just make sure to do it :)
Flags: in-litmus?
Assignee | ||
Comment 8•16 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 9•16 years ago
|
||
I added this as litmus testcase 5274
You need to log in
before you can comment on or make changes to this bug.
Description
•