diff options
| author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-11-11 17:21:29 +0000 |
|---|---|---|
| committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-11-11 17:21:29 +0000 |
| commit | d0364b99e19f5bd2308003c27a2eabfa9248dd79 (patch) | |
| tree | 73bc79690f2c9d74cc302e1aa7f76e5da444d4ab /chrome/browser/tabs | |
| parent | 4d2b744be713c70827adf457bc7c8a08532f38d2 (diff) | |
| download | chromium_src-d0364b99e19f5bd2308003c27a2eabfa9248dd79.zip chromium_src-d0364b99e19f5bd2308003c27a2eabfa9248dd79.tar.gz chromium_src-d0364b99e19f5bd2308003c27a2eabfa9248dd79.tar.bz2 | |
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
Diffstat (limited to 'chrome/browser/tabs')
0 files changed, 0 insertions, 0 deletions