destination receives dragleave event after (instead of before) source receives dragend

RESOLVED FIXED in mozilla15

Status

()

Core
Widget: Gtk
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: karlt, Assigned: karlt)

Tracking

Trunk
mozilla15
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

7 years ago
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

6 years ago
This behaves correctly according to W3C spec, and a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=619703

Comment 2

6 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

5 years ago
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.
Assignee: nobody → karlt
Status: NEW → ASSIGNED
Attachment #607431 - Flags: review?(roc)
(Assignee)

Updated

5 years ago
Attachment #607431 - Flags: review?(roc)
It would be good to write a test here.
(Assignee)

Comment 5

5 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

5 years ago
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.
Attachment #609616 - Flags: review?(roc)
(Assignee)

Comment 8

5 years ago
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.
Attachment #607431 - Attachment is obsolete: true
Attachment #609618 - Flags: review?(roc)
(Assignee)

Updated

5 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

5 years ago
Attachment #609618 - Flags: review?(roc)
Attachment #609616 - Flags: review?(roc) → review+
(Assignee)

Comment 9

5 years ago
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.
Attachment #609991 - Flags: review?(roc)
(Assignee)

Updated

5 years ago
Attachment #609618 - Attachment is obsolete: true
Attachment #609991 - Flags: review?(roc) → review+
(Assignee)

Comment 10

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb870a2d03f7
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0a2d79ca66d
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/bc7ea0e82d83
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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.