Closed Bug 1152300 Opened 9 years ago Closed 8 years ago
[e10s] Windowed Flash steals keyboard input targeted at content
Steps To Reproduce: 1. Open video(e.g. http://www.nicovideo.jp/watch/sm22991356 ) & play 2. Click comment field just below the video 3. Type any word in the comment field 4. Click "Video Reviews" textarea 5. Type any word in the textarea Actual results: Text appears in the comment field instead of the textarea Expected results: Text appears should appears in the textarea
it is necessary to login http://www.nicovideo.jp .
testcase: 1) wait for the flash editor to load 2) type some text in the flash editor (note the focus ring) 3) type some test in the text edit result: text input going to flash
Neil, curious what you think about this. The other location I can do this is in the focus manager where we have the previously focused content available. It seemed simpler to stick this in PuppetWidget. It's strange to me that SetFocus isn't implemented for PuppetWidget, but I guess that call is for shifting native focus around native widgets over on the chrome side. This bug represents one case where we want the focus change event forwarded over from content to chrome.
+ // For plugin puppet widgets (PluginWidgetProxy objects) on Windows and + // Linux: when focus moves from a plugin window to content elements we need + // to set focus to the top level native browser window so that the native + // child plugin window relinquishes focus. Normally, we focus the parent widget when blurring the plugin. This is done here: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager.cpp#1624 Do we need to focus the parent process widget here instead?
(In reply to Neil Deakin from comment #6) > + // For plugin puppet widgets (PluginWidgetProxy objects) on Windows and > + // Linux: when focus moves from a plugin window to content elements we > need > + // to set focus to the top level native browser window so that the native > + // child plugin window relinquishes focus. > > Normally, we focus the parent widget when blurring the plugin. This is done > here: > > http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager. > cpp#1624 > Do we need to focus the parent process widget here instead? Yeah, I think a call to my DispatchFocusToTopLevelWindow right there might accomplish the same. Unfortunately DispatchFocusToTopLevelWindow needed to be on in PBrowser so that it has has access to mFrameElement, which iti needed to get at the root parent widget. Maybe there's something similar to mFrameElement in PContent I can use.
Updated per your suggestion of moving this to the focus manager.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.