Ensure that windowed plugins get focus during WM_MOUSEACTIVATE. This fixes...

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
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=5178

[amit, 2008-11-10 22:46:19]

LGTM

[ananta, 2008-11-11 00:13:43]

Updated this CB to add a fix for the menu selection issues as reported in bug
http://code.google.com/p/chromium/issues/detail?id=937. Please take another
look.

On 2008/11/10 22:46:19, amit wrote:
> LGTM

[amit, 2008-11-11 00:18:48]

ok