Closed Bug 93149 Opened 23 years ago Closed 2 years ago

[meta] No way to move focus between plugin and browser from keyboard

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: lguarino, Unassigned)

References

(Blocks 2 open bugs, )

Details

(4 keywords, Whiteboard: [PL2:P1])

Attachments

(1 file)

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?
Keywords: access
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
Keywords: fcc508, nsbeta1
Plussing, per ADT triage
Keywords: nsbeta1nsbeta1+, topembed
Target Milestone: --- → mozilla1.0
Blocks: 58997
reassigning to accesibility folks, please see comment #4
Assignee: av → aaronl
Component: Plug-ins → Keyboard Navigation
QA Contact: shrir → sairuh
Keywords: topembedtopembed+
Blocks: focusnav
-> saari, for triage
Assignee: aaronl → saari
->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?
Assignee: saari → beppe
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.
Assignee: beppe → peterl
Whiteboard: [ADT3]
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?
Blocks: 75785
Created an attachment containing a proposal for communication between browser
and plugins regarding tabbing.
This is critical for section 508 compliance, and accessibility.
Severity: major → critical
Whiteboard: [ADT3] → [ADT1]
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
Status: NEW → ASSIGNED
Whiteboard: [ADT1]
Target Milestone: mozilla1.0 → mozilla1.0.1
removing the nsbeta1+, marking -
Keywords: nsbeta1+nsbeta1-
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. ***
Priority: -- → P1
Whiteboard: [PL2:P1]
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
nominating: would be good for buffy, and good for affected embedded apps like
chimera.
Keywords: nsbeta1-nsbeta1
OS: Windows 98 → All
Hardware: PC → All
this is in the planning phase and will not make it for buffy
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.1alpha → mozilla1.2beta
We still need this for section 508. Very important!

Peter, what are your plans for this?
Keywords: nsbeta1-nsbeta1
Whiteboard: [PL2:P1] → [PL2:P1], need eta
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.
Target Milestone: mozilla1.2beta → mozilla1.3alpha
Blocks: grouper
moving to 1.3 beta
Target Milestone: mozilla1.3alpha → mozilla1.3beta
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.
Depends on: 181177
Whiteboard: [PL2:P1], need eta → [PL2:P1]
Target Milestone: mozilla1.3beta → Future
Depends on: 140566
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. ***
Target Milestone: Future → mozilla1.9beta
Whiteboard: [PL2:P1] → [PL2:P1] [ Too difficult to change for Mozilla1.8 ]
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.
Depends on: 330411
Assignee: peterl-bugs → mats.palmgren
Status: ASSIGNED → NEW
*** 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)
Depends on: PluginShortcuts
No longer depends on: 140566
Blocks: keya11y
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [PL2:P1] [ Too difficult to change for Mozilla1.8 ] → [PL2:P1] [ Too difficult to change for Mozilla1.8 ] [wanted-1.9]
Depends on: 348279
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?
Blocks: fox3key
No longer blocks: keya11y
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.
Flags: wanted1.9+
Whiteboard: [PL2:P1] [ Too difficult to change for Mozilla1.8 ] [wanted-1.9] → [PL2:P1] [ Too difficult to change for Mozilla1.8 ]
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1-
Flags: wanted1.9.2?
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
Depends on: 491141
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
QA Contact: bugzilla → keyboard.navigation
Assignee: matspal → joshmoz
Priority: P1 → --
Whiteboard: [PL2:P1] [ Too difficult to change for Mozilla1.8 ] → [PL2:P1]
Target Milestone: mozilla1.9alpha8 → ---
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
Assignee: joshmoz → nobody
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.
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
Component: Keyboard: Navigation → User events and focus handling
Summary: No way to move focus between plugin and browser from keyboard → [meta] No way to move focus between plugin and browser from keyboard

Plugins no longer exist.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: