diff options
| author | estade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-02 20:33:47 +0000 |
|---|---|---|
| committer | estade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-02 20:33:47 +0000 |
| commit | 50a441d8fcc68babce2a7dc1fc373569c8326a2a (patch) | |
| tree | 5ffb68606a726f7e22032b96606f061f9bf06216 /chrome/renderer/extensions | |
| parent | 2fc90935ee2fb798829265ad145a15a36a56105a (diff) | |
| download | chromium_src-50a441d8fcc68babce2a7dc1fc373569c8326a2a.zip chromium_src-50a441d8fcc68babce2a7dc1fc373569c8326a2a.tar.gz chromium_src-50a441d8fcc68babce2a7dc1fc373569c8326a2a.tar.bz2 | |
GTK: when doing a drag from a web page, pass a recent mouse down to gtk_drag_begin() so it has a better idea what time to pass to gdk_grab_pointer().
I believe the following was happening:
- render view gets mouse down, forwards to webkit
- render view gets motion, forwards to webkit
- user releases mouse button, that event is added to the queue
- browser gets message from webkit that a drag has begun, calls gtk_drag_begin() with no event
- gtk_drag_begin initiates a cursor grab, but it only applies to events that have not yet been added to the queue
- mouse release comes up in queue; passed to render view rather than the drag widget
TEST=You can't get stuck in really short render view drags. Whereas it was really easy to repro before (especially in Xephyr), I can repro no longer.
BUG=http://crbug.com/15768
Review URL: http://codereview.chromium.org/150204
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19839 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/renderer/extensions')
0 files changed, 0 insertions, 0 deletions