Bug 78414 (PluginShortcuts)

Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus

RESOLVED FIXED in mozilla48

Status

()

defect
P3
major
RESOLVED FIXED
18 years ago
a year ago

People

(Reporter: dshultz, Assigned: masayuki)

Tracking

(Depends on 2 bugs, Blocks 4 bugs, 5 keywords)

Trunk
mozilla48
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(blocking2.0 -, relnote-firefox -)

Details

(Whiteboard: [triage][PL2:NA][READ COMMENT 638 BEFORE COMMENTING])

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
BuildID:    2001042508

When any Shockwave content is loaded in the current active 
frame/window, you cannot use any of the application keyboard functions 
such as command -Q or Command-W. Seems like when I did command 
Q on some movies, the plugin failed and I could no longer use the movie.

Reproducible: Always
Steps to Reproduce:
1. make sure you have the Shockwave plugin installed
2. go to the url above.
3. play the game for a second 
4. using the keyboard commands, try to close the window or quit the 
browser

Actual Results:  If I hit command - W, nothing happens. If I hit command - 
Q, the shockwave movie stops playing and the page has to be reloaded 
using the navigator bar button.  Even after you click to close the browser 
window, you still will not be able to use the keyboard command functions

Expected Results:  The movie should be able to play and the application 
keyboard commands should not be affected by Shockwave playback.
(Reporter)

Comment 1

18 years ago
Macromedia Bug 67613

Comment 2

18 years ago
I wonder if something to this effect would work: if any of the "modifier" keys 
are down, send that event to Moz instead of the plugin on Mac only. 

Keys should should work, especially after closing window. Taking bug.
Assignee: av → peterlubczynski
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: shockwave
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2

Comment 3

18 years ago
Okay, looked closer at this. There are two bugs here. First, "lost focus" wasn't 
working. Typo, should be using NS_CONTENT_BLUR instead of NS_LOSTFOCUS. Need 
to double check that it won't cause regressions on other platforms, but once 
that was fixed, one can click outside the plugin content area and then command 
keys work as expected. In fact, you could scroll the page with the keyboard and 
other key events seem to work.

The other problem is that the plugin was consuming all key events. Perhaps Peter 
G. from Macromedia knows if Shockwave returns consume status on keys like this 
or if Nav was responsible for filtering them out. 

Even after returning nsEventStatus_eIgnore from the DOM key event in 
nsObjectFrame.cpp if a "meta" key was down, it still looked like my event was 
consumed. Probably need to set some breakpoints in the EventStateManager. 
Pinkerton or Saari, do you have any tips on debugging this on the Mac? I wonder 
if there is a way to process shortcut keys before sending the event to the DOM.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.2 → mozilla0.9.1

Updated

18 years ago
Depends on: 78846
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

18 years ago
Keywords: 4xp, top100
OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 9

18 years ago
Refining the bug report, and giving the current status.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010810
BuildID:    081003

*After you click inside the flash plugin*, Mozilla stops receiving the keyboard
shortcut commands, like CTRL+L, ALT+F4, CTRL+2 (access mail), ALT+H (access help
menu), and any other key. If you click away from the Flash plugin (in the HTML
part of a mixed HTML/Flash page), the keys go back to working.

Reproducible: Always
Steps to Reproduce:
1. Load URL http://www.planetoftheapes.com/site_index.html
2. Click inside the Flash plugin, *giving it the focus*
3. Type CTRL+L, or ALT+F4

Actual Results:  CTRL+L or ALT+F4 won't have any effect.

Expected Results:  CTRL+L should direct me to URL Bar, ALT+F4 should close window.

Marcos.
Comment hidden (obsolete)

Updated

18 years ago
Keywords: access

Comment 11

18 years ago
Why keyword "access"?

"Bugs and enhancement requests related to making Mozilla accessible to users
with disabilities and special needs."

Doesn't seem to fit in this bug. It says disabilities *and* special needs. Not
"or", like in "disabilities or special needs, ie keyb shortcuts".

If I'm wrong, then maybe the description in
http://bugzilla.mozilla.org/describekeywords.cgi isn't well written.

I purpose removing keyword "access".

Marcos.

Updated

18 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

18 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

18 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Comment hidden (obsolete)

Updated

18 years ago
Summary: Application keyboard commands fail to operate during Shockwave playback → Application keyboard commands fail to operate during Shockwave Flash playback
Comment hidden (obsolete)

Updated

18 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment hidden (obsolete)

Comment 15

17 years ago
This only happens when the plugin has focus, right?  If not, my dups might be
incorrect.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

17 years ago
Whiteboard: [PL2:NA]
Sergey Lugenov has created a preliminary patch for a bug which seems to be a
dupe of this one, bug 95541.

Comment 20

17 years ago
This is very similar to bug 93149. This one is about app comands like Accel+L,
Accel+W, Alt+F working when the plugin has focus. Bug 93149 is about making the
plugin act as if it's a natural part of the tab order.
Summary: Application keyboard commands fail to operate during Shockwave Flash playback → Application keyboard commands fail to operate when plug-in has focus

Comment 21

17 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Topembed- as this is not currently needed by a major embedding customer.
Keywords: topembedtopembed-

Comment 23

17 years ago
Jaime, I think this should be topembed+
It's needed by all major embedding customers with accessibility requirements.
renominating. plugin content really does kill keyboard navigation.
Keywords: topembed-topembed
sairuh/aaron: do MSIE, 4.x or other browsers currently have this capability?

Comment 26

17 years ago
Yes, IE does.

Load a pdf file up and hit Alt+back arrow. You'll go back in history. 
Alt+D will focus the address bar
Alt+F will pull down the file menu
Ctrl+N will open a new browser window.

etc.

Comment 27

17 years ago
Yes, IE is able to process the top menu functions in some plug-ins. The current
plug-in architecture allows for the plug-in vendor to pass unwanted user
functions back to the browser. The npapi code does not analyze each keystroke on
the way to the plug-in. When the plug-in has focus, it has control of the
keystrokes. If the request here is to have the npapi code run an intermediate
layer between the browser and the plug-in and grab those keystrokes that the
browser knows and loves , then plug-ins will not be able to utilize those
functions because they will never reach the plug-in -- is that really what we
want to do here?

Updated

17 years ago
Target Milestone: mozilla1.2alpha → mozilla1.3alpha

Comment 28

17 years ago
What I suggest is that we identify a small handful of crucial keystrokes that we
never give the plugin. Perhaps only a single keystroke that means "Exit plugin".
It could be something uncommon. This way if the plugin swallows all keystrokes
there's still an escape hatch.

All other keystrokes get sent to the plugin, which can either use them or send
them back to us.

Updated

17 years ago
Keywords: topembedtopembed+
Comment hidden (obsolete)

Updated

17 years ago
Blocks: grouper
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 35

17 years ago
Adding nsbeta1+. Peter: we need to work with Aaron to chose a unique key
sequence to exit the plug-in, or ensure that the ALT+[key] is acceptable.
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 36

17 years ago
I nominate Shift+Escape, as a "focus the content window" key. 

Having such a key to focus the content window would be more generally useful
than just for leaving plugins. A user could hit Shift+Escape to unfocus a form
control, so that tabbing, typeaheadfind and other keys would be available. 

Comment 37

17 years ago
I am marking this as a dup of bug 181177. By providing an alt sequence to escape
the plug-in, the user will then have access to the window commands.

A somewhat realated bug is bug 93149, which is now a meta bug for additional
functionality.

*** This bug has been marked as a duplicate of 181177 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
bug 181177 seems to be an alternative for win32 (and maybe unix?) platforms, but
what about macintosh?

Comment 39

17 years ago
they are being covered sarah
mac is covered by bug 140566.

v dup.
Status: RESOLVED → VERIFIED

Comment 41

16 years ago
This bug covers shortcuts like Accel+L, whether or not we're in a full or
partial page plugin. There's no other bug covering that.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 42

16 years ago
Taking until we find out who/what/when/where/how, or if.

Perhaps the alt key solution will be good enough for the Windows platform. Not
sure what's being cooked up for Mac or Linux.
Assignee: peterlubczynski → aaronl
Status: REOPENED → NEW
Target Milestone: mozilla1.3beta → Future

Comment 43

16 years ago
On Windows, if a plugin wants to send shortcut keys to the browser, I wonder if
it can just get the browser's HWND through NPN_GetValue and call ::SendMessage
or if that will that just go back to the plugin? Need to try out idea in a
sample plugin.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla
Firebird/0.6.1

With Firbird, when I open a PDF file "Page Up", "Page Down" and cursor keys
doesn't work but ctrl-t work well. Plug is Adobe 4.0.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 61

15 years ago
the example url should be changed to remove top100 keyword - this isn't a bug
relating to cartoon network specifically but the general handling of shockwave
plugins

suggesting that http://www.shockwave.com/sw/home/ be used instead
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Summary: Application keyboard commands fail to operate when plug-in has focus → Application shortcut keys (keyboard commands such as f11, ctrl-t, ctrl-r) fail to operate when plug-in (flash, acrobat, quicktime) has focus
Comment hidden (obsolete)

Updated

15 years ago
Blocks: majorbugs
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Alias: PluginShortcuts
Summary: Application shortcut keys (keyboard commands such as f11, ctrl-t, ctrl-r) fail to operate when plug-in (flash, acrobat, quicktime) has focus → Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus

Comment 78

15 years ago
Note that the problem occurs only when the mouse pointer is in the plugin area.
The shortcuts do work when the pointer is in other parts of the browser window
(e.g., toolbar or menubar), or outside it. 
(Firefox 1.0, Linux, KDE 3.3)

Comment 79

15 years ago
(In reply to comment #78)
> Note that the problem occurs only when the mouse pointer is in the plugin area.
> The shortcuts do work when the pointer is in other parts of the browser window
> (e.g., toolbar or menubar), or outside it. 
> (Firefox 1.0, Linux, KDE 3.3)

Not really true, at least not on OS X 10.3.7:
The focus has to change. In the case of the flash plug-in, once it has focus,
one has to click somewhere else. Simply clicking somewhere in the bookmarks bar
or another toolbar wont' do. I found that clicking into the address field
removes focus from the flash plugin, as well as clicking in the html-area of a
site, if the plug-in doesn't take up the whole browser window.
Simply having the mouse cursor over another area won't do it.

Comment 80

15 years ago
On [Firefox 1.0, Linux, KDE 3.3], the behavior is exactly as described in
comment 78 (as opposed to comment 79)-- moving the cursor anywhere outside the
plugin area re-activates the shortcuts, regardless of mouseclicks. Yes, my kwin
is at the default click-to-focus setting (and not focus-follows-mouse).

Note that on the above setup, if press and hold down Ctrl while the mouse is
over the plugin area, move the mouse elsewhere, and then press "T" and release
both, then the Ctrl-T isn't registered as such. This may give a hint about the
layer in which the bug resides.

Comment 81

14 years ago
We're going to have to implement something like the following to get keyboard
accessibility working with plugins:
www.mozilla.org/access/plugins
Comment hidden (obsolete)

Updated

14 years ago
Depends on: 279532
windows XP - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5)
Gecko/20041121 Firefox/0.9.1+

my experience matches comment 79 - must click outside the area of the plugin,
i.e. anywhere in the html area outside the plugin.  Clicking URL area, any
toolbar area (including bookmarks) or menu does not suffice.  

HOWEVER, clicking the URL's tab does the trick.

Original URL no longer exists - replaced with
http://www.macromedia.com/software/flash/flashpro/video/gallery/ (which was
reported in bug 279532)

Updated

14 years ago
No longer depends on: 279532
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 87

14 years ago
*** Bug 287467 has been marked as a duplicate of this bug. ***
Comment hidden (obsolete)

Comment 89

14 years ago
On my Windows 2000, 1.0.3 machine, I have the same problem. Just thought I'd add
my $.02
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 92

14 years ago
Plugin work doc is now at:
http://www.mozilla.org/access/plugins-work

Updated

14 years ago
No longer blocks: majorbugs
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

14 years ago
No longer blocks: grouper

Updated

14 years ago
Blocks: 273456
Comment hidden (obsolete)

Comment 96

14 years ago
This even occurs if there is a flash animation in the page, but the flash plugin
is not installed, and the browser displays "Click here to download plugin" in
that place. When we get focus on that, there is no way to get out of it with
keyboard, TAB doesn't get the focus out of there. Testet in Deer Park Alpha 2
from Debian experimental.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
nominating for 2.0 (i know it's still quite some time), since it's quite confusing for my mum that she cannot open a new tab (ctrl+t) when she has a pdf loaded in her browser.
Flags: blocking-aviary2?

Comment 105

14 years ago
I'm using Firefox 1.5 RC2 on OS X and am still getting this problem. It's nice to at least know (after having read this bug report...) that if I select something else on the page that I can use the keys again.

Comment 106

14 years ago
Wow, this bug is closing in on 5 years old.

It seems to me that F11 should always work, like Alt-F4 and Alt-Tab.  If you are running a full screen SWF and go to full screen with View | Full Screen (F11 is ignored), the task bar becomes inaccessible, F11 doesn't work, and you can't exit in Windows without either:

- Alt-F4
- Windows key -> Right-clicking the application in the task bar -> Close

That makes for a pretty **** user experience.
Comment hidden (obsolete)

Comment 108

14 years ago
Here's a good example I found today:
http://media.putfile.com/Family-Guy-Does-Penut-Butter-Jelly-Time

Simply interact with the media control somehow (click play or stop).  Then try a FireFox command (Ctrl+T or Ctrl+D), and it will fail.  You can reactivate it by focusing back on the html or on a different tab.
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

14 years ago
Severity: normal → critical
Comment hidden (obsolete)
Flags: blocking-aviary2? → blocking1.8.1?

Comment 112

14 years ago
by the way, I'm not sure if Java content is regarded as plug-in related, but Java applets seem to do the same.

Comment 113

13 years ago
I'm looking at Adobe Reader 7.0 on Win XP.  In agreement with comment 83, I notice that it's unexpectedly hard to get focus back to Fx.

I can't regain focus by clicking anywhere on the Active Window bar at the top (including the minimize or maximize buttons!), the menu bar, the bookmarks shortcut bar, or the tool bar.  Not even the reload ikon will regain focus.  Are these not supposed to be active areas?

The only areas that work to regain focus are (1) the URL address or search engine box, the tabs, or a menu button.  Is this not a fixable (and maybe separate) bug?

Updated

13 years ago
Assignee: aaronleventhal → mats.palmgren
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 117

13 years ago
len@lencrockett.com please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html 
before posting comments to bugzilla.

Especially point 1.1, 1.2 and 1.3 maybe of interest to us.
Thank you :) 

Comment 118

13 years ago
Camino is able to process Cmd+` to switch between an application's windows when multiple Java applets are running, while Firefox is not.  Has anyone asked the Camino developers how they addressed the issue?  

Comment hidden (obsolete)
Aaron in comment #28:
> I suggest ... we identify a small handful of crucial keystrokes that
> we
> never give the plugin. Perhaps only a single keystroke that means "Exit
> plugin".
> It could be something uncommon. This way if the plugin swallows all keystrokes
> there's still an escape hatch.
> 
> All other keystrokes get sent to the plugin, which can either use them or send
> them back to us.

Why has this simple approach been abandoned when other more complex solutions (comment 27, comment 81) are years away judging by the long time lapse?  Why can't just a few basics be implemented (ctrl-N, ctrl-T, ctrl-L, ctrl-K) and allow it to be disabled for those that gotta have these for some odd plugin?

Can bug 181177 be duped to this?

As a side note this is one of 35 bugs marked top100 (for whatever that designation is worth) and not fixed. 77 top100 bugs (core+FF) have been fixed since this bug was so marked.
ctrl-N, ctrl-T, ctrl-L would be so great and good enough (can't see what ctrl-K stands for)
plus ctrl-U and ctrl-I ? 
(In reply to comment #121)
> ctrl-N, ctrl-T, ctrl-L would be so great and good enough (can't see what ctrl-K
> stands for)

ctrl-K is "search" (if you've put it in your tool bar)


> plus ctrl-U and ctrl-I ? 

not IMO if you're limiting to well used combos, one of which is ctrl-P (which I forgot)

Updated

13 years ago
Blocks: 93149

Comment 123

13 years ago
(In reply to comment #120)
> Can bug 181177 be duped to this?

that bug (and the presumably bit-rotted attached patch) is only to make alt-<key> shortcuts work.  i marked it as a blocker for this bug to keep them linked.
Depends on: 181177

Comment 124

13 years ago
Good news :) This and the other plugin focus/keynav bugs finally have an owner. Mats Palmgren just started working for Mozilla as a contractor and will be working on focus/keynav bugs. The plugin issues are a priority. Everyone can stop spamming the bug and worrying that the bugs aren't going to get fixed.
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

13 years ago
Flags: blocking1.9a1?

Comment 127

13 years ago
we'd like this but it needs a better design/idea on how this will work
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [PL2:NA] → [PL2:NA] wanted-1.9

Updated

13 years ago
Whiteboard: [PL2:NA] wanted-1.9 → [PL2:NA] [wanted-1.9]

Updated

13 years ago
Depends on: 348279
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

13 years ago
Summary: Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus → Application shortcut keys (keyommboard cands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus
Be careful with the summary please.
Summary: Application shortcut keys (keyommboard cands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus → Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus

Comment 133

13 years ago
Ctrl+w should be essential, especially in the case of adobe, where ctrl+w is supposed to close the current document anyway.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

12 years ago
Duplicate of this bug: 373471
Duplicate of this bug: 376356

Comment 139

12 years ago
After fixing this bug, would it be possible for a firefox extension to intercept all the keystrokes, even the ones that are pressed when the plugin is in focus ?

Updated

12 years ago
Blocks: 164421

Comment 140

12 years ago
(In reply to comment #139)

presumably, this depends on how it is "fixed" ;)

Updated

12 years ago
Duplicate of this bug: 384413
Duplicate of this bug: 390118

Updated

12 years ago
Duplicate of this bug: 390150

Updated

12 years ago
Duplicate of this bug: 394306
Blocks: 395980

Updated

12 years ago
Duplicate of this bug: 403119
Flags: wanted1.9+
Whiteboard: [PL2:NA] [wanted-1.9] → [PL2:NA]

Updated

11 years ago
Duplicate of this bug: 413756

Updated

11 years ago
Duplicate of this bug: 423117

Updated

11 years ago
Duplicate of this bug: 423927

Updated

11 years ago
Duplicate of this bug: 427274

Updated

11 years ago
Duplicate of this bug: 427635
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

11 years ago
Duplicate of this bug: 428949
Duplicate of this bug: 428911

Updated

11 years ago
Duplicate of this bug: 429028

Comment 159

11 years ago
On Mac, Firefox trunk has a similar problem (bug 428047).  For that platform, it's a recent regression.

Updated

11 years ago
Duplicate of this bug: 432283
Duplicate of this bug: 434720

Updated

11 years ago
Duplicate of this bug: 435180
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Or, for that matter, someone should document what expected behaviour is. Should plugin *and* browser receive key presses? Should plugin not?

Comment 168

11 years ago
comment 167 brings up a very good point.

This is a similar concern which was addressed with the accesskey changes.

In my opinion it would be prudent to have only the plugin receive the hotkey so that the plugin authors can do as they wish.  But then we get into a situation where there may be multiple plugins on the page.

We would also have similar issues as with the accesskey hotkey change.  I myself can't stand the shift-alt-hotkey combination because I'm used to IE's functionality and the extra hotkey hurts my hands.  There is in this case a user-setting which allows me to set my preference.  Something similar to this would also need to exist for this plugin hotkey issue.

My vote would be to have a plugin focus concept.
- control-click a link to open it in a new tab (it has a plugin)
- control-w to close that tab
- control-click a link to open it in a new tab (it has a plugin)
- click on the plugin (eg a flash presentation)
- control-w is ignored by the browser and sent to the plugin
- click outside of the plugin (in white space)
- control w to close that tab

This is almost the current functionality, is it not?

Right now, we have this:
- control-click a link to open it in a new tab (it has a plugin)
- control-w is ignored

We should have this:
- control-click a link to open it in a new tab (it has a plugin)
- control-w to close that tab

So by default the plugin (flash, media player, whatever) would not have "focus" when it is first opened on the page.  So that initial hotkey would work for the browser until the plugin is clicked.

This seems like a simple workaround for now.. thoughts?
Comment hidden (obsolete)

Comment 170

11 years ago
Sy Ali, thank you for detailing the expected behavior. I would also expect the tab shortcut keys (CTRL + 1 to 0) to work as expected, which would add up some cases in your listing.

What would be great (I don't know if it breaks up the whole architecture) is to have the following behavior:

* When any shortcut key is pressed, it is first passed to FF
* If FF handles the shortcut key, it does handle it and the plug-in doesn't know that the key has been pressed
* Otherwise, the plug-in action would be called

It would also be great to have similar behavior against keyboard shortcuts defined in pages (i.e. ALT + [key]), for now those keys are captured by the web page even if FF has a shortcut assigned to it...

Again, I don't know if this breaks up everything, it's just my thoughts. Any comments are welcome.

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #170)
> * When any shortcut key is pressed, it is first passed to FF
> * If FF handles the shortcut key, it does handle it and the plug-in doesn't
> know that the key has been pressed
> * Otherwise, the plug-in action would be called

Unfortunately this will break almost every flash game in existence: they use arrows & space to control something on screen, and firefox will always hijack those buttons to scroll a page.

Same when viewing pdfs.

Comment 172

11 years ago
It seems like we're going to need a list of shortcut keys that Firefox wants to keep. Unfortunately everyone has different favorites; so far we have Ctrl + W, Ctrl + #, Ctrl + T, Alt + [menu accelerator]... well, I'd just like to add Ctrl + L and Ctrl + K, since they are my primary means of exiting any site.

BTW, one will also want to consider Adobe Reader, as well as Flash, in the quest to not break anything. And here we run into a problem---who gets Ctrl + F?

Hmm :-|.

Comment 173

11 years ago
This is just my opinion, but isn't the purpose of a plugin to allow the browser to seamlessly display content that it cannot natively display? For example, Firefox doesn't display PDFs on its own, but a plugin can allow it to do so. To my mind, that means a plugin should behave as if it the browser, not as a separate application. That means even when viewing plugin content, the application in use is the browser and therefor all UI behaviors should be the browser's. If we wanted Acrobat functionality we would just launch Acrobat to view the document.

Comment 174

11 years ago
(In reply to comment #173)

Right, OK, but take Ctrl + F for example. How useful is it to let Firefox have Ctrl + F for full-screen Acrobat documents? Not at all; Firefox isn't going to find anything. So we should pass it on to Acrobat.

But if we make this a blanket decision, then we lose out elsewhere---for example, if someone's on a page with some kind of embedded Flash box, and they expect to be able to search the text _outside_ of the Flash box even while their focus (in the programmatic sense) is in the Flash box.
(In reply to comment #174)
> (In reply to comment #173)
> 
> Right, OK, but take Ctrl + F for example. How useful is it to let Firefox have
> Ctrl + F for full-screen Acrobat documents? Not at all; Firefox isn't going to
> find anything. So we should pass it on to Acrobat.
> 
> But if we make this a blanket decision, then we lose out elsewhere---for
> example, if someone's on a page with some kind of embedded Flash box, and they
> expect to be able to search the text _outside_ of the Flash box even while
> their focus (in the programmatic sense) is in the Flash box.
> 

Plugins need to say whether they handled the things that are sent there way and otherwise the browser needs to handle them.  If I press Ctrl-F while focused on a QuickTime video, that doesn't mean I want to search the video... but in Flash, I can see possibly wanting to have the Flash app search whatever content I'm looking at.

-[Unknown]

Comment 176

11 years ago
Think about what focus means in this context. Focus, in my mind, is simply a way of describing to an application which object will receive an action. Why can something like a PDF have focus anyway? It makes sense for things that can be manipulated (e.g., text inputs, dropdown lists, etc.), but what sense does it make for objects that cannot be directly manipulated?

I realize this calls for a philosophical line in the sand. It depends on what your opinion of the role of a plugin ought to be, and how much leeway should be given them. There is no right or wrong answer. In my opinion, the only case where not giving focus to a plugin might be an issue is where a plugin is duplicating behaviors that a browser is already capable of (damned Flash forms, for example). I'm not personally concerned about breaking them.

Comment 177

11 years ago
(In reply to comment #171)
> (In reply to comment #170)
> > * When any shortcut key is pressed, it is first passed to FF
> > * If FF handles the shortcut key, it does handle it and the plug-in doesn't
> > know that the key has been pressed
> > * Otherwise, the plug-in action would be called
> 
> Unfortunately this will break almost every flash game in existence: they use
> arrows & space to control something on screen, and firefox will always hijack
> those buttons to scroll a page.
> 
> Same when viewing pdfs.
> 

I guess you're right, and I've just seen that I've written the exact inverse of what I whought about: it should be the plugin that captures the shortcut key FIRST, and if it doesn't handle it FF handles it. Luckily, this also resembles the way focusing with child widgets work in many UI architectures.

This way, if a plugin captures a shortcut key (say, CTRL + T) it would be the plugin's fault: it hasn't been tested against the functionalities of a given browser.

I don't know if it helps, but this is also the way it works in a browser made by some guys based in Redmond: for the Youtube flash plugin, since it doesn't capture any CTRL + ? key, all browser shortcuts work. For the Adobe PDF plugin, the plugin captures many browser-related shortcut keys (and luckily does an action when the user uses those shortcuts), therefore it's visible that the shortcut keys chosen by Adobe are the bad ones. People then blame Adobe, not the guys at Redmond.

Any comments are of course welcome!

S. Ali Tokmen
http://ali.tokmen.com/

Comment 178

11 years ago
Is the aim to make it clear that Firefox is not at fault for unexpected behavior, or to provide the expected behavior? I don't think it's a consistent policy to say XYZ shortcut keys work unless there's ABC plugin loaded in which case who the hell knows what will happen. These days most pages have plugin content so we might as well just ditch shortcut keys altogether if we're going to surrender them to any plugin that might feel the need to intercept them.
(In reply to comment #178)
> Is the aim to make it clear that Firefox is not at fault for unexpected
> behavior, or to provide the expected behavior? I don't think it's a consistent
> policy to say XYZ shortcut keys work unless there's ABC plugin loaded in which
> case who the hell knows what will happen. These days most pages have plugin
> content so we might as well just ditch shortcut keys altogether if we're going
> to surrender them to any plugin that might feel the need to intercept them.

If you hate plugins, don't install them.  There really aren't too many of these - Java, Flash, Shockwave, QuickTime, RealPlayer, Windows Media, and Adobe PDF.  It sounds like you're probably really talking about Java or Flash.

The company I work for specializes in making interactive Flash.  We have clients like Fox, ABC, etc. that ask us to create Flash pieces for them.  Being able to capture keypresses is very important for making these things fit the spec - and if we had to tell our clients "oh, that will work in Safari and IE, but not Firefox"... that would really make Firefox look bad.

If you don't trust your plugins, uninstall them or use a content blocking extension.  These are widely available and would of course prevent the plugins from capturing any of your keypresses.

As it is, when if I do some QA on the Flash sites we do, I typically get annoyed about the Ctrl-T issue a lot.  It's funny, actually.  Historically Flash people have not like Firefox - I've actually managed to convert everyone in my office to using Firefox.  I really don't want to lose that because some people have Flash phobia.

If I'm playing a Flash space invaders game, and I press space, the *expected behavior* is for my ship to fire at the aliens.  Not for Firefox to jump down the page.  If I'm viewing a PDF in my browser (yuck), and I press Ctrl-F, the *expected behavior* is to search the PDF.

If I'm viewing a Flash app, and Ctrl-T does not work because the Flash app captures it, I will discontinue use of the Flash app.

It's pretty simple.

-[Unknown]

Comment 180

11 years ago
Our product is a full page web application which renders in Flash, and in that context the user expects our application to capture shortcut keys (we have customer authored bugs to prove it).  Since we're a full page web application, it doesn't make sense for the web browser to capture shortcut keys, and we'd like to handle those key presses to create a more user friendly experience for our customers.

Just my $.02, but I feel that the solution S. Ali Tokmen describes is both elegant, and ideal.

By giving the plugin application the ability to handle the event, you give the plugin developer the power to do the right thing.  Otherwise, the plugin developer's hands are tide and they are unable to do the right thing for the user.   

It would seem to me that everyone wins, assuming the default behavior is that the browser handles the key events that aren't explicitly handled by the plugin.
So honestly, we're 181 comments into this bug, and I think by now we've said everything there is to say at some point or other without having an actual patch.  If people want to help now, they should write a patch and propose modifications to the NPAPI to make it possible for a plugin to not swallow shortcut keys (since, last time I read this bug, that was the big holdup).  What we need now is the design and the patch, not endless and mostly-unproductive discussion.

Comment 182

11 years ago
(In reply to comment #181)
> So honestly, we're 181 comments into this bug, and I think by now we've said
> everything there is to say at some point or other without having an actual
> patch.  If people want to help now, they should write a patch and propose
> modifications to the NPAPI to make it possible for a plugin to not swallow
> shortcut keys (since, last time I read this bug, that was the big holdup). 
> What we need now is the design and the patch, not endless and
> mostly-unproductive discussion.
> 

As behavior (specifications?), I would propose:

* When any shortcut key is pressed, it is first passed to the plugin
* If the plugin handles the shortcut key, FF doesn't know that the key has been pressed
* Otherwise, the FF action for this shortcut key gets called

Is anyone OK or not OK with this?

S. Ali Tokmen
http://ali.tokmen.com/

Comment 183

11 years ago
Isn't that behavior what happens now? If you hand a key press event over to a plugin, how will the plugin to "give it back" if it doesn't know what to do with it? AFAIK Firefox has no way of knowing whether a plugin actually did something with the event, or whether it just swallowed it. I don't want to rely on plugin developers to make their plugin hand back unhandled key presses.

Regardless, I think it's pretty crummy to let plugins hijack shortcut keys. I would rather my browser behave consistently on every page no matter what content the page author has elected to place on their page. I can't see how it can be considered a good idea to shred the consistency of the user's experience and make the same shortcut keys produce radically different results from page to page. To make use of this, the user will not only have to know what plugin currently has the focus, but have memorized that plugin's particular list of shortcut keys. Hijacking my shortcut keys isn't any different than hijacking the size and/or position of my browser window or throwing unwanted popups IMHO.

Comment 184

11 years ago
(In reply to comment #182)
NOT OK! Remember who is the customer (of the browser), it is the user.

IMHO this is the way to go:

1) the base rule should therefore be, for a consistent user experience, that the browser receives any events.

2) events may be forwarded by the browser unmodified to embedded visual plugins.

3) full page web applications should either be launched in an external viewer, or jailed (by the browser) within a frame in the page and thereby becoming in effect becoming a embedded visual plugin.

I would be surprised if the above hasn't been suggested in one of the previous 183 posts (don't have the time to read through them all). If so, I'd like to apologize in advance for repeating what has been already suggested/discussed.
A few things to note:

1. Some work on this has already been done in bug 348279.  I think that just needs to be continued.

2. Currently, most plugins are "windows".  This means the gui toolkit (e.g. Windows, Gnome, KDE) in most cases (e.g. not on Macs) already gives them key events when they have focus (this has nothing to do with magical "short cut keys" - key events are key events are key events for everything on your keyboard.)

3. Making Firefox somehow capture all key events would render most plugins useless or inaccessible, because they would be unable to act upon any keypresses (even typing letters, up/down, etc. etc. etc.)

4. What needs to happen is that plugins need a way to (or just need to be written so that they do) hand the key events to the browser (there is no "back", this is the first time the browser would see them), so that the browser can process them.  See attachment 257819 [details] for more detail.

5. It does not logically make sense for the plugin to take an action on a keypress, and the browser ALSO to take action on it.  For example:

   A. If I press "page up" on my keyboard while a PDF has focus, I do *not* want Firefox to scroll the page up, and I definitely don't want the PDF to scroll up *and* Firefox to scroll the containing page up.  Page up *is* a short cut key as much as any other.

   B. If I press Ctrl-P (print), it is extremely unlikely I wish Firefox to print the current subset of the PDF I am viewing, but rather that I want to print the entire PDF.  Only the plugin should handle Ctrl-P.  This is certainly, by any definition, a short cut key as much as Ctrl-T is.

Again, there is no forwarding of keypress events *from* the browser *to* a plugin.  Don't think of it that way, that's not how the gui toolkits work (in most cases.)  The plugin already owns the keypresses.  If you cannot trust the plugin you should by no means and in no case have the plugin installed.

Obviously, Flash (as an example) should have things in place *within their plugin* which would make sure that Ctrl-T could not be trapped (if they decide to do that), or similar.  Flash *content*, such as annoying advertisements, should not be able to handle "system-like" key press events.

But, that is hardly controllable by Firefox (it's really up to the plugins whether they forward their keypress events to Firefox or not.)  This is something plugin authors (I do not mean authors of Flash swfs, I mean authors of *NSplugins* and if you're reading this bug you better know the difference) have to deal with.

-[Unknown]
I don't think that we want a brand new Firefox-only plug-in behavior. We need
something uniform and browsers like Safari and IE work as expected in my
opinion.

It's really sad that MoFo priorities don't include such issues and they
continue to exist for years. Sooner or later such attitude will affect the
Firefox penetration.

Comment 187

11 years ago
(In reply to comment #185)
> 5. It does not logically make sense for the plugin to take an action on a
> keypress, and the browser ALSO to take action on it.  For example:
> 
>    A. If I press "page up" on my keyboard while a PDF has focus, I do *not*
> want Firefox to scroll the page up, and I definitely don't want the PDF to
> scroll up *and* Firefox to scroll the containing page up.  Page up *is* a short
> cut key as much as any other.

How do you know that if I'm viewing a PDF I don't want Firefox to scroll up a page on PgUp? Unless the PDF is completely filling the entire viewport, it's entirely reasonable to want to scroll up or down from the PDF (if it's in an iframe for example). The problem here is that you don't know what the user wants to do. My argument is that, when you don't know what the user wants to do, it's not a good idea to assume they want the plugin to do something when they press keys.

>    B. If I press Ctrl-P (print), it is extremely unlikely I wish Firefox to
> print the current subset of the PDF I am viewing, but rather that I want to
> print the entire PDF.  Only the plugin should handle Ctrl-P.  This is
> certainly, by any definition, a short cut key as much as Ctrl-T is.

Same as above. You don't know what the user's intentions are. When you don't know what the user's intentions are, you have to guess. This argument is really about whether it's more reasonable to assume they want to take action in the plugin, or whether they want to take action in the larger domain of the browser itself.
 
> Again, there is no forwarding of keypress events *from* the browser *to* a
> plugin.  Don't think of it that way, that's not how the gui toolkits work (in
> most cases.)  The plugin already owns the keypresses.  If you cannot trust the
> plugin you should by no means and in no case have the plugin installed.

If it's true that plugins can commandeer the browser and hijack focus and key presses, then that's a major and serious design flaw. The model should be that plugins are subordinate to the browser at all times, otherwise they're not really plugins are they? If an application really needs "freedom" to do things the browser isn't letting it do, it can be opened externally.

All of this could be avoided if plugins were not allowed to get focus unless explicitly given focus by user input (e.g., mouse click, tab, etc.). That way, no hijacking occurs.
(In reply to comment #182)
> As behavior (specifications?), I would propose:

No.  The only reasonable contribution at this point is a patch which includes a specification for NPAPI entry functions as C method signatures.  Armchair architecture is not useful.

People probably aren't going to listen to me when I tell them to shut up now (the vast majority of this bug is entirely useless to anyone trying to fix the problem -- do you *really* thinking the 180+ comments all convey crucial information for fixing this?), but I'm going to take my own advice and shut up now, because nothing more I can say will be productive either.

Updated

11 years ago
Duplicate of this bug: 435671
(In reply to comment #187)
> All of this could be avoided if plugins were not allowed to get focus unless
> explicitly given focus by user input (e.g., mouse click, tab, etc.). That way,
> no hijacking occurs.

Yes; if the plugin does not have focus it should (imho) never get keyboard events ever.  The gui toolkit will send them to Firefox if Firefox has focus.  All is good here.

(In reply to comment #188)
> No.  The only reasonable contribution at this point is a patch which includes a
> specification for NPAPI entry functions as C method signatures.  Armchair
> architecture is not useful.

Sorry, I'll shut up now.  I'm just wanting to make sure that if someone does come along to make a patch (wish I had time myself, typing is cheap) they don't feel like they shouldn't do this bug since everyone wants different things... hate bugs like that.

-[Unknown]

Updated

11 years ago
Duplicate of this bug: 436958
Duplicate of this bug: 439079
Duplicate of this bug: 439685

Comment 194

11 years ago
In Firefox 3, clicking a different tab does not unfocus a plugin. While probably a good thing, the presence of this bug means that the following scenario is now possible:

- Open a tab with a plugin, eg YouTube.
- Click a different tab with the mouse.
- Do some work in the different tab.
- Attempt to Ctrl+Tab to another random tab.
- Get stuck on the YouTube tab, because as soon as you're on it the flash player gets focus, and eats up all subsequent Ctrl+Tab's.

This is a worse behaviour than in Firefox 2, because previously bug 78414 only affected you if you were actually using a tab with a plugin, but now it can affect you even if you're using two tabs with no plugins on them at all.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 201

11 years ago
Here is a constructive idea.

I've been thinking about this bug and its effects. I've also read most of the comments. Apparently the biggest question is whether any particular keystroke should be sent to the plugin at all or not.

Looking at it from a user's perspective, I think all keystrokes can be divided into three categories:


1) Keystrokes that pertain to Firefox itself and should be independent of any
   content displayed. This includes Ctrl+Tab, Ctrl+T, Ctrl+W, Ctrl+L, Ctrl+I,
   and basically everything else I've forgotten.

   The user expects that these work, full-stop. The user does not generally
   expect that something _inside_ a tab should have an effect on something
   like Ctrl+Tab that works on a higher level.

   I therefore suggest that such keystrokes should be handled by Firefox
   directly and never sent to any content.


2) Keystrokes that pertain to the thing that forms the full contents of the
   current tab. This is usually a website, but it can be a plug-in if the file
   displayed is not HTML but something like PDF or SWF. Examples of keystrokes
   that fall into this category are Ctrl+P, Ctrl+U, Alt+Shift+Letter, etc.

   The user has a certain expectation for these to have specific functions in
   the context of a website, but when a plugin is displayed, the function can
   vary. This way, each plugin can decide whether things like Print or View
   Source make sense, and either act accordingly or implement a different
   function (or ignore the keystroke).


3) Keystrokes that pertain to something which can be contained within a
   website. This includes, for example, the arrow keys, because they behave
   differently in a textbox than they do if the website has focus.

   These keys should be sent to whichever element currently has focus and it is
   then up to this element to bubble (forward) the event up to its parent if it
   doesn't know how to handle it. This is how it works already.


So basically I think the user expects keys to fall into these three categories, but Firefox handles all keys as the third category.

Does this sound like a reasonable implementation plan?
I think it sounds like a reasonable "user expectation plan" but it would probably be next to impossible to implement:

- ctrl button, by itself, is often used to control flash games. Not sending this button to plugin will cause all sorts of problems by itself - and if you send it to plugin, you can no longer use it for ctrl-button combo in browser (I believe).

- keeping and maintaing a list of keys that work in flash and a list of keys which work in browser is strange and non-obvious. There will be endless discussions which goes where, and there will be a (sensible) argument that user doesn't know what to expect before he tries, etc. It also causes various plugin keystrokes to no longer work in new browser versions as the list gets revised (for example because of new feature which gets a new, previously unused, combo).

All that goes on top of the general problem that with current plugin API, keypresses are sent directly to plugin by OS and browser never even gets a chance to see them. And there's no easy way around it.

Comment 203

11 years ago
> - ctrl button, by itself, is often used to control flash games. Not sending
> this button to plugin will cause all sorts of problems by itself

Hm, well this theory would require that such flash games don't work in IE7. IE7 handles flash applets correctly. Ctrl+T, Ctrl+Tab etc. still work, and even Tab and Shift+Tab can be used to tab into the flash applet, through the various items within the flash applet, and then back out at the end, as if it was a set of form elements on the website. Firefox should not be contented with anything less than this.

> - keeping and maintaing a list of keys that work in flash and a list of keys
> which work in browser is strange and non-obvious.

But this is already done in all form elements. Some override the arrow keys (textareas, radio buttons), while others relay them to the webpage and thus cause scrolling (buttons, checkboxes). Similarly for combinations like Ctrl+C or Ctrl+Home. Why is it any different to have the browser chrome "preview" key events before sending them to the website?

> there will be a (sensible) argument that user doesn't know what to expect
> before he tries, etc.

It is the situation _at the moment_ that the user doesn't know what to expect when they press Ctrl+T etc. Surely that is the very problem we are trying to rectify. I think my suggestion solves it.

> It also causes various plugin keystrokes to no longer work in new browser
> versions as the list gets revised (for example because of new feature which
> gets a new, previously unused, combo).

I think that's reasonable. I think plugins that are _embedded in a website_ should not expect to be able to use any keys or key combos that wouldn't also be available to a form element. Even with plugins that run in a tab, I'd still argue that browser features should take precedence, *especially* if it's something as essential as Ctrl+Tab or Ctrl+W, which prevents the user from escaping the plugin entirely.

> And there's no easy way around it.

I'm not saying it would be easy, but I think it's the right way.
Please keep comment 188 in mind.

Also, just fwiw, nothing in the past 7 comments has been at all constructive; it's either already been said in previous comments or simply not helpful.  I'm sorry.  I suggest you read past comments (especially 188) before commenting.

E.g. if you don't have any clue what "WM_KEYDOWN" or "GdkEventKey" are, probably you're not going to be able to give useful contributions to this bug at this point.

-[Unknown]

Updated

11 years ago
Duplicate of this bug: 441148

Updated

11 years ago
Duplicate of this bug: 441571
Duplicate of this bug: 442073
Duplicate of this bug: 437839
Duplicate of this bug: 437913
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)

Comment 215

11 years ago
I think the solution is to allow any plugins or applications to use the alt key, which I am pretty sure is only use in a few instances of firefox that is the menus.

So like the commands would be for like adobe reader(ctrl-f) for example.

alt-ctrl-f

Comment 216

11 years ago
No, Ctrl+Alt+Letter is an actual character on most keyboard layouts
(e.g. British: Ctrl+Alt+a = á).
Alt+letter combinations are typically used to input all Polish diacritical characters. Reserving Alt for different use is a big no-no.
Duplicate of this bug: 448066

Comment 219

11 years ago
In addition to the Ctrl+Alt+Letter issue, there are Java applets that use various keys that when pressed with Alt would then become system-controlled shortcuts such as Alt+F4.  If there happens to be only one tab in the window with the applet, then it will usually just close without warning.  What we really need is a set of options for users to decide on their own what they want and just leave the defaults as they are because it's not that big of a deal to have to click a few extra times.

Comment 220

11 years ago
I think remapping the macros is barking up the wrong tree.  The project I point to in comment #210 is a much more elegant solution:  allow firefox to honor the return values of events as handled in the plugin.  This is already implemented for javascript, why can't it be implemented for embedded media that also interacts with keyboard events???

Comment 221

11 years ago
Honoring the return values of certain JS functions (already) have some ill side-effects. Trap pages (there are a lot of rick-roll-in-the-face domains) exploit onBeforeUnload, onClose event handlers. And they are a massive annoyance, don't make it worse by letting plugins do the same. 

A GUI is not necessary, but a few about:config "rules" would allow everyone to control set the behavior to his/her liking.
Well the question is: Can we really solve this bug without doing a regression in some case. What we could do is:

Don't allow keyboard shortcuts in flash content at all:
programmers would not want that, would they. Especially flash content is becoming more complicated and there are many flash applications and others using key strokes. 

Apply keyboard shortcuts for both Flash Content and GUI:
This could have serious side effects in case that flash content does indeed use keyboard strokes. The user would wonder why there are two effects on keystroke.

Pass keystrokes that are not used from flash content back to the GUI:
Maybe the best solution. The only problem might be: If flash content indeed uses keystrokes like Ctrl+T or something like that, then the flash content will process the keystroke although the user maybe doesn't want it to do that. I mean: How can a user who wants to open a new tab via Ctrl+T know, that the keystroke is used by a flash object etc. 

Any more ideas? I think, we'll end up with a message box 'Hello, do you want to adapt this keystroke to the flash object that has focus or do you want it to apply on the firefox GUI?' :)

Comment 223

11 years ago
Maybe it's a good idea to let the user chose what should happen to keystrokes, as suggested by comment #222. 
I would like a setting within the "Options" menu, if keystrokes should be processed first by the plugin and then - if not used - be passed to Firefox or the other way round.

Comment 224

11 years ago
(In reply to comment #222)
> Don't allow keyboard shortcuts in flash content at all: programmers 
> would not want that, would they.  Especially flash content is 
> becoming more complicated and there are many flash applications and 
> others using key strokes.

Especially if the developers care the slightest in making their Flash applets accessible.  (You might argue "if you want accessibility, don't use Flash" ...  but obviously, my point would apply to content that can't feasibly be presented using more accessible technologies.

> Pass keystrokes that are not used from flash content back to the 
> GUI: Maybe the best solution.  The only problem might be: If flash 
> content indeed uses keystrokes like Ctrl+T or something like that, 
> then the flash content will process the keystroke although the user 
> maybe doesn't want it to do that.  I mean: How can a user who wants 
> to open a new tab via Ctrl+T know, that the keystroke is used by a 
> flash object etc.

Can we tell, in the general case, whether a plugin uses a particular keystroke?  To do so would require that the plugin sends feedback to the browser indicating whether it did anything with the keystroke sent to it.  But even assuming that this is part of the plugin API, can we rely on all plugins and all Flash objects to get it right?

> Any more ideas?

Why not forward those keystrokes the browser isn't interested in to the plugin?

> I think, we'll end up with a message box 'Hello, do you want to 
> adapt this keystroke to the flash object that has focus or do you 
> want it to apply on the firefox GUI?' :)

Every time a key is pressed, when this key is used for the first time in a particular plugin session, or what?
> > Any more ideas?
> 
> Why not forward those keystrokes the browser isn't interested in to the plugin?

Mmh, this is an idea. But that means that flash developers have to take care that the keystroke isn't used by firefox. But it's better than leaving it as is. 

> > I think, we'll end up with a message box 'Hello, do you want to 
> > adapt this keystroke to the flash object that has focus or do you 
> > want it to apply on the firefox GUI?' :)
> 
> Every time a key is pressed, when this key is used for the first time in a
> particular plugin session, or what?

This was more a 'fun idea'. I think some users would get annoyed by this. Some others would simply don't understand, why a key stroke is used by 2 'applications'. I think 'every time a key is pressed' is far too much. The 'plugin session' idea might be a bit better. But I don't know if it is realisable. 

Comment 226

11 years ago
I'm not sure where this idea that a plugin is an application in its own right comes from, but a plugin by definition is subordinate to the application in which it runs. Why would anybody think a subordinate application should be able to override the behavior of the parent application? If you need an application that uses shortcut keys, a browser plugin probably isn't the proper place. Flash, in particular, is not only inaccessible, but it's a pain to use for non-handicapped people too. The widgets behave in entirely different ways than the native OS which is endlessly frustrating.

Comment 227

11 years ago
There's too much bazaar and not enough cathedral here :)

Since 2006 Mats Palmgren is the owner of this bug, however nothing happened.
Not even a common stand has been reached regarding this issue.

Comments #28, #36, #201 and #226 are very informative and constructive. Some comments beside mine point out how wrong is the current approach to let the plugins,
and more precisely the "hosted applets" inside the plugins decide for
themselves.

Asking the user every time or even presenting them with a decision isn't the
best approach. But something like the info-bar for the password manager might
work if the plugin's hosted app asks for a certain key. (So let the user
entrust the partcular web-app. And the browser warns and informs the user about
what he/she is about to do and how can she/he reverse it.)
Asking the user doesn't make any sense.

The average user has no idea what Flash is.  I've had people tell me they installed the Flash update, but can't find the icon anywhere on their start menu.  Even when they know more than that, they don't understand what part of pages are what (generally.)

So, asking the user "do you want the plugin to handle this keypress?" will just confuse them.  And it's a dumb question anyway: if I go to YouTube, play a video, full screen it, and then press Esc... I want the darn plugin to handle it.  Obviously.

Sending key events to the plugin only if the browser doesn't handle them also won't work:

If I am playing a Flash game, and I hit space to make the Yeti swing the bat at the penguin, I want the darn plugin to get the space.  I don't want Firefox to scroll the page down (because the Space key is something Firefox captures.)

If a page has keypress handlers for keys (js) and Flash does, who picks?

Keep in mind: on a site that is 100% Flash, Ctrl-F is useless unless the Flash can handle it.  Firefox cannot highlight or search text within Flash.  Making it impossible to handle Ctrl-F is an important accessibility/user-interface blunder.

For instance this is a site that is, primarily, Flash:
http://www.bk.com/

Please keep sites like this in mind.  We're not just talking about annoying Flash ads or something.

-[Unknown]

Comment 229

11 years ago
> If I am playing a Flash game, and I hit space to make the Yeti swing the bat
> at the penguin, I want the darn plugin to get the space.  I don't want
> Firefox to scroll the page down

Well, my suggestion would solve this in the sense that Spacebar would be sent to the Flash in the same way that it is sent to a textbox or checkbox or any other element that has focus.

I'm not sure what you're trying to say about Ctrl+F. Are you saying that pages like bk.com should have Ctrl+F sent to the Flash applet, while other pages (e.g. YouTube) shouldn't? I think the differentiation is going to be very difficult to make, so we should probably not try. If the Find toolbar pops up but is useless, this is much less severe than having something like Ctrl+T not work at all. If the Flash applet doesn't respond to it either (and 99% of them don't) the user tends to think that Firefox has locked up.

Comment 230

11 years ago
Hello

I have a simpler suggestion, and it has the advantage of resembling the "standard" way in which embedded visual components behave.

The idea is that: if C is within B itself within A (think of a picture, itself inside a tabbed bar and that inside a window), and C (the picture) has immediate focus. On the other hand, since C is a child of B B also has focus, same for A.

When the used does something (here, press a shortcut key) it is first sent to the inmost child that has focus (the picture). If the picture doesn't handle it, its parent (the tab) receives the callback. If the tab doesn't handle either, it's the window's turn to do so.

Having the exact same schema in FF would be interesting: when I focus a plug-in, what is actually focused would be the plugin, which is in a web page (for the sake of simplicity let's ignore frames for now), itself in FF.

When the user presses a key, the key would first be sent to the plugin. If the plugin doesn't do anything with it, its parent (the page) would receive it. Finally, the browser does if the page doesn't do anything with it either.

Note that this already is the way all XUL components work: for instance, try that one out:

- Press T now. I would expect nothing to happen, except if you've activated the "search as you type" option.
- Now press ALT. Since the bugzilla page hasn't handled the key press to alt, it is also sent to FF and FF will focus the toolbar.
- If you press T again, since the toolbar was focused, it will open up the "Tools" menu.

I just hope this approach goes on well with the way plugin focusing and parent-child relations between plugins and pages in Gecko 1.9.

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #229)
> > If I am playing a Flash game, and I hit space to make the Yeti swing the bat
> > at the penguin, I want the darn plugin to get the space.  I don't want
> > Firefox to scroll the page down
> 
> Well, my suggestion would solve this in the sense that Spacebar would be sent
> to the Flash in the same way that it is sent to a textbox or checkbox or any
> other element that has focus.

Well, Space, tab, etc. would iirc get sent to the textbox and when they don't handle them, they bubble up... generally.  That does seem like the right way to handle it for Flash (send to it first, if unhandled, bubble up.)  That's not what I read you as saying.

Backspace being a great example: normally, it takes you to the previous page (back), but in a text box it deletes a key.  Script can also trap backspace (just like ActionScript might in Flash) and prevent both of those things from occurring.

> I'm not sure what you're trying to say about Ctrl+F. Are you saying that pages
> like bk.com should have Ctrl+F sent to the Flash applet, while other pages
> (e.g. YouTube) shouldn't?

No.  If I click inside YouTube, and press Ctrl-F, the following should happen:

1. Flash gets the key event.  It comes from the operating system and Firefox doesn't even know about it yet.

2. Most likely, Flash checks the key against an internal (*short*) blacklist of keys not to be sent to script.  Ideally, it might query Firefox/Safari/whatever for this list.

3. Flash checks for an ActionScript onKeyUp handler.  If one exists, the key press is handled (YouTube would not have one of these.)  Ideally there would be a way for ActionScript to communicate that the event was/wasn't handled.

4. If the key wasn't handled, or step 3 was skipped, the key is sent on to Firefox for it to handle.

Another plugin (like Adobe Reader) would work similarly.

> I think the differentiation is going to be very
> difficult to make, so we should probably not try. If the Find toolbar pops up
> but is useless, this is much less severe than having something like Ctrl+T not
> work at all.

Well, Ctrl-T shouldn't be handled by plugins, I think we can all agree on that.  But it is difficult to make a list of such keys that really makes sense for all use cases.  Handling it like Windows applications are already handled, in a way programmers will understand, seems like the best solution IMHO.

> If the Flash applet doesn't respond to it either (and 99% of them
> don't) the user tends to think that Firefox has locked up.

Exactly; if Flash doesn't respond to it, obviously Firefox should.  But the order of precedence is that; when it is *focused*, not only does Flash get the keystroke (nothing we can do about that), but it's also the thing the user is probably most interested in.

(In reply to comment #230)
This is how things always work in programming.  You're describing the current situation with one small alteration: currently, plugins cannot send the key events to Firefox if they don't consume them.  That's really all that needs to change.

-[Unknown]

Comment 232

11 years ago
The problem with bubbling up from the subordinates to the browser is that frequently the annoyance is that CTRL+T (for example), in fact, does do something in Acrobat. When I want it to open a new tab, it does something else. That's what led me to this bug.

Comment 233

11 years ago
As described by multiple people above, Firefox should receive commands that the plug-in does nothing with.  However, there needs to be a way to still access browser shortcuts even if the same keystroke is in use by the plug-in content.  I suggest that *a shortcut to move focus to the parent object* be added.  The problem with this is that virtually every keystroke combination imaginable is used by some applet or another, so it'd be hard to find a good shortcut for the focus shifting.  This is further complicated by the fact that different platforms and desktop environments have different system shortcuts/commands.  I suppose we'll need someone with both a Mac (running whichever version of OS X Firefox requires) and a PC (with at least XP, Vista, and Linux (on both Gnome *and* KDE; maybe XFCE too)) to try a bunch of combinations and see which ones, if any, are still available on all 3.

The other option to a shortcut to defocus objects and the "bubbling up" would be to have every shortcut user-configured, which would probably be too chaotic for even the most obsessive control freaks to handle manually.  I'm strongly in favor of the bubbling up + defocusing shortcut solution; it's the simplest as far as the user's concerned (and probably to program), and it would be more intuitive of the options; although I wouldn't object to a manual override option being added later.

Updated

11 years ago
Duplicate of this bug: 448670

Updated

11 years ago
Duplicate of this bug: 434760

Comment 236

11 years ago
A proposed API change (NPAPI version 0.20):

1. Per default, no plug-in gets any keyboard events. Windowless plug-ins just don't get them passed through; and for windowed plug-ins, we install hooks to filter them out (on Win32 with SetWindowsHookEx(WH_GETMESSAGE, ...)).

2. The name NPPVpluginKeyboardContract is added to the NPPVariable enumeration (suggested value: 17).

3. When a plug-in's library is loaded, we query it for that new name through the static NP_GetValue . To participate in the key handling contract, the plug-in _must_ return the value 0x100 (for version 1.00).

4. Plug-ins participating in the contract get (almost) all keyboard events passed through NP_HandleEvent. They _must_ however return FALSE when the key event wasn't needed (this includes the Tab key, when the last/first tabbable element was reached so that the browser can correctly tab out of the plug-in). Plug-ins incorrectly participating in the contract might get blacklisted over time.

5. The plug-in never receives any keyboard events associated with the F6 key. F6 currently moves the focus between the address bar, the sidebar and all content frames. Hitting F6 when a plug-in is focused should eventually behave the same as hitting F6 when a text field is focused.

This proposal is backwards compatible with all existing plug-ins. Existing plug-ins won't however be keyboard accessible anymore. New plug-ins can optionally get back all of the desired functionality (if they really need it), offering the keyboard user a much better experience. Non-compliant plug-ins can at least be escaped through F6.

Alternative: A slightly more conservative proposal would consist in filtering out only events related to the F6 keys and letting non-participating plug-ins handle all other keyboard events on their own. This might however not be enough of an incentive to plug-in authors for cooperating in future versions.

Updated

11 years ago
Duplicate of this bug: 449968
Comment hidden (obsolete)

Comment 239

11 years ago
(In reply to comment #236)
> 4. Plug-ins participating in the contract get (almost) all keyboard events
> passed through NP_HandleEvent. They _must_ however return FALSE when the key
> event wasn't needed (this includes the Tab key, when the last/first tabbable
> element was reached so that the browser can correctly tab out of the plug-in).
> Plug-ins incorrectly participating in the contract might get blacklisted over
> time.

I agree with those specifications: send the event and if the plug-in returns FALSE then root the event to next.

S. Ali Tokmen
http://ali.tokmen.com/
Duplicate of this bug: 450998

Updated

11 years ago
Flags: blocking1.9.1?

Updated

11 years ago
Duplicate of this bug: 452182

Updated

11 years ago
Duplicate of this bug: 452182

Comment 243

11 years ago
Mixing Comment 233 and Comment 236:

0.Spec new plugins to bubble up non-used keystrokes
1.Before a plugin is accessed, all strokes are sent to the browser attention
2.When a plugin is clicked or accessed somehow, it gets focus (the GUI could make it obvious by graying the tab or something)
3.Keystrokes are, from then on, all sent to the plugin (except F6)
4.Display some advice for the user saying special content is activated and to click somewhere or press F6 to exit (maybe different advices for spec'd and old plugins)*
5.F6 alternates focus between browser (meaning all menus, tab control, address bar, buttons, etc.) and contents (plugin)
6.When focus is changed to the browser or the user swithches tab (in response to Comment #194), behaviour is back to 1.

This way: the browser will work as expected; the plugin, when activated, also will; the user has a better feel on what to expect (browser-like or plugin-like behaviour); and user can control it better.

As correctly pointed out by some, users have no idea of what a plugin is. But this approach will at least make them know they're inside a pdf or a flash or whatever and letting an easy and visible wat "to get back to Firefox".

At least, this would be the optimal behaviour for me, as an user standpoint.

*Very long suggestion: "Special contents activated. Click in a tab, menu or the address bar or press F6 to exit and reactivate Firefox shortcuts." shown in the status bar.

Many thanks
Not blocking on this, but marking it P1 and wanted1.9.1. To fix this, we need updates to the plugin API, and help from plugin vendors to support the new API etc. We *really* want this, but we'll ship w/o it if no progress is made here.
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: P3 → P1

Comment 245

11 years ago
Has there been any attempt at having some kind of conference with the major plugin developers here?  Conference as in face-to-face, video or phone.  Hacking out ideas in a newsgroup or in bug and trying to get the major plugin developers doesn't seem like it will ever work if it hasn't 7 almost 1/2 years down the road hasn't.

Updated

11 years ago
Duplicate of this bug: 457006

Updated

11 years ago
Duplicate of this bug: 436001

Comment 248

11 years ago
my bug https://bugzilla.mozilla.org/show_bug.cgi?id=457006 has been closed as a duplicate, but i don't think this bug covers one of the aspects i raised: tabbing INTO the flash movie itself. IE handles this neatly: the flash movie is added to the normal tab cycle, based on its position in the document source - using tab, a user can cycle through links, form elements, etc, INTO any flash movie (unless it's wmode=transparent), tab through any keyboard-accessible elements inside the movie, and then at the end tab out of it and carry on in the document.

i'm concerned that this seems to go back to 2001 and there's no real resolution...it's a rather critical keyboard access issue in my eyes.

Comment 249

11 years ago
Something I didn't see mentioned, and has been driving me crazy lately, is that plugins are even stealing mouse wheel events. That means if I'm scrolling down a page and the mouse pointer crosses a plugin, I get stuck in a tar pit. I can't scroll with the wheel anymore unless I move the pointer out of the plugin and click.

Comment 250

11 years ago
Regarding Comment #249: Scrolling down into a plugin area does steal mouse wheel events for me, but merely moving the mouse pointer outside the plugin area is enough to reenable it, no clicking necessary in my case.
A rather minor suggestion on my side:
What about showing up a dotted frame around the plugin's area when it has focus, just as it's already done in the Windows OSes with the Desktop icons. I know this does not really solve the problem but I think IMHO it would help some people.

Updated

11 years ago
Duplicate of this bug: 466270
Duplicate of this bug: 468813
Duplicate of this bug: 469638
Duplicate of this bug: 469959
Duplicate of this bug: 471237

Updated

10 years ago
Duplicate of this bug: 471600

Comment 258

10 years ago
A workaround for the time being could be to make the plugin lose focus when the browser loses focus.

Example:
I'm stuck in a Youtube video
I press the Windows Key
When focus returns to the browser, I can once again tab around.

I'm not sure if this is even possible but I thought I would throw that out there.
QA Contact: shrir → plugins

Comment 259

10 years ago
add preference(s) to protect a (set of) hotkey(s) from being intercepted by
plugins

true:  CTRL+T always functions as expected
false: enjoy another opportunity to practice patience

Comment 260

10 years ago
IBM proposal:

http://ibm.com/developerworks/opensource/library/os-78414-firefox-flash/index.html

"With the code and tools presented here, you can restore your favorite Firefox hotkeys from the grasp of Flash."

Comment 261

10 years ago
I see a disadvantage on the proposed solutions in Comment #259 and Comment #260: this would freeze the set of hotkeys available to either FF and the plugin. As pointed out by some, we'd be better served by the ability to change focus between the browser and the plugin - then a hot key can be reserved for that, as F6, for example. So, instead of losing funcionality for the browser and the plugin, we just pick one to deal with - switching any time. This seems simpler to implement and use.

Updated

10 years ago
Flags: blocking1.9.2?

Updated

10 years ago
Duplicate of this bug: 482121

Comment 263

10 years ago
For the tab switching problem, one simple improvement would be to have Firefox just not pass off the control of the keys to the applet's domain if Firefox finds that you are already holding down the CTRL key when switching INTO any tab containing an applet. That way, you would be able to continue to cycle through all the rest of your tabs without getting stuck by the applet page, as long as you continue to hold ctrl down.  

Sure, if you let go of ctrl after each tab press, this wouldn't fix the problem, but most people continue holding down the ctrl key and just release and repress the tab key each time. Sure, this also won't fix the problem of ctrl-tabbing away from a page containing an applet, but it will at least be obvious to the user in that case that there is an applet present and they can learn to circumvent this by clicking another tab with their mouse.

However, when cycling through ones tabs when not initially starting from a page with an applet, it is much more annoying, as the likelihood of you wanting to stop on that particular tab isn't very good.

Comment 264

10 years ago
Oh, and I forgot to mention that Google Chrome figured out a way to fix this buggy behavior in the very Mozilla code they use and still retain keyboard control of applets once they are clicked, so it is definitely possible to fix this.
Comment hidden (obsolete)

Comment 266

10 years ago
(In reply to comment #263)

ISTM when you switch to a tab containing an applet, you ought to have to explicitly set focus on the applet by some means or another.

Comment 267

10 years ago
(In reply to comment #266)
> (In reply to comment #263)
> 
> ISTM when you switch to a tab containing an applet, you ought to have to
> explicitly set focus on the applet by some means or another.

I don't disagree, I am just trying to come up with a workable compromise that will suit those who don't want it to do that.

Updated

10 years ago
Duplicate of this bug: 484213

Comment 269

10 years ago
There is a specification addressing this problem here:

https://wiki.mozilla.org/Plugins:AdvancedKeyHandling

Updated

10 years ago
Duplicate of this bug: 484908
Duplicate of this bug: 486116
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Duplicate of this bug: 489599
Duplicate of this bug: 449923

Updated

10 years ago
Depends on: 491141
This is not my bug, so I'm not going to add keywords, but I think sec508 needs to be added to the list.
Blocks: 491178
Duplicate of this bug: 498285
Duplicate of this bug: 499517

Updated

10 years ago
Duplicate of this bug: 502247

Updated

10 years ago
Duplicate of this bug: 503182

Updated

10 years ago
Duplicate of this bug: 504982
Duplicate of this bug: 505689
Comment hidden (obsolete)
Duplicate of this bug: 508535

Comment 288

10 years ago
revisiting Comment #259 and Comment #260

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

Comment 289

10 years ago
(In reply to comment #286)
> There's not going to be enough time to implement the advanced key handling
> proposal for 1.9.2.
-----------------------------------------------------------------------
Serously? Not enough time?  You've had what, almost a decade?  Please.


(In reply to comment #260)
> IBM proposal:
> 
> http://ibm.com/developerworks/opensource/library/os-78414-firefox-flash/index.html
> 
> "With the code and tools presented here, you can restore your favorite Firefox
> hotkeys from the grasp of Flash."
-----------------------------------------------------------------------
Has this been attempted or even researched?


(In reply to comment #264)
> Oh, and I forgot to mention that Google Chrome figured out a way to fix this
> buggy behavior in the very Mozilla code they use and still retain keyboard
> control of applets once they are clicked, so it is definitely possible to fix
> this.
-----------------------------------------------------------------------
Hm, so Google was able to fix it and they didn't need 8 years.  Interesting.


(In reply to comment #273)
> Voting for this bug, because it is a terrible flaw in accessibility.  There is
> no way to escape from a Flash applet using the keyboard, once it has focus.  It
> is marked as Critical and needs closure, as it comes up to its 8th birthday.
[[  Importance:  	P1 critical  with 176 votes (vote) ]]
-----------------------------------------------------------------------
So it's Critical, needs resolution, and yet won't make it into an update that's already passed, and still exists after 7.5+ years.  Looks like the programmers behind Firefox are lazy, possibly bad coders, and don't care about the customer base.  Fantastic.  This is great reason of motivation to try other browsers such as Opera or Chrome, although I don't use either currently.

Removing my CC from this bug permanently.
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Duplicate of this bug: 413986

Comment 294

10 years ago
It sounds like https://wiki.mozilla.org/Plugins:AdvancedKeyHandling is going to happen :)
Assignee: matspal → joshmoz
Priority: P1 → --
Target Milestone: Future → ---
Comment hidden (obsolete)
Duplicate of this bug: 513043

Comment 297

10 years ago
The use of Flash is growing rapidly from esoteria to standard UI, which makes this bug worse and worse every day.

To use Ctrl-T, Ctrl-Tab, etc, the user has to find some place outside the plugin to click in order to remove focus from the plugin. But this is not always so easy. Previously one could at least click the tab above the webpage, to give focus to the tab instead - but in a recent FF version update the focus behaviour of tabs seems to have vanished (good in itself, but...) and the possibility doesn't exist anymore. On pages where the Flash plugin takes up the whole page (or where the user doesn't find an obvious spot that is outside the plugin), the only easy way seems to be clicking on another page's tab. Not user-friendly.

I hope you can come with a remedy very soon.

Comment 298

10 years ago
(In reply to comment #297)
@297: Yes, TabSwitching to another opened tab via Ctrl-PageDown or Ctrl-PageUp must work always, no matter what content (!) is displayed in the tabs. But now, unfortunately, Ctrl-PageDown/Up does not switch to another tab if a webpage contains certain Flash or Java content etc. 

Reproducible: Always

Steps to Reproduce:
1. Open some random tabs to switch through.
2. In one of these tabs, surf to Bandwidth.com/tools/speedTest and click "Begin Test" (it simply tests your Internet connection speed). 
3. Now try to switch to another tab via Ctrl-PageDown or Ctrl-PageUp: It does not work. 

Actual Results:  
After performing these steps, users cannot switch to another tab via Ctrl-PageDown/Up — which is critical indeed because those fundamental navigation elements must function perfectly in 2009 and in the future.

Expected Results:  
Ctrl-PageDown and Ctrl-PageUp must always (!) switch to another tab, no matter (!) what content exists in the current tab. 
 
Many powerusers and I assigned Ctrl-PgUp and Ctrl-PgDwn to their mouse side-buttons for the best tabbed browsing experience. But this usability is still being disrupted by Firefox’ keyboard focus bug. It's 2009 now. 
 
Switching tabs by clicking somewhere outside the flash focus and then trying it again is not a final "solution" at all: Most users do not know that they should click "next to" the flash zone. And this is often impossible because the flash app can fill the whole content window. Users want to browse through their tabs fluently; the Firefox keyboard shortcuts must finally have the absolute priority, at least if the mouse pointer "is not over" a shockwave/flash/etc. object, but outside.

Comment 299

10 years ago
this problem is getting worse, rather than better.  before up and down arrow keys worked as expected, but now the default behavior for up and down keys skips across the entire page based (it seems) on where the flash object is.  normal pages (without flash) behave as expected.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090830 Minefield/3.7a1pre

Comment 300

10 years ago
(as a side-note, and apologies for the double post, but this behavior does not always happen by default, some pages automatically seem to take you into the flash region and cause it, others default to the up/down working properly).  in either case, you can click outside into text, and it will operate normally again, at least until it encounters the flash object again.

Comment 301

10 years ago
I wrote a 5 liner script that runs a timer which checks every second if the focus is on the embed object and blur()'s it if so. Seems to fix Ctrl-T, Alt-D and any other problems with the keyboard. 

I know it's a hack, but for people who need to use FF3 now (instead of waiting another 7 years ;-) it might be a solution.

Just install Grease Monkey and add script from: http://cgi.cs.indiana.edu/~oleykin/window focus.user.js
That greasemonkey script is a nice idea, however in 3.7a1pre, the script breaks every single site I visit because I can't do anything due to windows popping up saying undefined. If you fix it, let me know. :)

Comment 303

10 years ago
Fixed now, i just messed up the file while cleaning up comments.
Try now "http://cgi.cs.indiana.edu/~oleykin/window focus.user.js"

Here's the code:
// ==UserScript==
// @name           Window Focus
// @namespace      http://alexleykin.zapto.org
// @description    Grab Focus from Flash back to the window
// ==/UserScript==
// ==UserScript==
(function(){


   setInterval(doFocus, 5000);
   		

   function doFocus() 
   {
         if (document.activeElement.tagName == 'EMBED') {
            document.activeElement.blur();
         }
         return;
   }
})();
Much better, thanks.

Comment 305

10 years ago
(In reply to comment #303)

Thanks so much for making this.  It's good to know that *someone* is making an effort to fix the issue, no matter how rudimentary the technique!

I also added the following block to the beginning of my script, so that if no embedded objects are found, we quit and don't bother setting up an interval.  This should help reduce memory usage when many pages and tabs don't have Flash on them.

if(document.getElementsByTagName('EMBED').length == 0)
{
	return;
}

Comment 306

10 years ago
This is really not a solution, appreciate the effort but try playing a flash game or anything where you want to actually use keys inside the game.  Plus some of them automatically pause when the game loses focus.  The key handlers have to be controlled by the browser first, then the plugin

Comment 307

10 years ago
To defend my puny piece of code :-)

1) I tried fullscreen on hulu.com and it breaks the timer, in other words you will be able to play a flash game in fullscreen just fine.

2) An easy shortcut toggle could be made to turn the feature off if you want to play a flash game.

3) Statistically speaking, how many of the average user visited pages are a "flash game" requiring keyboard navigation?

But you are right in principle, this is just a hack and a permanent solution is sought for.

Comment 308

10 years ago
Compiled it into a Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/14054/

Updated

10 years ago
Duplicate of this bug: 511209

Comment 310

10 years ago
First of all, there will always be bad plugins, or bad usage of good plugins, or whatever. Some sites will always try to misuse all available possibilities. 

Now we have the pop-up blocker, am I right?
Why, instead of making it, don't we endlessly discuss "some pop-ups are legitimate ones, we cannot hurt them, etc"?

So, bad plugins will always exist, they will report "I am good plugin", they will return 0x100-the-magic-number, and yet they will behave badly -- eat all the keys as an example.

Well, the proposed solution:

The control at the plugin-type level: global settings like "I want this plugin to handle keys before the browser, and that plugin to receive them after the browser". We can even set these to "plugin is the boss" by default, but, at least, let's give the power users an ability to control it.

The next level: for untrusted plugins, the ability of (temporarily) enabling key-swallowing for a particular instance of the plugin -- yes, this is about "my favourite flash game". 

I thought about Quakelive -- an extreme case of "browser plugin". Why do we call such things "plugins", I don't know. It can do anything, format your hard-drive, for example. Any exploit found in such "plugins" -- and your computer is dead.

P.S. About "don't install bad plugins" -- sounds like "don't browse sites with bad pop-ups" -- there is no need for the pop-up blocker. People want to watch youtube and yet they want to create a new tab with Ctrl-T, strangely.

Comment 311

10 years ago
I've a couple comments I hope are constructive.

A lot of the proposed solutions seem like a very large development effort (allow the user to set preferences for which hotkeys he wants the browser to keep), or seem highly platform-centric and/or browser centric (CTRL-W should _always_ work).  In a world where plugin developers (e.g. developers of flash applications) are trying to target multiple browsers on multiple platforms, suddenly the list of problematic key-combos explodes to include all the important hot keys in all common browsers and on all common platforms.

On the other hand, plugin developers know they must avoid certain gui toolkit key combos like alt-tab or command-tab.

My proposed solution: 

Create a SINGLE new hotkey for Firefox which says "please unfocus this embedded object for me". It doesn't really matter what combo it is (how about ESCAPE? ;)  This would require that Firefox was at least sniffing the key events, but it would only have to look for a single key combo and so we wouldn't be violating lots of hotkeys plugin developers might wish to use.  If escape is too important a key to take, it could be ctrl-alt-f11 or something...

[Unknown] said (in comment #185) that Firefox isn't even getting the key events from the gui toolkit in many cases.. so perhaps that invalidates my suggestion.

If Firefox is entirely unable to sniff the keyboard events on some platforms, I'd argue that perhaps the responsibility is on the plugin developer (Adobe, Sun..) to "play nice" with the browser.  

I'd say flash is probably the biggest offender snatching focus, e.g. if you have a youtube video open in a tab and you try to cycle past it (INCREDIBLY frustrating).  Adobe and Sun already have to consider myriad security and usability issues.  Flash is built to always exit full screen when the escape key is pressed.. this is a rule imposed by flash and is not overrideable by the flash developer.  Flash can make javascript calls.. it seems like it'd be trivial to make it call .blur() on it's DOM object when a certain hotkey is pressed (e.g. escape when not in full screen).

I also have found a pretty pitiful work-around which works for me in FF3 on WinXP.  When I've focused a flash object, windows shortcuts like ctrl-escape and alt-f4 still work.  If you have more than one tab open and you enable the "warn me when closing multiple tabs" option.. you can press alt-f4 and the browser will pop up the warning/confirmation.. you can then hit escape to say "no I didn't actually want to close" and focus has magically been shifted back to Firefox!

I sometimes browse entirely with the keyboard, e.g. living room/tv setting watching youtube videos, wireless mouse's battery is dead or the mouse is otherwise unavailable.  Having youtube then hijack focus is pretty frustrating.  At least I can escape using the work-around above.

Comment 312

10 years ago
(In reply to comment #311)
> Create a SINGLE new hotkey for Firefox which says "please unfocus this embedded
> object for me". It doesn't really matter what combo it is (how about ESCAPE? ;)
>  This would require that Firefox was at least sniffing the key events, but it
> would only have to look for a single key combo and so we wouldn't be violating
> lots of hotkeys plugin developers might wish to use.  If escape is too
> important a key to take, it could be ctrl-alt-f11 or something...

Ctrl+Alt+F11 would never reach Firefox on Linux, where Ctrl+Alt+Fn switches to virtual terminal n....

Eventually, even the most obscure combo is used by something, so they should assume that there's going to be a conflict and make the unfocusing combo customizable.  Or perhaps we could get the entire software industry to work together on a universal key combo permissions system....



Here's an (somewhat disorganized) idea for universal combo permissions that would fix this bug, but which extends far beyond the scope of any browser.  However, keyboard shortcut priorities are a major problem that's mostly been ignored or quietly worked around when major collaboration is needed.

The idea is to implement a cross-platform universal standard on what gets to use what combos....

It's sort of based on applying the idea of security "rings" (see http://en.wikipedia.org/wiki/Ring_(computer_security) ) to key combos.

Comment 313

10 years ago
(In reply to comment #312)
(It didn't post the whole comment, so I'm adding the rest here)


Here's a rough description of how it would work.

First, break keys down into "tiers" of importance:

Tier 0: An extremely limited set of combos (such as Ctrl+Alt+Del) and combos involving certain laptop-specific keys (such as the "ThinkVantage" key on ThinkPads)
Tier 1: Meta ("Windows key") and Scroll/Caps/Num Lock
Tier 2: Alt and the Fn keys
Tier 3: Ctrl, Tab, and Esc
Untiered: Shift and all visible characters

A combo's tier would be the same as it's highest-tiered modifier, so Alt+Ctrl+Shift+Tab would be a Tier 2 combo.

Each software layer would be given a tier level of key combo access, such as this:
Tier 0: hard-coded in the OS kernel, BIOS, etc
Tier 1: the OS, window manager, etc.
Tier 2: Tier 1 + everything that runs directly as a program
Tier 3: Tier 2 + everything that runs within another program (browser plugins, Google Desktop widgets, etc)
Untiered: everything

Currently, everything can use less privileged tier levels and can even share its higher-level privileges with stuff that run inside of it, but it shouldn't, since that's how this problem started in the first place.

What things should do is strictly use only combos of their own tier level, trying to avoid using lower-tier modifiers.  If something wants to use a lower-tier combo, it should probably make an object with lower privileges to handle it.  If this were already implemented, you'd be using Meta+Tab for switching windows, Alt+Tab for switching tabs, and Ctrl+Tab would be available for Flash, etc.

As a practical concession, you would still be able to use higher-tiered combos in low-tiered objects by combining modifiers.  For example, if a Flash applet wanted to use F1, you'd press Alt+Ctrl+F1.

The organization of keys into tiers almost certainly needs a *lot* of refinement, as does the support of pre-standardization programs/applets, the categorization of global combos with local impact (Ctrl+V pastes from the global clipboard to the local location).  However, once implemented, universal combo standards would completely solve this entire category of problems while also making it very clear to users what privileges the combo has.

Comment 314

10 years ago
(In reply to comment #312)
> Eventually, even the most obscure combo is used by something, so they should
> assume that there's going to be a conflict and make the unfocusing combo
> customizable.

I partly agree, but there are combos not so obscure which should be always available, as Ctrl-Tab and Alt-Tab. To use theses combos for a plugin/app/script is unfair with the browser, and the developer should seriously consider not doing so.
I favor the browser to simply forbid it and force developers to avoid those combos. After all, there are enough keys and combinations for no developer to ever need these specific couple.

Comment 315

10 years ago
This bug has enough speculation and opinions, more isn't going to help. Lets stick to comments with tested patches from now on.

At this point we're solving the problem as described in comment #269.

Comment 316

10 years ago
(In reply to comment #315)
> This bug has enough speculation and opinions, more isn't going to help. Lets
> stick to comments with tested patches from now on.
> At this point we're solving the problem as described in comment #269.

How about opening a new bug with comment 0 describing the solution since this bug has more spam than any other bug I have seen here.  Then mark this one as a duplicate?

Comment 317

10 years ago
Comment #316 sounds good to me.

More opinion/solution for a compromise that minimizes both browser annoyance and plug-in functionality loss:

When working inside a browser, you can't expect to do whatever you want. You have to conform to what is accepted and appropriate. (Just like when working in a kindergarten, church, hospital, etc. Nothing strange with that.) A Flash programmer that rely on being served every key/mouse event in the world will not be successful. The browser should get whatever events that it wants to use, even if the plug-in has focus. Everything else is (apparently, just look at this discussion thread) very annoying for the browser user.

However, when the browser consumes the event right in front of the plug-in, a little information "flag" (perhaps similar to the little translucent "block" thingy that Adblock Plus uses if not hidden in the settings) could be shown near the plug-in for some seconds, allowing the user to click on it to grant permission for the plug-in to get all events from now on. This would make it possible for a plug-in to get practically ALL events if it really wants to - but without annoying a user who just want to cycle through the tabs, scroll the page, or close it.

Comment 318

10 years ago
... and I forgot: This "flag" could be shown already at modifier keystrokes, making it visible before the user completes a command that may take her away from the page.

Comment 319

10 years ago
I've only recently subscribed to this bug, so pardon me if someone has made this suggestion before.

It seems to me that the main problem here is one of focus.  When the tab contains Flash/dynamic content, that content is *automatically* the focus, with no way to change it.  This is the core frustration... you have to do something extremely nonstandard (switching to a new tab) to perform standard shortcuts.

So why not allow the user to determine what is in focus, decide for him/herself?  Ways to differentiate between when the dynamic content is in focus vs. out of focus:

1. Mouse hover-- if it's over the content of the Flash, it is active.
2. Mouse click-- if you click on the Flash, it is active, if you click on the HTML content, Firefox's shortcuts are active.
3. Some kind of overlay or shortcut on pages with dynamic content which the user can click on to change the focus.

Comment 320

10 years ago
Really - don't comment on this bug unless you are posting a patch. Just don't do it.

I don't want to have to close a perfectly reasonable bug because the comments are out of control.
Duplicate of this bug: 516249

Updated

10 years ago
Duplicate of this bug: 517675
Duplicate of this bug: 521978

Updated

10 years ago
Duplicate of this bug: 524024
Duplicate of this bug: 524425
Duplicate of this bug: 524425

Comment 327

10 years ago
Allow flash no keys until flash itself modified that adobe flash control features page allows individual users to specify which keys SHALL NOT be used by flash object.  This rather than trying to use the browser, in which flash is a 'guest', to make flash objects behave.

Without the 'user consent in adboe flash setting panel' no keys work.

It is obscene that I have to use the new tab toolbar button in firefox rather than hotkeys.
Couldn't this be fixed temporarily be denying embedded plugins (i.e. plugin content within web pages) to own Ctrl- (and maybeall meta-char) prefixed combinations.

I don't know about any flash content that needs these meta chars. Normal web pages only get Ctrl+Shift+<key> and printable chars for inputs.

We must also think about how tabbing should work in plugins Adobe's plugin tabs between internal objects, like it should, but instead of giving the focus to the rest of the page when end is reached it starts from beginning.

This bug is one of the key reasons I don't use Flash on my mostly free Linux box.

Updated

10 years ago
Duplicate of this bug: 526983

Comment 330

10 years ago
Sorry Josh, but I have to comment: what has been done is inadequate. Typical users do not understand why Ctrl-T and other combinations sometimes don't work nor do they understand how to get around this behavior that Flash causes. I have to teach & deal with these people, and am tired of this annoyance. If this cannot be better resolved, then Please give us a different solution: Create an option of some sort that prevents plugins from even receiving a user-defined set of key combinations. This way we can set the browser to always "see" them.

Comment 331

10 years ago
I don't know if anyone's mentioned this, but IE7 (and presumably 8) handles this perfectly.  It is also handled perfectly in IE6 under IETester, so unless that is something provided by IETester itself, this has been working in IE since before Firefox was born!

Using one of the special browser shortcuts within a flash movie works as you would expect (e.g. Ctrl-T opens a new tab).

The tab order for the page includes the Flash movie, e.g. when you get to the end of the tab order in Flash it then tabs out of the movie and round the rest of the page, up to the address bar and then back into the movie, again as you would expect.

If IE has got this licked, why is it still a problem in Firefox?  It's no use shifting the blame to Adobe - that clearly isn't the source of the problem if IE is handling it OK!
Comment hidden (obsolete)

Comment 333

10 years ago
Since key handling inside/outside plugin objects is a delicate matter, it hasn't been solved in the first 333 comments. People could discuss it forever. But It seems to me that most annoyances are related to something on the edge of this key handling - things that can be solved by workarounds, without solving the hard task!

Here come three related problems and their workarounds:

1. When scrolling, it stops when cursor happens to be over a YouTube video.
Solution:
Never pass scroll events to a non-focused plugin object.

2. When cycling between tabs with Ctrl-Tab, I end up stuck in a plugin object.
Solution:
When showing another tab, never give back focus to a plugin object.

3. When a plugin object is full-page, I don't know where to click to de-focus.
Solution:
Take away the focus from the plugin object if I click the tab at the top. The tab was a "safe place" until a version some months ago, when the tabs could no longer be focused themselves. Nowadays a click on the tab doesn't take away the focus from a plugin object.

Should be fairly easy & effective compared to solving the complete issue!
No need for user-defined disallowed keys, negotiating with Adobe & other browser makers about standard behaviour conformance, etc. Just do IT.

PS:
I agree with the recent comments above... I never expected that MSIE would handle this issue well, but I realized that quite recently when turning to MSIE to watch a Flash movie without halts... the assumed memory corruption of Bug 490122 makes Firefox unable to show video properly after some hours of use. Ending up with MSIE handling both the video bit and the general UI handling fine while Firefox performed ridiculously in both respects was not what I was looking forward to. Something must be done quick.

Comment 334

10 years ago
This bug has a bounty on it in:
http://www.fossfactory.org/project/p81

It is currently worth US $106.88 .

Does anyone want to collect it?
Duplicate of this bug: 533289
Comment hidden (obsolete)
Please, no more comments unless you have a constructive patch to submit. See comment315 and comment 320.