User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322) Steps to reproduce: With focus on some control in the plugin - - minimize / restore the firefox window, our plugin loses focus - double click on the title bar to maximize the firefox window, again, plugin loses focus When I say plugin loses focus, I mean plugin has received a WM_KILLFOCUS msg and keyboard input is not being sent to the plugin window anymore. A mouse-click is needed to give focus to the plugin again. Inspect32 shows that the firefox main window is the one having focus / keyboard input This looks like a firefox bug. Expected results: When the window is maximized / restored, the plugin should get a WM_SETFOCUS msg so that it can restore focus to the child control (that had focus earlier)
I'm assuming this is the same focus issue you reported later on in bug 767871? If that's the case one of these should be closed.
No, this use case is completely different from bug 767871. 767871 is to do with a modal dialog box and focus issues with it. The current bug is with minimize / maximize / restore window causing focus lost with native controls rendered in the NPAPI plugin. At the core, however, it does seem that firefox does a 'bad' job of handling focus / activation around plugins rendered using native controls.
Does this only affect Firefox 10? Does it affect Nightly? Does it go as far back as Firefox 4?
Is this still an issue with the latest Firefox 24 /Flash 11.8 ?
I will close this issue due to lack of response from the reporter.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.