Fix un-processed drag events not being handled on OSX.

When a QDragMoveEvent is posted, we have to notify Chromium, and wait
synchronously, for the possible drag and drop action at the respective
coordinates. This is done by executing an inner event loop.

The drag move event was processed in the inner event loop as a
side-effect, specifically when another event (like a QMouseMove or
QKeyPress) was forwarded to Chromium, which in turn called DoWork
implicitly.

The side effect led to incorrect behavior, when the
mouse button is released and the drag operation should be finished.

What actually happened is that additional queued DragMove events
were being sent by OSX after the mouse release, and the process
was stuck in the inner event loop, because Chromium's DoWork was
never called. And only after moving the mouse a bit (and thus
forwarding MouseMove events), the inner event loop was quit, and
the drag operation finished.

To actually make Chromium handle the DragMove event, we have to
manually call DoWork on the inner event loop.

Also because the possible drag and drop action is sent via IPC from the
render process to the main process, there is a race condition that the
the message might not be handled on the first manual call of DoWork,
so we set up a QTimer to continuously call DoWork, thus polling for
the message. Once the message is handled, the timer is stopped. In
practice this leads to at most two timer timeouts.

Change-Id: I8dc37a9c47ea5b675e15ebd138bc0e616b522049
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>

0 files changed, 0 insertions, 0 deletions