diff options
author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-07 00:53:28 +0000 |
---|---|---|
committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-07 00:53:28 +0000 |
commit | 29edb1760137085c0fd77e70fcffafb894ace0f2 (patch) | |
tree | e2bb1e2978ad762ca726556e4cdf788df1261bbd /win8 | |
parent | 029a00c5f6a820cf3f3d6baa607a012c48d0917a (diff) | |
download | chromium_src-29edb1760137085c0fd77e70fcffafb894ace0f2.zip chromium_src-29edb1760137085c0fd77e70fcffafb894ace0f2.tar.gz chromium_src-29edb1760137085c0fd77e70fcffafb894ace0f2.tar.bz2 |
Fix mouse locking in Chrome AURA Windows and ASH.
Mouse locking is used for e.g. by WebGL and is implemented in the browser by entering a state in the web view
where in we ensure that the mouse stays within the boundaries of the view and we send only mouse increment/decrement
information to the renderer.
We had support for this in Chrome AURA which did not work correctly due to a number of bugs.
1. We need to implement the MoveCursorTo override in the DesktopRootWindowHostWin, DesktopRootWindowHostX11 and
RemoteRootWindowHostWin classes which implement the aura RootWindowHost interface. In desktop Chrome windows we
invoke the SetCursorPos API to ensure that the cursor is set to the position specified. In desktop Chrome linux we
invoke the XWarpPointer API to achieve this. In ASH chrome on Windows we cannot call SetCursorPos in the
RemoteRootWindowHostWin class's implementation of the MoveCursorTo function.
As mouse input is received by the viewer process and sent to the browser, we have scenarios wherein we receive stale
mouse input from the viewer after invoking the SetCursorPos API in the browser. To workaround this we call SetCursorPos
API in the viewer process from an IPC MetroViewerHostMsg_SetCursorPos which is sent from the RemoteRootWindowHostWin::MoveCursorTo
function. We send out an ACK from the viewer process when the call finishes and in the meantime we ignore any mouse
messages coming from the viewer while we wait for the ACK.
If we don't do this then we have issues with the image locking up on screen in ASH. In the viewer process we also
send out a fake mousemove IPC after the SetCursorPos API as we don't receive the corresponding real mouse move for
some reason. This is needed as RVHAura class sets a flag which is reset when it receives the mousemove corresponding to
the cursor pos.
2. The RenderWidgetHostViewAura::ShouldMoveToCenter function which checks if the mouse cursor has moved beyond the window
bounds needs to convert the window rect to screen.
3. The MakeWebMouseEvent function in the web_input_Event_aura.cc file should use not set the globalX and globalY members in
the WebMouseEvent structure from the root coordinates if we have a native mouse event for Windows. This breaks the
lock mouse coordinate calculations.
I also fixed the implementation of the RootWindowHost::QueryMouseLocation function in the RemoteRootWindowHostWin class and
the DesktopRootWindowHostWin class. We can now safely enable the AshNativeCursorManagerTest.DisabledQueryMouseLocation test
with some windows specific fixes.
BUG=222497
R=cpu@chromium.org, palmer@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/14574010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@198582 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'win8')
-rw-r--r-- | win8/metro_driver/chrome_app_view_ash.cc | 24 | ||||
-rw-r--r-- | win8/metro_driver/chrome_app_view_ash.h | 1 |
2 files changed, 25 insertions, 0 deletions
diff --git a/win8/metro_driver/chrome_app_view_ash.cc b/win8/metro_driver/chrome_app_view_ash.cc index 8c296cc..f3a3a88 100644 --- a/win8/metro_driver/chrome_app_view_ash.cc +++ b/win8/metro_driver/chrome_app_view_ash.cc @@ -85,6 +85,7 @@ class ChromeChannelListener : public IPC::Listener { OnDisplayFileSaveAsDialog) IPC_MESSAGE_HANDLER(MetroViewerHostMsg_DisplaySelectFolder, OnDisplayFolderPicker) + IPC_MESSAGE_HANDLER(MetroViewerHostMsg_SetCursorPos, OnSetCursorPos) IPC_MESSAGE_UNHANDLED(__debugbreak()) IPC_END_MESSAGE_MAP() return true; @@ -133,6 +134,16 @@ class ChromeChannelListener : public IPC::Listener { title)); } + void OnSetCursorPos(int x, int y) { + VLOG(1) << "In IPC OnSetCursorPos: " << x << ", " << y; + ui_proxy_->PostTask( + FROM_HERE, + base::Bind(&ChromeAppViewAsh::OnSetCursorPos, + base::Unretained(app_view_), + x, y)); + } + + scoped_refptr<base::MessageLoopProxy> ui_proxy_; ChromeAppViewAsh* app_view_; }; @@ -525,6 +536,19 @@ void ChromeAppViewAsh::OnDisplayFolderPicker(const string16& title) { file_picker_->Run(); } +void ChromeAppViewAsh::OnSetCursorPos(int x, int y) { + if (ui_channel_) { + ::SetCursorPos(x, y); + DVLOG(1) << "In UI OnSetCursorPos: " << x << ", " << y; + ui_channel_->Send(new MetroViewerHostMsg_SetCursorPosAck()); + // Generate a fake mouse move which matches the SetCursor coordinates as + // the browser expects to receive a mouse move for these coordinates. + // It is not clear why we don't receive a real mouse move in response to + // the SetCursorPos calll above. + ui_channel_->Send(new MetroViewerHostMsg_MouseMoved(x, y, 0)); + } +} + void ChromeAppViewAsh::OnOpenFileCompleted( OpenFilePickerSession* open_file_picker, bool success) { diff --git a/win8/metro_driver/chrome_app_view_ash.h b/win8/metro_driver/chrome_app_view_ash.h index 1e9e601..0989cda 100644 --- a/win8/metro_driver/chrome_app_view_ash.h +++ b/win8/metro_driver/chrome_app_view_ash.h @@ -53,6 +53,7 @@ class ChromeAppViewAsh void OnDisplayFileSaveAsDialog( const MetroViewerHostMsg_SaveAsDialogParams& params); void OnDisplayFolderPicker(const string16& title); + void OnSetCursorPos(int x, int y); // This function is invoked when the open file operation completes. The // result of the operation is passed in along with the OpenFilePickerSession |