Ensure that windowed plugins get focus during WM_MOUSEACTIVATE. This fixes

bug http://code.google.com/p/chromium/issues/detail?id=4273, which shows up
when windowed plugins enter modal loops like context menu and keyboard navigation
does not work in the menu.

We were not converting the coordinates returned by GetCursorPos to client coordinates correctly, which caused us to miss the child window (Plugin) at times.

This also fixes bug http://code.google.com/p/chromium/issues/detail?id=937, which was an issue with menu selections in Java menus. This occured because we would force 
the child window to have focus in every WM_MOUSEACTIVATE message. In this case the Java plugin window, which is a child of the plugin window already has focus. It receives a WM_KILLFOCUS message due to the forced SetFocus in our handler and takes out the menu, thus ignoring the menu selection. Fix for this issue is to handle WM_MOUSEACTIVATE only if a child window of RenderWidgetHostHWND does not have focus.

R=amit
Bug=4273

Review URL: http://codereview.chromium.org/10004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5178 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 20 insertions, 18 deletions

diff --git a/chrome/browser/render_widget_host_view_win.cc b/chrome/browser/render_widget_host_view_win.cc
index 3c86595..e24ecbe 100644
--- a/chrome/browser/render_widget_host_view_win.cc
+++ b/chrome/browser/render_widget_host_view_win.cc
@@ -779,25 +779,27 @@ LRESULT RenderWidgetHostViewWin::OnWheelEvent(UINT message, WPARAM wparam,
 
 LRESULT RenderWidgetHostViewWin::OnMouseActivate(UINT, WPARAM, LPARAM,
                                                  BOOL& handled) {
-  // We handle WM_MOUSEACTIVATE to set focus to the underlying plugin
-  // child window. This is to ensure that keyboard events are received
-  // by the plugin. The correct way to fix this would be send over
-  // an event to the renderer which would then eventually send over
-  // a setFocus call to the plugin widget. This would ensure that
-  // the renderer (webkit) knows about the plugin widget receiving
-  // focus.
-  // TODO(iyengar) Do the right thing as per the above comment.
-  POINT cursor_pos = {0};
-  ::GetCursorPos(&cursor_pos);
-  MapWindowPoints(m_hWnd, &cursor_pos, 1);
-  HWND child_window = ::RealChildWindowFromPoint(m_hWnd, cursor_pos);
-  if (::IsWindow(child_window)) {
-    ::SetFocus(child_window);
-    return MA_NOACTIVATE;
-  } else {
-    handled = FALSE;
-    return MA_ACTIVATE;
+  HWND focus_window = GetFocus();
+  if (!::IsWindow(focus_window) || !IsChild(focus_window)) {
+    // We handle WM_MOUSEACTIVATE to set focus to the underlying plugin
+    // child window. This is to ensure that keyboard events are received
+    // by the plugin. The correct way to fix this would be send over
+    // an event to the renderer which would then eventually send over
+    // a setFocus call to the plugin widget. This would ensure that
+    // the renderer (webkit) knows about the plugin widget receiving
+    // focus.
+    // TODO(iyengar) Do the right thing as per the above comment.
+    POINT cursor_pos = {0};
+    ::GetCursorPos(&cursor_pos);
+    ::ScreenToClient(m_hWnd, &cursor_pos);
+    HWND child_window = ::RealChildWindowFromPoint(m_hWnd, cursor_pos);
+    if (::IsWindow(child_window)) {
+      ::SetFocus(child_window);
+      return MA_NOACTIVATE;
+    }
   }
+  handled = FALSE;
+  return MA_ACTIVATE;
 }
 
 LRESULT RenderWidgetHostViewWin::OnGetObject(UINT message, WPARAM wparam,