Closed
Bug 634719
Opened 13 years ago
Closed 12 years ago
destination receives dragleave event after (instead of before) source receives dragend
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: karlt, Assigned: karlt)
Details
Attachments
(2 files, 2 obsolete files)
1.42 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
8.49 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
This behaves correctly according to W3C spec, and a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=619703
Comment 2•12 years ago
|
||
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.
Assignee | ||
Comment 3•12 years ago
|
||
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.
Assignee | ||
Updated•12 years ago
|
Attachment #607431 -
Flags: review?(roc)
It would be good to write a test here.
Assignee | ||
Comment 5•12 years ago
|
||
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.
Maybe that's not worth the effort.
Assignee | ||
Comment 7•12 years ago
|
||
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.
Attachment #609616 -
Flags: review?(roc)
Assignee | ||
Comment 8•12 years ago
|
||
There is a modification from the previous version to ensure that EndDragSession happens.
Attachment #607431 -
Attachment is obsolete: true
Attachment #609618 -
Flags: review?(roc)
Assignee | ||
Updated•12 years ago
|
Attachment #609616 -
Attachment description: don't start a new source drag session until the previous has completed → part 1: don't start a new source drag session until the previous has completed
Assignee | ||
Updated•12 years ago
|
Attachment #609618 -
Flags: review?(roc)
Attachment #609616 -
Flags: review?(roc) → review+
Assignee | ||
Comment 9•12 years ago
|
||
Should also ensure that SourceEndDragSession doesn't run twice. A drag-end signal follows a drag-failed signal.
Attachment #609991 -
Flags: review?(roc)
Assignee | ||
Updated•12 years ago
|
Attachment #609618 -
Attachment is obsolete: true
Attachment #609991 -
Flags: review?(roc) → review+
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb870a2d03f7 https://hg.mozilla.org/integration/mozilla-inbound/rev/c0a2d79ca66d
Target Milestone: --- → mozilla15
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/bc7ea0e82d83
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/eb870a2d03f7 https://hg.mozilla.org/mozilla-central/rev/c0a2d79ca66d
You need to log in
before you can comment on or make changes to this bug.
Description
•