Issue 4273: At times, keyboard events are not received by windowed plugins when it enters a modal loop. http://code.google.com/p/chromium/issues/detail?id=4273
Comment #3 by [EMAIL PROTECTED]: Fixed on trunk Revision: 5178 Changed files: chrome/browser/render_widget_host_view_win.cc Comments: 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 Issue attribute updates: Status: Fixed -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
