646361 - No focus event fired on document when focus is set to the document while focused in a plugin

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

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 (:asurkov)]

Attachment: 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 (:asurkov)]

(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]]

(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]

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 (:asurkov)]

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 (:asurkov)]

fixed by bug 673958

Comment 7

[Marco Zehe (:MarcoZ)]

Jamie, can you verify that this is fixed in the 2011-09-29 nightly build or later?

Comment 8

[James Teh [:Jamie]]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1