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)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15

People

(Reporter: karlt, Assigned: karlt)

Details

Attachments

(2 files, 2 obsolete files)

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.
This behaves correctly according to W3C spec, and a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=619703
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.
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: nobody → karlt
Status: NEW → ASSIGNED
Attachment #607431 - Flags: review?(roc)
Attachment #607431 - Flags: review?(roc)
It would be good to write a test here.
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.
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)
There is a modification from the previous version to ensure that EndDragSession happens.
Attachment #607431 - Attachment is obsolete: true
Attachment #609618 - Flags: review?(roc)
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
Attachment #609618 - Flags: review?(roc)
Should also ensure that SourceEndDragSession doesn't run twice.
A drag-end signal follows a drag-failed signal.
Attachment #609991 - Flags: review?(roc)
Attachment #609618 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/bc7ea0e82d83
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.