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.

i think this is bug 78414.. Peter , can u pls verify?

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.

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

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.)

Nominating - Major section 508 issue

Plussing, per ADT triage

reassigning to accesibility folks, please see comment #4

-> saari, for triage

->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?

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.)

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?

Setting to ADT 3, this can follow 78414.

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?

How is the plugin supposed to communicate that the user "tabbed out" back to the browser?

Created an attachment containing a proposal for communication between browser and plugins regarding tabbing.

This is critical for section 508 compliance, and accessibility.

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 :-) lguarino@adobe.com -> Loretta's email.

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

removing the nsbeta1+, marking -

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

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.

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.

*** Bug 148774 has been marked as a duplicate of this bug. ***

nominating: would be good for buffy, and good for affected embedded apps like chimera.

this is in the planning phase and will not make it for buffy

We still need this for section 508. Very important! Peter, what are your plans for this?

This is being planned for post buffy, the plan of action is to address this soon after that timeframe

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.

See also bug 78414, application shortcut commands don't work when plugin has focus.

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.

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.

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.

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?

The proposal in attachment 77684 [details] looks like a good start. But I've got some questions: 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)

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.

> 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 order. > 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 plugin? > 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.

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

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.

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?

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.

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.

moving to 1.3 beta

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.

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. -Robin

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. -Robin

*** Bug 306294 has been marked as a duplicate of this bug. ***

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).

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: http://xstandard.com/misc/mozilla/tab/1/NPXStandard.dll There is the markup to launch the plug-in: <object type="application/x-xstandard" width="100%" height="400"> <param name="Value" value="Hello World!" /> </object>

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

*** Bug 321625 has been marked as a duplicate of this bug. ***

switching depends on from bug 140566 to bug 78414 (which 140566 was duped on)

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.

Checking in again - can we get support for this enabled by 2008 for the next major release of Flash Player?

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.

In Italy accessibility is law since August 2005. We have developed a java video player named VideoVista. http://www.vista.it 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 .

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.

Many thanks to all FireFox developers.

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.

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.

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...

There is a specification addressing this problem here: https://wiki.mozilla.org/Plugins:AdvancedKeyHandling

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? 1] https://addons.mozilla.org/en-US/firefox/addon/4319

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). PLEASE FIX!! Thanks, -pt

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.

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 9.3.0.148 under Windows XP SP3.

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 ;-) Cheers, ^s

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 ;-) Cheers, ^s

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??

(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 https://bugzilla.mozilla.org/page.cgi?id=etiquette.html §1 ¶1.

Is it possible to fix this issue with Windows API: AttachThreadInput()? http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms681956(v=vs.85).aspx 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. Thanks!

No, attached input queues are unrelated to this bug (although they may be responsible for another set of hangs, see bug 818059).

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

Related https://bugzilla.mozilla.org/show_bug.cgi?id=78414 ?

Hi, 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 https://wiki.mozilla.org/NPAPI:AdvancedKeyHandling 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. https://bugzilla.mozilla.org/show_bug.cgi?id=78414 * There is no way to get focus from a plugin using the keyboard. https://bugzilla.mozilla.org/show_bug.cgi?id=93149 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 Ephox