diff options
| author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-04 16:38:23 +0000 |
|---|---|---|
| committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-04 16:38:23 +0000 |
| commit | 6837cf8e48f577f215bee763f080cb737c2fdf2f (patch) | |
| tree | dcc2584d7825a32e1509cc6c77bd4c79c8991596 /site_scons/site_tools | |
| parent | a513227838d8b0b8b6d6d4289f2e9d35c7630266 (diff) | |
| download | chromium_src-6837cf8e48f577f215bee763f080cb737c2fdf2f.zip chromium_src-6837cf8e48f577f215bee763f080cb737c2fdf2f.tar.gz chromium_src-6837cf8e48f577f215bee763f080cb737c2fdf2f.tar.bz2 | |
One more attempt at fixing the keyboard focus issue when the windowless Flash plugin puts up a context
menu and we click on the browser window.
The Flash plugin at times sets focus to its hidden popup window with class name SWFlash_PlaceholderX
in the context of the TrackPopupMenu call. This causes the browser ui thread to receive a WM_ACTIVATEAPP
message indicating that another top level window has become active, which causes this issue. This also
happens in Firefox at times. However in Firefox the popup lives on the ui thread and hence the sideeffect
is that no window has keyboard focus.
Our workaround/fix for this scenario is to identify when this occurs and send over a raw mousedown/mouseup
event via SendInput to the last focus window.
Fixes http://code.google.com/p/chromium/issues/detail?id=8988
Bug=8988
Review URL: http://codereview.chromium.org/119049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17636 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'site_scons/site_tools')
0 files changed, 0 insertions, 0 deletions