Last Comment Bug 646361 - No focus event fired on document when focus is set to the document while focused in a plugin
: No focus event fired on document when focus is set to the document while focu...
Status: VERIFIED FIXED
: access, regression
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: mozilla10
Assigned To: alexander :surkov
:
Mentors:
Depends on: 673958
Blocks: focuseventa11y
  Show dependency treegraph
 
Reported: 2011-03-30 00:06 PDT by James Teh [:Jamie]
Modified: 2011-10-04 17:07 PDT (History)
3 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test plugins (421 bytes, text/html)
2011-09-16 04:34 PDT, alexander :surkov
no flags Details

Description James Teh [:Jamie] 2011-03-30 00:06:30 PDT
Str:
1. In Firefox >= 4, open a page which embeds a plugin.
2. Move focus inside the plugin.
3. Find the document accessible and set focus to it.
Expected: A focus event should be fired on the document accessible.
Actual: A focus event is fired on the top level Firefox frame accessible, but not on the document accessible.

This worked as expected in Firefox <= 3.6 because the document had its own HWND. Therefore, when focus was set to the document accessible, this caused the document HWND to be focused, which in turn caused Windows to fire a focus event on the document accessible because it is the client accessible for the document HWND. In Firefox >= 4, the document does not have its own HWND; there is only one HWND per browser window. The client accessible for this HWND is the top level Firefox frame accessible, so Windows fires a focus event for this. Unfortunately, nothing ever fires a focus event for the document accessible.

In NVDA, we've worked around this by faking a focus event when returning focus to the document, but this is hacky.
Comment 1 alexander :surkov 2011-09-16 04:34:38 PDT
Created attachment 560533 [details]
test plugins

(In reply to James Teh [:Jamie] from comment #0)
> Str:
> 1. In Firefox >= 4, open a page which embeds a plugin.
> 2. Move focus inside the plugin.

can you give me an example of plugin? I tried some testing plugins and can't reproduce

> 3. Find the document accessible and set focus to it.

set focus means call accSelect(SELFLAG_TAKEFOCUS) or something else?
Comment 2 alexander :surkov 2011-09-16 04:39:42 PDT
(In reply to alexander surkov from comment #1)
> Created attachment 560533 [details]
> test plugins
> 
> (In reply to James Teh [:Jamie] from comment #0)
> > Str:
> > 1. In Firefox >= 4, open a page which embeds a plugin.
> > 2. Move focus inside the plugin.
> 
> can you give me an example of plugin? I tried some testing plugins and can't
> reproduce

I can, DOM focus is fired but no accessible focus event.
Comment 3 James Teh [:Jamie] 2011-09-16 04:49:43 PDT
(In reply to alexander surkov from comment #1)
> can you give me an example of plugin?
Windowed Flash... but I'm guessing this isn't relevant now given comment #2.

> > 3. Find the document accessible and set focus to it.
> set focus means call accSelect(SELFLAG_TAKEFOCUS)
Yes.
Comment 4 Rudi Sherry 2011-09-20 09:07:25 PDT
This is happening for non-embedded plug-ins (i.e. URL directly to a PDF), and even if they're non-accessible.  Here's a recipe:

0. Install Adobe Reader (any version 9 or greater)
1. Go to <http://acroeng.adobe.com/formstestsuites/PDFs/PingForm.pdf>
2. Click in the orange "You may type..." and type: characters are input
3. Click on some other application to app-blur Firefox
4. Click on the Firefox app again anywhere (in the title bar or in the orange box or anywyhere) to app-focus it.

...can't type into the orange box until you click on the light-blue box then the orange box.

I've debugged this to: when Firefox loses focus all our HWNDs lose focus out from under our windowed plugin; when Firefox regains the focus it does not fire anything through the NPAPI plugin to tell us that we should focus again, nor does the OS notify us.

We hacked this in <=3.6 by subclassing the main Firefox window and pre-patching the APPRESUME message.  On app-blur we remembered the focus'ed HWND (if it was in our windowed plugin tree) and on app-focus we explicitly sent it a WM_FOCUS message.

We can't do that in >=4.0 because we're out-of-proc.

I would expect that NPP_HandleEvent(.. WM_SETFOCUS.. ) or something like that to fire, or maybe Firefox would do the same as our patch and use OS calls to reset the focus to what it was.

Is there some workaround?
Comment 5 alexander :surkov 2011-09-20 21:53:59 PDT
Rudi, you should file new bug under Plug-ins component since the problem you describe is different from (or wider than) AT support.
Comment 6 alexander :surkov 2011-09-28 02:26:33 PDT
fixed by bug 673958
Comment 7 Marco Zehe (:MarcoZ) 2011-09-29 07:57:54 PDT
Jamie, can you verify that this is fixed in the 2011-09-29 nightly build or later?
Comment 8 James Teh [:Jamie] 2011-10-04 17:07:16 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1

Note You need to log in before you can comment on or make changes to this bug.