The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla10

Status

()

Core
Disability Access APIs
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access, regression})

Trunk
mozilla10
x86
Windows 7
access, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
(Assignee)

Updated

6 years ago
Blocks: 375743
(Assignee)

Comment 1

6 years ago
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?
(Assignee)

Comment 2

6 years ago
(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.
(Assignee)

Updated

6 years ago
Depends on: 673958
Flags: in-testsuite?
(Reporter)

Comment 3

6 years ago
(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

6 years ago
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?
(Assignee)

Comment 5

6 years ago
Rudi, you should file new bug under Plug-ins component since the problem you describe is different from (or wider than) AT support.
(Assignee)

Comment 6

6 years ago
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 7

6 years ago
Jamie, can you verify that this is fixed in the 2011-09-29 nightly build or later?
(Reporter)

Comment 8

6 years ago
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.