Last Comment Bug 93149 - No way to move focus between plugin and browser from keyboard
: No way to move focus between plugin and browser from keyboard
Status: NEW
: access, helpwanted, meta, sec508, topembed-
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: All All
-- critical with 72 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
: 148774 306294 321625 330412 401972 (view as bug list)
Depends on: 181177 330411 491141 PluginShortcuts 348279
Blocks: focusnav fox3key 58997 75785 grouper
  Show dependency treegraph
Reported: 2001-08-01 15:23 PDT by Loretta Guarino Reid
Modified: 2016-09-17 16:49 PDT (History)
86 users (show)
bmo: wanted1.9.2?
benjamin: blocking1.9.1-
pavlov: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Proposal for tabbing integration with plugins (2.10 KB, text/plain)
2002-04-04 11:44 PST, Deneb Meketa
no flags Details

Description User image Loretta Guarino Reid 2001-08-01 15:23:43 PDT
For accessibility purposes, it is required that all functionality be accessible 
from the keyboard. When we load a PDF file in the browser, it gets focus, and we 
can invoke all the Acrobat keyboard functions. However, there is no way to use 
keyboard commands to move focus back to the browser so that we could, for 
instance, invoke one of Mozilla's menu commands, or type in a new target 
location. If we move focus to the Search box by clicking with the mouse, there 
is no way to use keyboard commands to get focus back into Acrobat and the PDF 
document. Ideally, the plugin would be one stop in the tab chain use to navigate 
focusable items in the browser.
Comment 1 User image shrirang khanzode 2001-08-01 15:27:28 PDT
i think this is bug 78414.. Peter , can u pls verify?
Comment 2 User image Peter Lubczynski 2001-08-01 15:47:10 PDT
Not quite a dup, IMO, but close.

Liz, if I understand you correctly, the Acrobat embedded window is not
participating in the accessibility tab chain.
Comment 3 User image lmcquarr 2001-08-01 15:53:55 PDT
Peter --

Loretta is actually the accessibility czarina here in Acrobat (be sure
to bow ... she is good!).

Comment 4 User image Loretta Guarino Reid 2001-08-01 16:06:14 PDT
That's correct, Peter. The Acrobat embedded window is not participating in the
accessibility tab chain. In addition, Acrobat needs some way to send focus back
to the tab chain (since once it has focus, it will interpret TAB in the Acrobat
context and take us to the next link or form field.) 
Comment 5 User image Aaron Leventhal 2002-02-27 01:33:48 PST
Nominating - Major section 508 issue
Comment 6 User image Aaron Leventhal 2002-02-27 12:55:34 PST
Plussing, per ADT triage
Comment 7 User image rubydoo123 2002-03-22 09:18:15 PST
reassigning to accesibility folks, please see comment #4
Comment 8 User image Aaron Leventhal 2002-03-25 14:28:19 PST
-> saari, for triage
Comment 9 User image saari (gone) 2002-03-25 14:38:44 PST
->beppe. Something we need to deal with... probably in the plugin code trapping
a special key. maybe a function key, maybe shift-tab, I dunno, I'm not the one
to make that call. How does IE do this?
Comment 10 User image Loretta Guarino Reid 2002-03-25 14:54:00 PST
Forgive me, I may not be using the correct terminology here. In IE, the Acrobat
plugin code that is running in the browser process is called when the IE tab
chain sets focus to its HWND. A message is then sent to the Acrobat process that
it should take focus. At that point, Acrobat is processing TAB keystrokes. When
Acrobat determines that it wants to send focus back to the browser (say, because
it has finished with its TAB chain), it sends a message back to the Acrobat code
in the browser, which sets focus to the original HWND. Then, when the browser
processes the next TAB, it resumes its TAB chain. (Ideally, we'd advance along
the TAB chain instead of setting focus to the HWND, but there was no obvious way
to do that.)
Comment 11 User image saari (gone) 2002-03-25 15:08:51 PST
Ah, okay. Are you guys sending a WM_FOCUS or a different Win32 message, or is
this something in the plugin API that isn't working right? 
Comment 12 User image rubydoo123 2002-03-27 14:22:53 PST
Setting to ADT 3, this can follow 78414.
Comment 13 User image Deneb Meketa 2002-04-01 20:16:17 PST
The Flash Player is also impacted by this limitation.  In NS4.x, Flash plug-ins 
were skipped entirely in the tabbing; in Mozilla 0.9.9 they seem to participate 
in the tab order, but only in a whole-object sense, and with no highlight.

I am guessing that whatever is done in Mozilla, the Flash Player plugin will 
need to be revved before it cooperates properly.  Please keep me informed as to 
what methods of communication develop.  We would love to solve this problem.

I would like to emphasize two things:

1. It is important that, on both the into-plugin and out-of-plugin side, there 
be a way to distinguish between tab and shift-tab, so that tabbing works 
correctly in either direction.  If key events are being passed, this is taken 
care of, but if some higher-level semantic thing is going on, it needs to 
include information about tabbing direction in some way.

2. It would be very nice to skip the state where an entire plugin is selected, 
proceeding directly from a focusable HTML element to a focusable element within 
a plugin or vice versa.  In other words, an apparent seamless relationship 
between the focusable elements in the HTML page and the focusable elements in 
the plugin.  If we can't get rid of the entire-plugin focus state, then I would 
strongly suggest we arrange for that state to have some visual feedback - a 
visible selection rectangle around the plugin.

Also, I have discovered that when I move the focus from an HTML element to a 
Flash element or vice versa (using the mouse), there are often two blinking 
text carets showing at the same time, which is definitely wrong.  Should this 
be a separate bug?
Comment 14 User image Peter Lubczynski 2002-04-03 17:16:17 PST
How is the plugin supposed to communicate that the user "tabbed out" back to the
Comment 15 User image Deneb Meketa 2002-04-04 11:44:55 PST
Created attachment 77684 [details]
Proposal for tabbing integration with plugins

Created an attachment containing a proposal for communication between browser
and plugins regarding tabbing.
Comment 16 User image Aaron Leventhal 2002-04-04 13:45:17 PST
This is critical for section 508 compliance, and accessibility.
Comment 17 User image lmcquarr 2002-04-05 08:09:54 PST
Hi Folks: 

Accessibility is very important to us in Acrobat Land
and we have more than a few years
of experience making it happen.  Loretta Guarino Reid is our
accessibility czarina and she and I will be meeting next week
so I can translate what she recommends to some thing associated
with the plug-in interface and living in the browser (we will
also take a look at the proposal.)   Please
do not hesitate to ask for help here.  We will do the best
we can (given the other stuff we have on our plates :-) -> Loretta's email.
Comment 18 User image rubydoo123 2002-04-08 11:54:10 PDT
This will involve modifying the API, which at this point in the cycle is just 
too risky to do. This will have to be moved to 1.0.1. I am removing the [ADT1] 
keyword and reassignng to 1.0.1
Comment 19 User image rubydoo123 2002-04-15 15:43:55 PDT
removing the nsbeta1+, marking -
Comment 20 User image saari (gone) 2002-04-15 17:01:53 PDT
Not fixing this comprimises our accessibility story for all plugins... we may
have to fix this on the 1.0 branch even post mach v
Comment 21 User image John Gaunt (redfive) 2002-04-23 17:33:03 PDT
This is a really crucial issue for accessiblity. Especially as plugins get more
complicated and interactive. Flash has form controls now and we don't have a
way, besides the mouse, of focusing them. I also see no way to tab around the
controls when viewing full page pdf file with the Adobe Plugin, only scrolling
of the page seem available from the keyboard.

Comment 22 User image Peter Lubczynski 2002-04-23 18:27:53 PDT
I am also concerned about getting focus back from the plugin. Notice in Flash
form testcases, once clicking inside the plugin you can tab around but never
back to the browser.

Perhaps we could "set focus" on the plugin for its turn in the tab chain but I'm
worried that some plugins might break the rest of the chain.

Comment 23 User image R.K.Aa. 2002-06-07 01:04:00 PDT
*** Bug 148774 has been marked as a duplicate of this bug. ***
Comment 24 User image sairuh (rarely reading bugmail) 2002-07-30 13:32:26 PDT
nominating: would be good for buffy, and good for affected embedded apps like
Comment 25 User image rubydoo123 2002-07-30 13:52:55 PDT
this is in the planning phase and will not make it for buffy
Comment 26 User image Aaron Leventhal 2002-08-13 23:18:07 PDT
We still need this for section 508. Very important!

Peter, what are your plans for this?
Comment 27 User image rubydoo123 2002-08-14 07:17:50 PDT
This is being planned for post buffy, the plan of action is to address this soon
after that timeframe
Comment 28 User image Aaron Leventhal 2002-09-03 19:55:52 PDT
I want to escalate this, it's been marked topembed+ for some time, and we need
it for Buffy to be accessible. It's urgent.
Comment 29 User image Aaron Leventhal 2002-09-06 11:41:38 PDT
See also bug 78414, application shortcut commands don't work when plugin has focus.
Comment 30 User image Aaron Leventhal 2002-09-06 11:51:27 PDT
Loretta, Deneb - do you have any new info on this? We're looking closely at the
problems now. Do your plugins still have problems interacting with the focus and
keyboard shortcuts in IE and Opera? If you have something that already works,
we'd like to piggyback on that.
Comment 31 User image Loretta Guarino Reid 2002-09-06 18:59:50 PDT
Aaron, I think it is going to take active cooperation from the plugin to make
this work. You may be able to force focus to the plugin when you reach it in the
tab chain (if you can tell whether it even takes focus), but I don't think
you'll be able to force it back from the plugin without cooperation. When
working with IE, we monitor SetFocus on our window in the tab chain within the
browser, and send focus to Acrobat. When Acrobat decides to send focus back to
the browser, it sets focus to that window in the tab chain. This is less that
ideal, because when the focus is on that window, it isn't obvious to the user
where it is. There is no visual feedback. 
Comment 32 User image Deneb Meketa 2002-09-06 19:09:08 PDT
Aaron - have you reviewed my attachment to this bug?  It outlines a solution 
for cooperation between plugins and the browser using an extension to the 
NPAPI.  I agree with Loretta: I don't think this problem can be solved unless 
the browser and plugins actively cooperate.  Also please review my comment #13, 
which is still entirely applicable.
Comment 33 User image Aaron Leventhal 2002-09-06 21:03:09 PDT
Yes Deneb, thank you - let me make sure we go over your submissions thoroughly.

Peterl, Serge - would you evaluate how we can use Deneb's ideas for Gecko?
Comment 34 User image Peter Lubczynski 2002-09-09 16:05:04 PDT
The proposal in attachment 77684 [details] looks like a good start. But I've got some

1. How is the plugin going to pass an event to the browser to notify that it
should take focus?
2. How does the browser capture events sent to the plug-in window?
3. How does the browser know which keys to process and which to forward to the
plug-in? (belongs with bug 78414)
Comment 35 User image Loretta Guarino Reid 2002-09-09 16:20:08 PDT
The Acrobat plugin implements a complex UI. I think we will continually run into
problems if the browser is filtering the keystrokes that reach the plugin when
the plugin has focus. At the very least, avoiding the keystrokes reserved by
various browsers will seriously impact the keyboard control possible within the
Acrobat application (since we'll want to be consistent whether we are running in
the browser or not). I'd rather see a clean negotiation of who has focus, than a
continuing monitoring of keystrokes by the browser to decide which to pass
through. If the browser needs to reserve some keystrokes, it should be as
conservative as possible.
Comment 36 User image Deneb Meketa 2002-09-09 16:55:00 PDT
> 1. How is the plugin going to pass an event to the browser to 
> notify that it should take focus?

Hmmm.  I think my original intention was that the browser would always capture 
the tab key, and send advanceFocusEvent, and a return of 1 from the plugin 
would indicate "I have tabbed out, please take the focus back".  However, I 
guess maybe the plugin has to actually *take* real input focus when it receives 
getFocusEvent, which would take the browser out of the event loop, unless we 
want to do some trick like spying on the child window messages - is that 
possible and reasonable?  If not, we would need to add something like 
NPN_TakeFocus that the plugin could call when it reaches the end of its tab 

> 2. How does the browser capture events sent to the plug-in window?

Yeah, I think this is the same question I just asked above.  How does it work 
in NN 4.7?  I can click inside a plugin, type into the plugin, and then press 
Ctrl+S and the NN Save dialog pops up.  Isn't this exactly what we are asking 
about?: the plugin has focus, but the browser is somehow intercepting events?  
Or is it maybe that the browser has kept focus and is forwarding events to the 

> 3. How does the browser know which keys to process and which 
> to forward to the plug-in? (belongs with bug 78414)

Hmmm.  Loretta makes a good point that plug-ins have more freedom if they 
receive all events, but that does make for an inconsistent browser user 
experience.  It seems to me that the best solution is to go with a "most local" 
rule: if the plugin attaches a particular meaning to a key combination, then 
when the plugin has focus, it should get that key event.  But otherwise the 
browser should get it.  In theory, the plugin should return something from its 
event handler that indicates whether it consumed the event or not.  But if 
we're dealing with keyboard events at the OS level, that may not be reliable; 
plugins might just always say yes, I handled it, which is no good.  If we 
introduce an NPAPI-level way of sending keyboard events to plugins, then people 
could be encouraged to make a careful decision as to whether to say the event 
was consumed or not.  But maybe that's too much hassle and somebody just needs 
to make an executive decision that There Are Certain Key Events That The 
Browser Always Gets.  Hopefully this is a stable list of key combinations; it 
would be more annoying if user prefs in the browser could cause new key 
combinations to not reach the plugin.
Comment 37 User image Aaron Leventhal 2002-09-09 17:08:40 PDT
I can think of at least one nice thing about letting the plugin decide what keys
to use or not use. If there's a key the plugin doesn't need (PgUp/PgDn for a
plugin that doesn't scroll), the plugin can decide to not swallow that and let
us use it (in this case to scroll the web page). Otherwise even plugins that
never scroll would impede the user's ability to use that key.

On the other hand, like Deneb says, that may lead to a feeling of inconsistency.


Here's a list of keys that I would like to see us always get. This should help
give more of a feeling what the splitup might be. Nothing to greedy here, I
don't think :)

Key          Function
---          --------
Ctrl+Tab   - prev/next tab
Ctrl+L     - location bar
Ctrl+M     - new mail
Ctrl+N     - new nav window
Ctrl+O     - open file
Ctrl+Q     - quit
Ctrl+R     - reload
Ctrl+T     - open new tab
Ctrl+W     - close window
Ctrl+digit - switch to another app in suite
F5         - reload
F6         - prev/next frame
F9         - toggle sidebar
F10        - main menu
F11        - full screen
All Alt+keys - menus, back, forward, etc.
Alt by itself - main menu


And are are the keys that I have purposefully left out:

Key      What it normally does in browser
---      --------------------------------
Ctrl+A - select all
Ctrl+B - bookmark management
Ctrl+C - copy
Ctrl+D - bookmark
Ctrl+E - edit this page
Ctrl+F - find
Ctrl+G - find next
Ctrl+H - history
Ctrl+I - page information
Ctrl+J - nothing
Ctrl+K - nothing
Ctrl+P - print
Ctrl+S - save
Ctrl+U - view source
Ctrl+V - paste
Ctrl+X - cut
Ctrl+Y - redo
Ctrl+Z - undo
F1     - help
F2     - nothing
F3     - find next
F4     - nothing
F7     - nothing
F8     - nothing
pgup   - navigation
pgdn   - navigation
home   - navigation
end    - navigation
arrows - navigation
tab    - navigation

Comment 38 User image Aaron Leventhal 2002-09-09 17:23:37 PDT
Hmm.. what if 
1) the browser first took the keystrokes that it really must have, such as
Ctrl+L for location bar, Alt+letter for menus 
2) the plugin then picked from the leftover keystrokes, consuming the ones it needs
3) the browser gets to use the leftover keystrokes the plugin didn't want

This would allow the browser to ensure minimal keyboard functionality for
itself, without taking away the ability for the plugin to use most of the keys
it needs. And, it still has the advantage of letting the browser use keys like
PgUp/PgDn that specific plugins don't care about.
Comment 39 User image Deneb Meketa 2002-09-09 17:28:54 PDT
Aaron's proposal, in theory, sounds good to me.  But still, I think in order 
for this to work, we would have to either introduce a new NPP/NPN mechanism for 
passing events back and forth, or rely on existing OS-level event handler 
routines to return an appropriate value.  I think the former sounds like a lot 
of work, and the latter sounds like it's bound to encounter overly greedy 
plugin implementations (although that's not to say they couldn't be fixed).

I think the larger problem is still: what is the mechanism for cooperating with 
regard to focus, and tab-key events?
Comment 40 User image Peter Lubczynski 2002-09-09 17:45:58 PDT
Perhaps the plugin could call something like NPN_SetValue when its time to
continue the browser's tab chain. When it comes time for the plug-in to take
focus, maybe the browser can send an event through NPP_HandleEvent or a WM event?

Taking control of keys like CTRL+L may rob a plugin of some ability. Alt+ keys
may be a bit safter as they somehow worked in 4.x although I could forsee a
Shockwave game or Java applet possibly needing those.
Comment 41 User image timeless 2002-09-09 19:26:58 PDT
going from the bottom of aaron's greedy browser keystroke list to the top

1. we should surrender all fkeys, if a java app wants to be a vt100 terminal
emulator or whatever, we should allow it. While a plugin is focussed and you're
playing a game, the last thing you want is for the sidebar to pop open, so
sidebar keybinding is definitely out. If someone wants to trigger fullscreen,
they can use the menus or select chrome first.

2. we should surrender ctrl+number, we really don't need it, anyone who needs to
trigger another app in our suite can (a) use the mouse, or (b) focus chrome and
then trigger it.
3. surrender: Ctrl+Q, Ctrl+R, Ctrl+T, Ctrl+W. these each cause too much jumping,
damage, and/or disruption. the user can rely on some other mechanism to trigger
chrome and then use them.
4. surrender: Ctrl+M, Ctrl+N. these are not important to a user who is focussed
on a plugin. the user can rely on some other mechanism to trigger chrome and
then use them.

How many plugins need escape? if plugins don't seem to need escape, then i'd
propose that we use escape to change keyboard focus from the plugin as a
focussed object to the plugin as a selected object (we can use ie's masking
approach or somethign else, it doesn't matter much).

My greedy list appears to be:
Ctrl+Tab, Alt with or without other keys, and Escape.

The only other two keys I didn't take off the greedy list are Ctrl+L and Ctrl+O,
however I'm not attached to them and I agree with peterl that stealing them from
plugins can be problematic (pico w/o ctrl-o is useless).

Total keys stolen by browser: 2, total keystrokes: 1-3.
Comment 42 User image rubydoo123 2002-12-03 15:53:02 PST
moving to 1.3 beta
Comment 43 User image Peter Lubczynski 2002-12-05 15:34:32 PST
per beth, setting topembed- and nsbeta1-

I'm changing this to a META beta as we'll need to implement this differently on
each toolkit. I've already opened bug 181177 about having ALT keys give focus
back to the browser on Win32.
Comment 44 User image Robin Lee Powell 2004-12-06 11:09:34 PST
I *think* this is the right bug to mention this in.  When a PDF is loaded in
*any* tab in FireFox, using alt-tab to get back to FireFox after being in
another window causes a return to FireFox with no keyboard commands (typing,
alt-anything, etc) to work at all.  This is with a PDF in the background, but
not the current tab.

Reproducible every time, Win2K, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0.

Comment 45 User image Robin Lee Powell 2004-12-06 11:10:00 PST
I *think* this is the right bug to mention this in.  When a PDF is loaded in
*any* tab in FireFox, using alt-tab to get back to FireFox after being in
another window causes a return to FireFox with no keyboard commands (typing,
alt-anything, etc) to work at all.  This is with a PDF in a tab, but not the
current tab.

Reproducible every time, Win2K, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0.

Comment 46 User image Michael (GoodWill) 2005-08-29 00:58:08 PDT
*** Bug 306294 has been marked as a duplicate of this bug. ***
Comment 47 User image Masatoshi Kimura [:emk] 2005-10-30 10:20:25 PST
We can tabbing into plug-in from Gecko now.
But tabbing from plug-in to Gecko requires plug-in's cooperation.
When plug-in wants to keep focus, it should consume key events not to call previous WinProc (in case windowed plug-in) or to return true from NPP_HandleEvent (in case windowless plug-in or Mac).
When plug-in wants to give up focus (i.e. it reaches the end of its tab 
order), it should ignore key events to call previous WinProc (in case windowed plug-in) or to return false from NPP_HandleEvent (in case windowless plug-in or Mac).
Some plug-ins, however, do not follow this rule. for example, Flash Player always consume events in windowed mode, and it always ignore events in windowless mode.
We may need a NPP_SetValue flag to determine whether plug-in follows the strict event consuming rule. Otherwise, bug 60102 will regress.
Plus, we need to notify keypress events to plug-in (see bug 312920).
Comment 48 User image Vlad Alexander 2005-10-31 06:20:53 PST
What build is this fixed in? I could not get this working in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051030 Firefox/1.6a1" using our plug-in XStandard with this build:

There is the markup to launch the plug-in:

<object type="application/x-xstandard" width="100%" height="400">
	<param name="Value" value="Hello World!" />
Comment 49 User image Masatoshi Kimura [:emk] 2005-10-31 06:31:40 PST
(In reply to comment #48)
At present, you will need tabindex="0" because of fix for bug 309704.
We can't enable tabbing into plugin by default until we support tabbing out.
Comment 50 User image Aaron Leventhal 2006-04-17 08:14:11 PDT
*** Bug 321625 has been marked as a duplicate of this bug. ***
Comment 51 User image Marc Bejarano 2006-06-15 09:05:13 PDT
switching depends on from bug 140566 to bug 78414 (which 140566 was duped on)
Comment 52 User image Jeff Mott 2006-08-17 10:37:18 PDT
What is the status of this work please?  We at Adobe are starting work on the next major rev of the Flash player, and we'd very mich like to get seamless tabbing working.
Comment 53 User image Jeff Mott 2007-01-09 17:12:35 PST
Checking in again - can we get support for this enabled by 2008 for the next major release of Flash Player?
Comment 54 User image Nathan Derksen 2007-02-01 09:24:03 PST
I second the request as well. This is really too important to leave untouched. Our ability to use Flash for web applications depends on being able to sell it as an accessible solution.
Comment 55 User image Fabio Busa 2007-02-08 02:17:40 PST
In Italy accessibility is law since August 2005.

We have developed a java video player named VideoVista.
Our first step is accessibility using keyboard and now it works with Java JVM 1.5.0_10 on IE6 and IE7.

As videos are so preeminent in nowdays, like accessibility, fix this bug will be a great goal for us, and for people who want / must / have to see and use video only with keyboard using Firefox, that is consider a web site proof of usability / accessibility .
Comment 56 User image Aaron Leventhal 2007-03-08 07:21:23 PST
Oliver Yeoh has posted docs and a patch to solve this and other plugin focus/keynav issues in bug 348279. Please take a look at the new API recommendations if you are a plugin developer.
Comment 57 User image Fabio Busa 2007-03-20 03:43:57 PDT
Many thanks to all FireFox developers.
Comment 58 User image Mats Ahlgren 2007-07-21 14:08:15 PDT
I would like to echo that the suggestion posted by Aaron Leventhal on 2002-09-09 17:08:40 PDT seems like "the right way" -- namely, at the very least whatever you do, a certain set of prominent modifier+keys combos (e.g. tab-cycling, moving to the next form element, etc.) should be untrappable and unclaimable by plugins.

The rationale is thus: 1) You don't want to confuse users. 2) You don't want to trust 3rd-party code not to bug-up your core functionality. 3) You want to be accessible, which relies on #2.
Comment 59 User image Aaron Leventhal 2007-07-23 01:17:05 PDT
Status report:

Any real work for plugin keyboard issues is occuring in bug 348279.
However, unfortunately work is stalled as the developer who was working on it no longer responds to pings.
Comment 60 User image Aaron Leventhal 2007-11-01 07:05:01 PDT
*** Bug 401972 has been marked as a duplicate of this bug. ***
Comment 61 User image Patrick H. Lauke 2009-02-11 16:49:16 PST
any activity on this in the foreseeable future? this is effectively stopping users that rely on keyboard access from using sites with so much as a simple embedded flash movie (even if the flash movie itself is actually keyboard-accessible itself). i understand that screenreaders running on top of firefox may fix this issue somehow (i seem to recall marco zehe mentioning something to that effect a while ago), but this still leaves keyboard users without such AT (with no sight impairments etc) high and dry...
Comment 62 User image Josh Aas 2009-03-20 12:42:08 PDT
There is a specification addressing this problem here:
Comment 63 User image Seth 2009-08-08 17:18:01 PDT
revisiting Comment #259 and Comment #260  from bug 78414

Could not Cycle Input focus [1], an AMO extension, be modified to take focus away from the offending (plugin) object such that CTRL+T will function as expected?

Comment 64 User image Mats Palmgren (:mats) 2009-08-26 16:47:51 PDT
*** Bug 330412 has been marked as a duplicate of this bug. ***
Comment 65 User image philiptdotcom 2009-12-01 13:34:27 PST
I just want to add my support to getting this problem fixed.  Seems to me to be a fundamental usability issue.  FF should be able to control any plugin it instantiates.  Users should be able to "get control" back to the original app (FF) via a keystroke.  There should be a way in FF to COMPLETELY (or selectively) DISABLE the "stealing" of keys by plugins.  At the very least, there needs to be ONE NON-OVERRIDABLE KEYSTROKE COMBO in ff whose sole purpose is to toggle control between the browser and the plugin (*OR* simply to TRANSFER CONTROL TO THE BROWSER [not a toggle]; which one--direct transfer or toggle--should be carefully considered.  Direct transfer is more straightforward, and would keep users from having to "guess" which entity will receive focus).


Thanks, -pt
Comment 66 User image Michal 'hramrach' Suchanek 2009-12-30 05:40:25 PST
Any progress on implementing this?

FWIW I would suggest amendment of the AKH proposal which does not really change the API but specifies behavior for non-compliant plugins.

0) a plugin is compliant if it implements NPPVSupportsAdvancedKeyHandling and returns true. It should be possible to blacklist plugins that appear compliant but cause keyboard navigation problems. In about:plugins and other plugin lists plugins implementing the new API should be indicated and there should be a checkbox to turn the new api off. It may be desirable to turn it on for legacy plugins and let them handle most key events (although they would just sink all key events and not return unused ones).

1) plugins that are compliant (and not blacklisted) should receive most keyboard events, only very few key combinations should be reserved to make it possible to escape the plugin should it crash or fail in some other way. Otherwise plugin can (and should) hand key events it does not care about and focus to to the browser using the new api.

2) legacy non-compliant plugins and blacklisted plugins should receive only key events that would not be used by the browser
 a) a plugin-only tab should receive keys that would be handled inside a HTML tab but not "browser global" keys - that is keys that would affect content outside tabs (bookmarks, sidebars, ...) switch tabs, close tabs, activate browser menu, etc. This should provide consistent user experience with and without plugins. Plugins which want to handle some keys that are not passed to legacy plugins should implement the new api and handle only the keys they require (or be blacklisted if they eat keys they don't use).
 b) in addition, a plugin embedded in a web page may not (perhaps as per a pref setting) receive the tab key (and make a single tab stop) nor do they receive scroll events (as are arrow keys, pgup/pgdn keys, mouse wheel events). However, plugins embedded in an additional iframe would receive scroll events as per plugin-only page.
Comment 67 User image Diomidis Spinellis 2011-02-20 23:49:41 PST
One can sidestep this bug as follows: Change application focus to another application with Alt-Tab and then return to the browser with Alt-Tab.  This restores the focus to the browser level.  Tested with Firefox 3.6.13, the Adobe Acrobat add-on under Windows XP SP3.
Comment 68 User image sphakka 2011-10-27 05:45:10 PDT
Hey, as a workaround, please, give us keyboard addicted ones an über-meta combination to focus back to the browser. f.i., CTRL+META+<configurable>. And you'll also spare a lot of RSI wrist pain to poor mouse dependent ones ;-)


Comment 69 User image sphakka 2011-10-27 05:47:06 PDT
Hey, as a workaround, please, give us keyboard addicted ones an über-meta combination to focus back to the browser. f.i., CTRL+META+<configurable>. And you'll also spare a lot of RSI wrist pain to poor mouse dependent ones ;-)


Comment 70 User image philiptdotcom 2012-06-08 12:29:42 PDT
Just wanted to point out that this has been on the books--and recognized as an important issue--for more than TEN YEARS.  Is anyone ever going to fix this FUNDAMENTAL problem??
Comment 71 User image Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention) 2012-09-05 16:05:35 PDT
(In reply to philiptdotcom from comment #70)
> Just wanted to point out that this has been on the books--and recognized as
> an important issue--for more than TEN YEARS.  Is anyone ever going to fix
> this FUNDAMENTAL problem??

The number of still open dependencies (i.e. bugs that this bug depends on) is proof enough that this bug isn't easy to fix — all those others will have to be fixed first.

Also, whining as in comment #70 is not contributing to help fix the bug — if anything, it adds to the chaff that developers must wade through before understanding the question — and should not have been made, see §1 ¶1.
Comment 72 User image 2012-11-17 23:47:26 PST
Is it possible to fix this issue with Windows API:
Using this API should make the OOPP plugin thread shares the same input handling with the main firefox process.
This works even for threads created in different processes so I think it should work for OOPP as well.

Comment 73 User image Benjamin Smedberg [:bsmedberg] 2012-12-04 08:00:40 PST
No, attached input queues are unrelated to this bug (although they may be responsible for another set of hangs, see bug 818059).
Comment 74 User image Jeff D 2012-12-20 19:40:58 PST
(In reply to Tony Mechelynck [:tonymec] from comment #71)
> The number of still open dependencies (i.e. bugs that this bug depends on)
> is proof enough that this bug isn't easy to fix — all those others will have
> to be fixed first.

What about a preference to keep plugins from taking focus unless explicitly assigned it (right click/hotkey/etc)? It wouldn't solve accessibility, but I know I'd be happy if firefox would just keep focus whenever I pause a flash video... and I would expect that much of that code could be reused in the final accessibility solution.
Comment 75 User image Patrick H. Lauke 2014-04-03 04:47:25 PDT
Related ?
Comment 76 User image dylan.just 2015-05-27 16:56:38 PDT

This bug has a major impact on our customers. Basically, if the user clicks in an input field, then our Java Applet, then clicks out to the field they were in, key events still go to the applet.

Here's Oracle's evaluation:

Although describes the 
methods for focus communication, they're never used. This specification also 
references these two bugs: 

* Plugins eat all key events when focused, the browser does not get a chance 
to process anything. 
* There is no way to get focus from a plugin using the keyboard. 

Either one is reported back in 2001, and neither is fixed so far. 

Without proper API, we can do nothing. Adobe Flash probably suffers 
the same problem. 

Testing with a modified Firefox plugin to provide 'gotfocus' and 'lostfocus' functions 
shows that they're never called by the browser. 

Searched for these function calls in Firefox search and found no usages except 
NPPluginFuncs structure initialization with NULL before the structure is passed 
to NP_GetEntryPoints function in plugin. 

In short, this bug cannot be fixed until the two Mozilla bugs referenced above are fixed. 
The likelihood of them being fixed is low since since Mozilla also has plans to drop NPAPI support. 

Kind regards,

Dylan Just
Senior Engineer

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