Last Comment Bug 634719 - destination receives dragleave event after (instead of before) source receives dragend
: destination receives dragleave event after (instead of before) source receive...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: mozilla15
Assigned To: Karl Tomlinson (:karlt)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-16 13:18 PST by Karl Tomlinson (:karlt)
Modified: 2012-05-02 21:15 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order (7.58 KB, patch)
2012-03-19 20:30 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
part 1: don't start a new source drag session until the previous has completed (1.42 KB, patch)
2012-03-26 22:24 PDT, Karl Tomlinson (:karlt)
roc: review+
Details | Diff | Splinter Review
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v2 (7.62 KB, patch)
2012-03-26 22:26 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v3 (8.49 KB, patch)
2012-03-27 20:25 PDT, Karl Tomlinson (:karlt)
roc: review+
Details | Diff | Splinter Review

Description Karl Tomlinson (:karlt) 2011-02-16 13:18:56 PST
In attachment 512731 [details], drag div A and drop onto div B (which doesn't accept the
drop).  Expected order of events is dragstart, dragenter, dragleave, dragend.
(See also bug 497498 comment 26.)

A GTK drag source sends the leave message to the destination before the
drag-end or drag-failed signal on the source widget, but the leave message
goes via the X server, and so doesn't get processed at least until the event
loop is run again.
Comment 1 Nathan Vander Wilt 2012-02-07 13:29:35 PST
This behaves correctly according to W3C spec, and a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=619703
Comment 2 Nathan Vander Wilt 2012-02-07 13:32:33 PST
Sorry, reading comprehension fail.

This is NOT a duplicate of 619703, which has to do with dragenter/dragleave (destinations). This ticket has to do with dragleave (destination) vs. dragend (source) and I'm not sure what the spec says regarding these.
Comment 3 Karl Tomlinson (:karlt) 2012-03-19 20:30:28 PDT
Created attachment 607431 [details] [diff] [review]
schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order

This patch applies on top of those in bug 497498.

The bug reported here happens when the target will not accept the drop so GTK gives us a source drag-end signal without a target drop.

RunScheduledTask will dispatch any necessary leave event.
Comment 4 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-20 16:11:58 PDT
It would be good to write a test here.
Comment 5 Karl Tomlinson (:karlt) 2012-03-20 19:12:05 PDT
Perhaps a unit test could dispatch fake GdkEvents to the event loop.
We may be able to use gtk_grab_get_current() to get the correct GdkWindow.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-20 19:30:28 PDT
Maybe that's not worth the effort.
Comment 7 Karl Tomlinson (:karlt) 2012-03-26 22:24:11 PDT
Created attachment 609616 [details] [diff] [review]
part 1: don't start a new source drag session until the previous has completed

There is an existing possibility that InvokeDragSession could be called before
a destination has replied to indicate that it has received a drop, and so
EndDragSession has not yet been called.

The next patch here will run EndDragSession off an event, which could make this
a little more likely.  The ideal fix is probably to have a separate drag
session object for each drag, but the simple defence is to avoid starting a new
session until the previous has completed.
Comment 8 Karl Tomlinson (:karlt) 2012-03-26 22:26:40 PDT
Created attachment 609618 [details] [diff] [review]
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v2

There is a modification from the previous version to ensure that EndDragSession happens.
Comment 9 Karl Tomlinson (:karlt) 2012-03-27 20:25:19 PDT
Created attachment 609991 [details] [diff] [review]
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v3

Should also ensure that SourceEndDragSession doesn't run twice.
A drag-end signal follows a drag-failed signal.

Note You need to log in before you can comment on or make changes to this bug.