Comment #9 on issue 13233 by [email protected]: Typing into Flash with wmode = opaque|transparent and non-latin language active outputs as if US keyboard layout active http://code.google.com/p/chromium/issues/detail?id=13233
I quickly investigated this issue today on my Windows PC. Technically, this issue consists of several problems. 1. The WebViewImpl class does NOT dispatch Char events to plug-ins. Flash expects a browser sends a WM_CHAR event through a NPP_HandleEvent() call when a browser sends a non-ASCII character. On the other hand, WebViewImpl::KeyEvent() always set | suppress_next_keypress_event_| to true to prevent Char events from being dispatched to plug-ins. This is because WebPluginContainerImpl::handleKeyboardEvent() calls Event::setDefaultHandled() even when WebPlugin::handleInputEvent() returns false, <http://b/1119691>. (Maybe, this is for preventing KeyDown events from being bubbled to ancestor nodes?) The simplest way to solve this issue is checking if the focused node is an object node in WebViewImpl::KeyEvent() to prevent it from setting |suppress_next_keypress_event_| to true when the focused node is an object node. (Even though this works OK on my Windows PC, I cannot ensure it fixes this problem WITHOUT ANY REGRESSIONS.) 2. Our WebKit APIs cannot handle Char events. It seems we just forgot adding handlers for Char events and it is easy to fix. Even though I have not investigated on Mac or Linux, we may need to dispatch such native events blocked by Chrome to plug-ins on Mac and Linux? Regards, -- 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 --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
