Closed
Bug 93149
Opened 23 years ago
Closed 3 years ago
[meta] No way to move focus between plugin and browser from keyboard
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
INVALID
People
(Reporter: lguarino, Unassigned)
References
(Blocks 1 open bug, )
Details
(4 keywords, Whiteboard: [PL2:P1])
Attachments
(1 file)
2.10 KB,
text/plain
|
Details |
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 2•23 years ago
|
||
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?
Reporter | ||
Comment 4•23 years ago
|
||
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•23 years ago
|
||
Nominating - Major section 508 issue
Comment 6•23 years ago
|
||
Plussing, per ADT triage
Comment 7•23 years ago
|
||
reassigning to accesibility folks, please see comment #4
Assignee: av → aaronl
Component: Plug-ins → Keyboard Navigation
QA Contact: shrir → sairuh
Updated•23 years ago
|
Comment 9•23 years ago
|
||
->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
Reporter | ||
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Setting to ADT 3, this can follow 78414.
Assignee: beppe → peterl
Whiteboard: [ADT3]
Comment 13•23 years ago
|
||
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•23 years ago
|
||
How is the plugin supposed to communicate that the user "tabbed out" back to the
browser?
Comment 15•23 years ago
|
||
Created an attachment containing a proposal for communication between browser
and plugins regarding tabbing.
Comment 16•23 years ago
|
||
This is critical for section 508 compliance, and accessibility.
Severity: major → critical
Whiteboard: [ADT3] → [ADT1]
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
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
Comment 20•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 148774 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Priority: -- → P1
Whiteboard: [PL2:P1]
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Comment 24•22 years ago
|
||
nominating: would be good for buffy, and good for affected embedded apps like
chimera.
Comment 25•22 years ago
|
||
this is in the planning phase and will not make it for buffy
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → mozilla1.2beta
Comment 26•22 years ago
|
||
We still need this for section 508. Very important!
Peter, what are your plans for this?
Comment 27•22 years ago
|
||
This is being planned for post buffy, the plan of action is to address this soon
after that timeframe
Comment 28•22 years ago
|
||
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•22 years ago
|
||
See also bug 78414, application shortcut commands don't work when plugin has focus.
Comment 30•22 years ago
|
||
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.
Reporter | ||
Comment 31•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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)
Reporter | ||
Comment 35•22 years ago
|
||
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•22 years ago
|
||
> 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.
Comment 37•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Updated•22 years ago
|
Target Milestone: mozilla1.2beta → mozilla1.3alpha
Comment 43•22 years ago
|
||
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•20 years ago
|
||
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
Comment 45•20 years ago
|
||
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
Updated•20 years ago
|
Keywords: helpwanted
Comment 46•19 years ago
|
||
*** Bug 306294 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Target Milestone: Future → mozilla1.9beta
Updated•19 years ago
|
Whiteboard: [PL2:P1] → [PL2:P1] [ Too difficult to change for Mozilla1.8 ]
Comment 47•19 years ago
|
||
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•19 years ago
|
||
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>
Comment 49•19 years ago
|
||
(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.
Updated•19 years ago
|
Assignee: peterl-bugs → mats.palmgren
Status: ASSIGNED → NEW
Comment 50•19 years ago
|
||
*** Bug 321625 has been marked as a duplicate of this bug. ***
Comment 51•18 years ago
|
||
switching depends on from bug 140566 to bug 78414 (which 140566 was duped on)
Updated•18 years ago
|
Flags: blocking1.9a1?
Updated•18 years ago
|
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]
Comment 52•18 years ago
|
||
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•18 years ago
|
||
Checking in again - can we get support for this enabled by 2008 for the next major release of Flash Player?
Updated•18 years ago
|
Comment 54•18 years ago
|
||
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•18 years ago
|
||
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 .
Comment 56•18 years ago
|
||
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•18 years ago
|
||
Many thanks to all FireFox developers.
Comment 58•17 years ago
|
||
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•17 years ago
|
||
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.
Updated•17 years ago
|
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 ]
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1-
Updated•16 years ago
|
Flags: wanted1.9.2?
Comment 61•16 years ago
|
||
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•16 years ago
|
||
There is a specification addressing this problem here:
https://wiki.mozilla.org/Plugins:AdvancedKeyHandling
Comment 63•15 years ago
|
||
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
Updated•15 years ago
|
QA Contact: bugzilla → keyboard.navigation
Updated•15 years ago
|
Assignee: matspal → joshmoz
Priority: P1 → --
Whiteboard: [PL2:P1] [ Too difficult to change for Mozilla1.8 ] → [PL2:P1]
Target Milestone: mozilla1.9alpha8 → ---
Comment 65•15 years ago
|
||
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
Comment 66•15 years ago
|
||
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•14 years ago
|
||
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.
Comment 68•13 years ago
|
||
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
Comment 69•13 years ago
|
||
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
Comment 70•13 years ago
|
||
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•12 years ago
|
||
(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.
Comment 72•12 years ago
|
||
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!
Comment 73•12 years ago
|
||
No, attached input queues are unrelated to this bug (although they may be responsible for another set of hangs, see bug 818059).
Comment 74•12 years ago
|
||
(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•11 years ago
|
||
Comment 76•10 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•6 years ago
|
Summary: No way to move focus between plugin and browser from keyboard → [meta] No way to move focus between plugin and browser from keyboard
Comment 77•6 years ago
|
||
Keywords: sec508
Comment 78•3 years ago
|
||
Plugins no longer exist.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•