Closed Bug 78414 (PluginShortcuts) Opened 23 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Tracking

(blocking2.0 -, relnote-firefox -)

RESOLVED FIXED
mozilla48
Tracking Status
blocking2.0 --- -
relnote-firefox --- -

People

(Reporter: dshultz, Assigned: masayuki)

References

(Blocks 1 open bug)

Details

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

Attachments

(4 files)

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.
Macromedia Bug 67613
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
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
Depends on: 78846
Keywords: 4xp, top100
OS: Mac System 9.x → All
Hardware: Macintosh → All
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.
Keywords: access
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.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Summary: Application keyboard commands fail to operate during Shockwave playback → Application keyboard commands fail to operate during Shockwave Flash playback
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
This only happens when the plugin has focus, right?  If not, my dups might be
incorrect.
Whiteboard: [PL2:NA]
Sergey Lugenov has created a preliminary patch for a bug which seems to be a
dupe of this one, bug 95541.
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
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-
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?
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.
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?
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
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.

Keywords: topembedtopembed+
Blocks: grouper
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
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. 
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
Closed: 22 years ago
Resolution: --- → DUPLICATE
bug 181177 seems to be an alternative for win32 (and maybe unix?) platforms, but
what about macintosh?
they are being covered sarah
mac is covered by bug 140566.

v dup.
Status: RESOLVED → VERIFIED
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 → ---
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
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.
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.
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
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
Blocks: majorbugs
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
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)
(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.
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.
We're going to have to implement something like the following to get keyboard
accessibility working with plugins:
www.mozilla.org/access/plugins
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)
No longer depends on: 279532
*** Bug 287467 has been marked as a duplicate of this bug. ***
On my Windows 2000, 1.0.3 machine, I have the same problem. Just thought I'd add
my $.02
Plugin work doc is now at:
http://www.mozilla.org/access/plugins-work
No longer blocks: majorbugs
No longer blocks: grouper
Blocks: 273456
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.
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?
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.
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.
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.
Severity: normal → critical
Flags: blocking-aviary2? → blocking1.8.1?
by the way, I'm not sure if Java content is regarded as plug-in related, but Java applets seem to do the same.
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?
Assignee: aaronleventhal → mats.palmgren
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 :) 
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?  

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)
Blocks: 93149
(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
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.
Flags: blocking1.9a1?
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
Whiteboard: [PL2:NA] wanted-1.9 → [PL2:NA] [wanted-1.9]
Depends on: 348279
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
Ctrl+w should be essential, especially in the case of adobe, where ctrl+w is supposed to close the current document anyway.
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 ?
Blocks: 164421
(In reply to comment #139)

presumably, this depends on how it is "fixed" ;)
Blocks: 395980
Flags: wanted1.9+
Whiteboard: [PL2:NA] [wanted-1.9] → [PL2:NA]
On Mac, Firefox trunk has a similar problem (bug 428047).  For that platform, it's a recent regression.
Or, for that matter, someone should document what expected behaviour is. Should plugin *and* browser receive key presses? Should plugin not?
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?
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.
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 :-|.
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.
(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]
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.
(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/
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]
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.
(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/
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.
(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.
(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.
(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]
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.
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.
> - 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]
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
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.
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.
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???
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?' :)
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.
(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. 
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.
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]
> 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.
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]
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.
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.
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.
(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/
Flags: blocking1.9.1?
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
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.
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.
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.
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.
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
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
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."
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.
Flags: blocking1.9.2?
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.
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.
(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.
(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.
There is a specification addressing this problem here:

https://wiki.mozilla.org/Plugins:AdvancedKeyHandling
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
Depends on: 502128
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
(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.
It sounds like https://wiki.mozilla.org/Plugins:AdvancedKeyHandling is going to happen :)
Assignee: matspal → joshmoz
Priority: P1 → --
Target Milestone: Future → ---
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.
(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.
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
(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.
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. :)
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.
(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;
}
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
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.
Compiled it into a Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/14054/
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.
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.
(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.
(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.
(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.
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.
(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 #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.
... 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.
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.
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.
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.
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.
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!
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.
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?
Please, no more comments unless you have a constructive patch to submit. See comment315 and comment 320.
(In reply to comment #334)
> 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?


I started the bounty there for the project.  Once we get past the halfway point to the goal, I'll start looking into whom to donate it to or if perhaps i want to submit a patch myself.

Noone has contacted me or claimed the bounty yet, but I welcome all comers.
Pls definitely see Comment 315, Comment 320 and Comment 337. The first fully answers this question.
If we can copy OOPP from Chromium, how about looking in Chromium code how it working there without this annoying bug, so me can copy it to Fx too :P
Blocks: papercuts
Blocks: cuts-focus
No longer blocks: papercuts
also relevant for pressing Alt to show the hidden menu bar
Blocks: 477256
A Google search gleans some interesting information on this bug:

http://www.asserttrue.com/articles/2006/11/17/firefox-and-flash-swf-selection-and-focus-problems
[Stating/showing that issue may be rooted in the wmode attribute]

http://www.ibm.com/developerworks/opensource/library/os-78414-firefox-flash/index.html
[Fully-Functional code workaround in Linux using cnee and Perl, code can be applied to Windows as well]
--"Linux is required, with Firefox V2 or later. The libXnee and cnee components are necessary to monitor systemwide keyboard events, and Perl handles the algorithms. Certain Perl modules are required to process the cnee output and send X Window System events: threads, Thread::Queue, X11:GUITest and Time::HiRes. Although implemented on Linux, the general concepts presented here are applicable to multiple operating platforms, such as Microsoft® Windows®. All that is required is a cnee replacement that can print out systemwide keyboard events reliably, as the Firefox extension and Perl code are cross-platform."

http://wwwx.cs.unc.edu/~gb/wp/blog/2007/06/08/fixing-firefox-flash-foolishness/
[More code, this time using Flash's ExternalInterface object]


The third link provides a .zip containing an example of the code; I have attached it to this bug.
Attached file code example
I provided a RentACoder company with this URL and the Foss Factory URL for this bug, and the URLs / code from Comment 350 above - they said this can definitely be done, but would require several weeks of work to do so - this company is in an emerging economy so the hourly rate is fairly low, but still they estimate it would be roughly 750$US for the labor.
Correct me if I'm wrong, but the first and third links describe workarounds that flash developers can use to get firefox to play nicely with their own particular SWFs. The second link describes a workaround that you can use to redirect keyboard input around and into firefox if need be. None of them describe a way to actually fix the problem in firefox. Even if they did, the first and third links are SWF-specific and thus irrelevant, and the second link has relatively detailed instructions. First, why would it take several weeks and USD 750, and second, what exactly are these RentACoders proposing to do? 

What we need is not coding man-hours from some random people, but decisive action from Mozilla personnel to fix the paradigm which causes Firefox to display this behavior. As the maintainer assigned to this bug, Josh Aas, mentioned earlier, the roadmap for the new paradigm that will fix this bug is listed in detail at https://wiki.mozilla.org/Plugins:AdvancedKeyHandling . They are working on it (though it's been a year since that page was last updated...), so we should all shut up, as people have said multiple times.
I could be wrong, but I think the main point of hiring coders or having donations for a project is mainly to keep up visibility on this issue.  It's gone un-fixed for like 9 years, which is all keeping quiet has so far accomplished.  This particular thread though, is not the appropriate place for this discussion, hence the external project.  There's a comment thread on the fossfactory project where this discussion should take place.
blocking2.0: --- → ?
Not blocking for the same reason given in comment 244. This is high on our priority list though.
blocking2.0: ? → -
Thanks Alex for the great Firefox add-on:
https://addons.mozilla.org/en-US/firefox/addon/14054/

Moz team might want to checkout Google Chrome's code to learn how it's done lol.
Hahaha, a "top 100" bug open for like 9 (NINE) years :D

Seriously, a few points are being missed here:

1. Full page applications written in Flash or Java should not take all events by default

Rationale:
There is this thing called "tabbed browsing", and people want to be able to use Ctrl+Tab and other shortcuts to switch from your "application" to another tab or Alt+D to give focus to the address bar. Using your "application" is not a guarantee that people want their PC's I/O devices abducted by it.

2. No plugin should ever get the focus initially when the page loads

Rationale:
You should not have to "unfocus" the plugin to begin browsing the page.

3. No plugin should ever get Ctrl/Alt/Command keys

Rationale:
Ctrl/Alt/Command are modifier keys used for accessing menus and other shortcuts in the host application. Regardless of how much some developers would like to call their flash movie an "application", those keys should be always handled by the host application in much the same way your operating system always handles Ctrl+Alt+Del key combination.

Unless you want to break all GUI and accessibility design rules?

From the above it is obvious that Ctrl/Alt/Command+<anykey> should also never be received by plugins. If people want to write a full-fledged application with access to all control/modifier keys, then they should write a standalone application in a real programming language -- they should not expect from the host application to compromise its own functionality for the sake of plugins.

In my opinion, part of the main problem that has to be solved for this bug to ever get fixed is how to allow user to click on a play button on a flash video player without giving focus to the flash player plugin itself?

That should be doable even if it means giving and then immediately taking away the focus after sending the event so that the focus doesn't stay with the plugin.

Of course, there should still be a way to give focus when you want to -- for example clicking with right mouse button could give the focus to the plugin until you click outside of it with any mouse button.

Single keystrokes (arrows, letters, numbers, space, etc) should always go to the plugin when it has focus so that other things such as games and text input would still work.

Finally, the only exception to the control/modifier keys which plugins should be able to receive _when they have focus_ are CUA keys for text editing.

Hope this helps a bit.
Further useless comments will result in account termination, as per the Bugzilla Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) -- especially with regards to section 1, sub-section 1. Please be mindful of this, as it is your only warning. :)
The url of this bug has changed to http://www.adobe.com/products/flash/
(In reply to comment #379)
> The url of this bug has changed to http://www.adobe.com/products/flash/

I disagree, host application is to blame for giving up on its own functionality.
(In reply to comment #381)
> REDDIT SON!!! REDDIT!!! WE WILL NOT DISAPPOINT!!!

Hello Reddit

Everyone on this forge, including Mozilla designers, developers and users, are upset because of this bug. If you have any improvement solutions, be it design or code, your contributions are welcome.

Else, please avoid making useless noise.
I already gave some suggestions in comment #373 but nobody bothered to dispute them.

I also submitted two bugs a month ago and no updates there either even though they are clearly reproducible.
This patch tries to fix the issue mentioned in the bug, for the Gtk2/Linux version of Firefox.

It's a compromise, where some keys are sent to Firefox and some to the plugin:
- Pressing ctrl-t, ctrl-r, ctrl-w, F11 etc. always works in Firefox
- Pressing space in youtube to pause videos works
- Pressing ctrl in flash games works (but not in combination with other keys)
- Editing text in flash forms, using ctrl-a, -z, -x, -c and -v works

Hope it makes the world somewhat less annoying for someone. It works for me.
Comment on attachment 483216 [details] [diff] [review]
Patch for fixing this issue on Linux/Gtk2

Maybe we should have someone having a look at this patch?
Attachment #483216 - Flags: review?(joshmoz)
Tried the patch of #385 with my machine (Gentoo). Though, it didn't work directly. My GTK (2.20.1) defines the keysyms e.g. as GDK_F12 (and not GDK_KEY_F12). Now everything's going well...
Nice work :). Flash is much less annoying now :).
At least, gdk/gdkkeysyms.h in gtk-2.22.0 includes gdk/gdkkeysyms-compat.h which have GDK_KEY_* style of the definitions.

<gdk/gdkkeysyms.h>
/* For GTK 2, we include compatibility defines by default. */
#ifndef __G_IR_SCANNER__
#include <gdk/gdkkeysyms-compat.h> 
#endif
(In reply to comment #385)
> Created attachment 483216 [details] [diff] [review]
> Patch for fixing this issue on Linux/Gtk2
> 
> This patch tries to fix the issue mentioned in the bug, for the Gtk2/Linux
> version of Firefox.
> 
> It's a compromise, where some keys are sent to Firefox and some to the plugin:
> - Pressing ctrl-t, ctrl-r, ctrl-w, F11 etc. always works in Firefox
> - Pressing space in youtube to pause videos works
> - Pressing ctrl in flash games works (but not in combination with other keys)
> - Editing text in flash forms, using ctrl-a, -z, -x, -c and -v works
> 
> Hope it makes the world somewhat less annoying for someone. It works for me.

This is very cool if it works. Any comments on the feasibility of applying the same approach on Windows? (ie. selectively not passing through things like Ctrl-T, Ctrl-W)
i am having the same problem and i have tried to enter the ctrl- key first and the same problem keeps coming back.
I'm not allowed to point out how incredible it is that this bug will still be unsolved in Firefox 4, so instead I am filing four enhancement requests suggesting efficient workarounds for the most annoying results of this bug: (Three of them were proposed already a year ago in my Comment 333 above)

1.
Problem:
When scrolling, it stops when cursor happens to be over a YouTube video.
Solution:
Never pass scroll events to a non-focused plugin object.
[ Bug 625805 - Keyboard command enhancement: save lost scroll events (workaround for Bug 78414) ]

2.
Problem:
When cycling between tabs with Ctrl-Tab, I suddenly end up stuck in a focused plugin object.
Solution:
When showing another tab, never give back focus to a plugin object.
[ Bug 625806 - Keyboard command enhancement: keep tab navigation (workaround for Bug 78414) ]

3.
Problem:
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.
[ Bug 625808 - Keyboard command enhancement: safe click zones (workaround for Bug 78414) ]

0.
Problem:
Shortcut keys are not working for Firefox functions, they end up in the plug-in. But is anybody using them in the plug-in? Probably not nearly as often as someone is annoyed by Firefox's lack of function. And good plug-in programmers would never use these browser-common shortcuts anyway (apart from in malware), so why keep them in the plug-in?
Solution:
Never give the most important shortcuts F11, Ctrl-T, Ctrl-W, Ctrl-Tab, Ctrl-Shift-Tab, Ctrl-PgUp, and Ctrl-PgDn to a plug-in. Keep their Firefox functionality instead. *IF* users have problems with these shortcuts not working in a plug-in anymore, they will report it in this bug report system. If no reports are coming - then there was no use passing the keys to the plug-in!
[ Bug 625809 - Keyboard command enhancement: reclaim Firefox functionality (workaround for Bug 78414) ]

Please include these enhancement in Firefox 4.

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.
I agree with Comment 398 and Comment 399.
Firefox should force unfocus plug-ins by default and only if I press on this plugin field it should only take and stay focus
Maybe new variable would fix it (temporary at least)?
is_focused by default set to false (disallow plug-ins to take focus and shortcuts), and if I press somewhere inside plug-ins field it change to is_focused=true and let plug-in to take shortcuts and focus?
(In reply to comment #398)
> 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.

That's the point. It was "fairly easy" to fix near ten years ago, when this was reported. Since they decided to ignore the issue I don't think they're ever going to fix it. Lot of issues/bugs out there that are not blatant enough to get their attention.
Adding more comments here isn't necessary. It's a priority to fix, it's one of the top ten issues as far as the User Experience team is concerned, it just didn't have a clear solution for 4.0.

Personally, I care passionately about getting this fixed, and once 4.0 is out the door, this is a priority for the next release for me. It just didn't make the cut this time, which sucks — but it will be fixed eventually.

In other words, everyone agrees that it needs to be fixed, but it's a complex issue that will take some time to get right.
Whiteboard: [PL2:NA] → [PL2:NA][READ COMMENT 403 BEFORE COMMENTING][wanted2.1?]
@limi, how can you say with a straight face? The bug has existed for almost ten years now. Saying "it's a priority to fix" means nothing now, you guys have lost all credibility. Comments will continue to be necessary until this actually gets fixed.
Clear solution? Really? How about doing what the desktop environemnts/window managers do? (Firefox can't handle the [Windows] + [Tab] or [Ctrl] + [Alt] + [F1] because it's reserved for Aero, or in the latter case for Linux. How hard it would be to likewise reserve a few hotkeys? And make it configurable. Show a small icon somewhere - no need for the full info bar - and let the user enable full-capture on a per URL basis.)

Writing fancy specifications and waiting for the plugin vendors is clearly an anti-pattern.
(In reply to comment #404)
> @limi, how can you say with a straight face? The bug has existed for almost ten
> years now. Saying "it's a priority to fix" means nothing now, you guys have
> lost all credibility. Comments will continue to be necessary until this
> actually gets fixed.

I can say that with a straight face since I've only worked here for a bit over a year, and have been pushing to get this fixed since I started. Firefox 4 is the first real major release I'm a part of, and it didn't make it this time around. I'm personally following this up for our next release.

Don't assume things without having the facts. Now, please stop spamming this bug. It'll get fixed.

(In reply to comment #405)
> Show a
> small icon somewhere - no need for the full info bar - and let the user enable
> full-capture on a per URL basis.)

This isn't something that is understandable to people unfamiliar with the implementation, which is a bad way to build a UI.
 
> Writing fancy specifications and waiting for the plugin vendors is clearly an
> anti-pattern.

Plugins stealing focus is already minimized on Mac OS X, so when we have a sane way of doing it, we do it. On Windows, things are more complicated. We'll get there, but not for Firefox 4.
(In reply to comment #406)
> I can say that with a straight face since I've only worked here for a bit over
> a year, and have been pushing to get this fixed since I started. Firefox 4 is
> the first real major release I'm a part of, and it didn't make it this time
> around. I'm personally following this up for our next release.
> 
> Don't assume things without having the facts. Now, please stop spamming this
> bug. It'll get fixed.

Look at comment #124 - it's almost identical to yours. "Everyone can
stop spamming the bug and worrying that the bugs aren't going to get fixed." That was almost 5 years ago. What a joke. (BTW, nothing personal intended - I really hope you can fix this bug, just pointing out what a disaster it has been so far.)
Folks, stop spamming this bug. I'd contact each of you by personal email as I am supposed to, but the last time I did that, the person I contacted just argued with me. I have no desire to get into any arguments. I'll just state that adding comments that do not contribute to getting the bug fixed violates Bugzilla etiquette <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>. I will report the next person who spams this bug to Gerv. Don't be surprised if your Bugzilla account gets suspended.

Thanks.
Cool! After 10 years of having this problem, now we're getting threatened too! That's some etiquette...
WTF!! It's not getting fixed in Firefox 4.0!?

"Adding more comments here isn't necessary."

Oh, you couldn't possibly be more wrong about that buddy.

This bug is a dealbreaker for me. I'll stay with Chrome until this is fixed. Now I'm off to kickout Firefox. No more donations to Mozilla from me.

//Nils-Werner Claesson, Sweden
mcdreamy81, Chrome seems to suffer from the same problem. I just tried it with mine (build 8.0.552.237). Clicked pause on a YouTube video, then tried to Alt-Tab. Didn't work.
(In reply to comment #411)
> mcdreamy81, Chrome seems to suffer from the same problem. I just tried it with
> mine (build 8.0.552.237). Clicked pause on a YouTube video, then tried to
> Alt-Tab. Didn't work.

Yeah; Ctrl-Tab here on windows doesn't work in chrome either; does work on IE9, and doesn't work in minefield.  The current youtube flash apparently deals with tabs between controls.

That would suggest that the appropriate solution is not to ask the plugin whether a key can be handled (seemingly chrome's behavior), but to always handle browser keyshortcuts (seemingly IE9 beta's behavior).
Well, maybe temporary provide some "release focus" key combination?
It would be AMAZING, because I hate to switch to mouse because of lack of major keyboard functions

I know, we shouldn't write, but any good idea is wanted to resolve this fast.
HaWaN, have you tried this extension?

https://addons.mozilla.org/en-US/firefox/addon/unfocus/

It's a bit of hack but it seems to work.
Having read the comments in patch proposed by Alexander Rødseth, I must note it is a bit unfair to both sides:
- Web applications should have the ability to receive any key, including modified and even function keys, since only then the long-term dream of web apps replacing desktop ones can be achieved;
- Browser should have the ability to receive any key, including unmodified, regular ones, since there exist elaborate plugins (like Pentadactyl or Vimperator) which allow user to control browser using these simple keys (<d> to close tab, <H> to go back etc.) - it's just faster when the browser is not used to input text.

So I think it's better to reserve some keystrokes for browser and leave the rest for web applications. If this is not possible (which would be sad) then we could only resort to implementing a switch key.
>... since only then the long-term dream of web
>apps replacing desktop ones can be achieved;

Isn't it obvious that Web applications can replace desktop applications only when web browsers fully replace operating systems?

Just because someone failed to grasp such an obvious fact in their wet dreams does not mean that all of us who use other things next to web apps should suffer.
> Isn't it obvious that Web applications can replace desktop applications only
> when web browsers fully replace operating systems?

Hmm... no, web browsers could just use operating systems, being additional layer between them and web applications (like existing libraries and virtual machines already provide for desktop apps).

But remember we could be threatened again to be banned if we continue discussion on this broader topic. I just thought that Mozilla supports this view of web apps, so such patch I think won't be officially merged.
(In reply to comment #417)
> Hmm... no, web browsers could just use operating systems, being additional
> layer between them and web applications (like existing libraries and virtual
> machines already provide for desktop apps).

Um... no, because the difference between a virtual machine and a browser is that guest OS running in a VM cannot take over host OS' keyboard shortcuts like you suggest web apps should be able to.
(In reply to comment #418)
> (In reply to comment #417)
> > Hmm... no, web browsers could just use operating systems, being additional
> > layer between them and web applications (like existing libraries and virtual
> > machines already provide for desktop apps).
> 
> Um... no, because the difference between a virtual machine and a browser is
> that guest OS running in a VM cannot take over host OS' keyboard shortcuts like
> you suggest web apps should be able to.

I meant Java Virtual Machine and similar environments.
(In reply to comment #415)
> - Web applications should have the ability to receive any key, including
> modified and even function keys, since only then the long-term dream of web
> apps replacing desktop ones can be achieved;

Although you amend this a little further on I just want to point out that this is exactly opposite to the experience gained from multitasking operating systems in the last decades. If the plugin/web-app/etc is to behave w.r.t. the browser like an application does w.r.t. the operating system, events and resources should trickle or be requested from the browser so that they do not interfere with the resources of other apps or the events that are expected to be handled by an encompassing level (such as kernel or browser). A keystroke is such an event. Just like you expect your OS to act in a specific way to e.g. ctrl-alt-del or alt-tab there are also browser bindings of this kind, especially when it comes to switching focus or closing a tab or window. Right now there is simply no way to close the tab or switch to another one with the keyboard if a plugin has focus. That is definitely not the correct thing to do, whatever philosophy, architecture or dream we intend to follow.
The comment above is exactly what I had in mind, thank you for explaining it so nicely.
"Right now there is simply no way to close the tab or switch to another one with the keyboard if a plugin has focus. That is definitely not the correct thing to do, whatever philosophy, architecture or dream we intend to follow."

No Sir, apps should behave like the apps they are. When a browser is in use, standard browser keys should always work, regardless of which site I visit. 'dont allow any site to alter the browser's expected behavior - the browser is supposed to behave in a particular way =- regardless of which site is being visited'. That means Ctrl-T always opens new tab, and a site cannot code itself to go fullscreen and capture all those key commands meant to be handled by the browser.
(In reply to comment #420)
> (In reply to comment #415)
> > - Web applications should have the ability to receive any key, including
> > modified and even function keys, since only then the long-term dream of web
> > apps replacing desktop ones can be achieved;
> 
> Although you amend this a little further on I just want to point out that this
> is exactly opposite to the experience gained from multitasking operating
> systems in the last decades. If the plugin/web-app/etc is to behave w.r.t. the
> browser like an application does w.r.t. the operating system, events and
> resources should trickle or be requested from the browser so that they do not
> interfere with the resources of other apps or the events that are expected to
> be handled by an encompassing level (such as kernel or browser). A keystroke is
> such an event. Just like you expect your OS to act in a specific way to e.g.
> ctrl-alt-del or alt-tab there are also browser bindings of this kind,
> especially when it comes to switching focus or closing a tab or window. Right
> now there is simply no way to close the tab or switch to another one with the
> keyboard if a plugin has focus. That is definitely not the correct thing to do,
> whatever philosophy, architecture or dream we intend to follow.

Ok I was a little unclear but I wrote about this later in that comment #415: There's no objection on that shortcuts should be divided between browser and web apps. It would be the best solution. I just thought that the approach in that specific patch is unfair.

I did not intend for web apps to receive literally ALL keystrokes, but to be able to receive all TYPES of keystrokes, including modified (if not already used by browser).

The problem here is that the keys set used by browser might differ per browser, and especially with Vimperator-like addons, so web apps' keys might be blocked, and so it's better to provide means to rebind them to available ones.
Plugin ability to receive keys should be limited so it does not interfere with, or disable the functionality of the host application (browser).

That should be the main concern for everyone who ever tries to fix this bug, regardless of the way they intend to do that. If you want to push for an API, then by all means do it, but _we need an interim fix_ that will enable us to escape the plugin wrath *NOW*.

What I suggest is that at least the following key combinations:

- Alt+D
- Alt+F4
- Ctrl+Tab
- Ctrl+T
- Ctrl+W/Ctrl+F4

Be reserved for the browser with no way for plugins to override them.

For the last 10 years, basic browser functionality of page and tab navigation is broken when there is a plugin on a page.

Only after someone makes a patch with those keys working properly when there is a plugin on the page, and after end users can download it, only then it will make sense to continue debating and perhaps working on a better solution.

It is very bad to do nothing because you cannot find a way to please everyone.

Finally, let me remind you that developers of web applications and "visionaries" who are pushing for web-centric development are a minority when compared to the number of people using the browser -- they should not be the ones to decide what is best for the rest of us.
(In reply to comment #424)
> What I suggest is that at least the following key combinations:
> 
> - Alt+D
> - Alt+F4
> - Ctrl+Tab
> - Ctrl+T
> - Ctrl+W/Ctrl+F4

Please also add to this list:

- Ctrl+numbers (for cycling between tabs)
- Ctrl+L (address)
- Ctrl+K (search bar)

> Be reserved for the browser with no way for plugins to override them.

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #424)
> What I suggest is that at least the following key combinations:
> 
> - Alt+D
> - Alt+F4
> - Ctrl+Tab
> - Ctrl+T
> - Ctrl+W/Ctrl+F4
> 
> Be reserved for the browser with no way for plugins to override them.

If such temporary solution is possible to get in 4.0, then +1, it's better than nothing. But what about a simple Esc key, which would exit plugin mode, and allow entering any shortcuts to browser (as a temporary solution)? This way we wouldn't have to agree on exact list of reserved keys: all keys except Esc could be used in both plugin and browser mode.

And as for better (later) solution, we can allow all keys without switching mode, and allow user to rebind conflicting ones on the side of plugins.
I guess the long term solution would be giving plugins a way to query the browser for which keys/combinations they are entitled to receive.
Amidst the lots of comments I found out that they already decided on solution: https://wiki.mozilla.org/Plugins:AdvancedKeyHandling

If I understand it correctly, this means the plugin will decide (after it will be updated for new API) whether or not pass the key. Can't say I like this solution; seems unnecessary cumbersome, and non-standard shortcuts could not work (what if it'll be another browser with different shortcuts, or is this API for Firefox only?).
Is there any reason the browser can't display an alert or menu bar informing the user that a plugin would like to commandeer some key bindings (and which ones preferably), and let the user decide whether to do that (the default being to deny)?
(In reply to comment #428)
> If I understand it correctly, this means the plugin will decide (after it will
> be updated for new API) whether or not pass the key.

That's how I read it also. It also seems like this is basically what we have now, just minus a fancier API to deny me access to regular keyboard shortcuts.
(In reply to comment #429)
> Is there any reason the browser can't display an alert or menu bar informing
> the user that a plugin would like to commandeer some key bindings (and which
> ones preferably), and let the user decide whether to do that (the default being
> to deny)?

Yes there is, if you have an average of 10 flash ads on a page, it would spam you to death with those alerts for each and every page you visit.

(In reply to comment #426)
> This way we wouldn't have to agree on exact list of reserved keys:

We do not have to agree at all -- browser itself already has a list of reserved keys, and browser addins should also be able to register additional reserved keys.

The idea with plugin deciding what keys to handle is retarded. It should be exactly the opposite -- plugin is a GUEST, browser is a HOST. You do not let guests to do whatever they want in your house.
(In reply to comment #431)
> (In reply to comment #429)
> > Is there any reason the browser can't display an alert or menu bar informing
> > the user that a plugin would like to commandeer some key bindings (and which
> > ones preferably), and let the user decide whether to do that (the default being
> > to deny)?
> 
> Yes there is, if you have an average of 10 flash ads on a page, it would spam
> you to death with those alerts for each and every page you visit.

Agree. 

> (In reply to comment #426)
> > This way we wouldn't have to agree on exact list of reserved keys:
> 
> We do not have to agree at all -- browser itself already has a list of reserved
> keys, and browser addins should also be able to register additional reserved
> keys.
> 
> The idea with plugin deciding what keys to handle is retarded. It should be
> exactly the opposite -- plugin is a GUEST, browser is a HOST. You do not let
> guests to do whatever they want in your house.

It's going to break most apps if we filter *all* keys which can be handled by the browser and don't pass them to the plugin, since this includes page up/dn, Esc (think closing a fullscreen flash video), the arrow keys, etc. Taking a look at http://support.mozilla.com/en-US/kb/keyboard%20shortcuts we have a couple of categories:

* Navigation applies to the current tab
* Current Page, Editing and Search apply to the current page
* Windows & Tabs applies to the whole browser or the current window
* Tools are for accessing certain cross-window/tab browser functionality
* Miscellaneous' scope varies

What I would like is that at least the Windows&Tabs and Tools keys are filtered since those are used to do stuff that is completely out of the scope of the plugin or the page it is displayed on. Perhaps it would be wise to not filter the function keys. The rest can be handled by NPAPI:AdvancedKeyhandling.
Can I respectfully suggest that discussion not rapidly occur on a bug with 315 CC's on it? I've already removed my email address from the CC list, but I'm continuing to get emails with every comment here. I wouldn't be surprised to find other people in this situation.
But we're engaged in a critically important discussion of what color the paint the bikeshed <http://bikeshed.org/>!!!

But seriously, folks, let's move this discussion to, say, <http://forums.mozillazine.org/viewtopic.php?f=38&t=1693495> where anyone can discuss how Firefox should handle this issue.
I'd like to add some suggestions to the list in comment 425:

Esc
Ctrl R
Ctrl Z
Ctrl X
Ctrk C
Ctrl V
Ctrl B
Ctrl N
Ctrl P
Ctrl E (this was a jump to search on the nav-bar, then Panorama, but was recently unmapped)
Ctrl+shift+E
Ctrl+shift+R
Ctrl+shift+J
Ctrl+A
Ctrl+S
Ctrl+F
Ctrl+Shift+D
Ctrl+home
Ctrl+end
Ctrl+shift+home
Ctrl+shift+end
Alt+[left/right arrow]
Tab/Shift+Tab
Ctrl+Shift+V
Ctrl+Shift+S

Those are all commonly used in most productivity applications in windows and I'd go out on a limb and say that users who use keyboard shortcuts will expect similar behaviour from this shortcuts in different applications, not just browsers.  Those are all one I use daily.  I may have forgotten some.  All of these have Mac equivalents if I'm not mistaken.

The tab key alone would be a life saver for escaping flash apps!  Tab should get you off of a flash element eventually, but currently will only get stuck jumping around elements in the flash app, which I would call inconsistent UI behaviour.
In response comment 424: mozillazine is a third party site, not actually affiliated with mozilla.  Discussion there has little bearing on what happens here.
"READ COMMENT 403 BEFORE COMMENTING" -- I did, but this needs to be said.

THIS IS A CRITICAL FLAW! GOING TO 'FULL SCREEN' ON A WINDOWS MACHINE CAN CAUSE YOU TO LOSE CONTROL OF YOUR COMPUTER UNLESS YOU KNOW WINDOWS KEYBOARD SHORTCUTS!

The reality is that the majority of Windows users don't know even basic keyboard shortcuts -- they rely completely on their mouse. _IF_ they have selected to auto-hide their toolbar AND they select 'Full Screen' from the menu, there is NO WAY for them to recover control of their machine unless they know to:
1. press the 'Windows' key or Ctrl-ESC to bring up the Start menu
2. right-click on the correct taskbar button 
3. select 'Close'

I KNOW that this can happen as I've had panicked calls from friends reporting this situation and asking me what to do. They know that they need to press F11 to get out of full screen mode, but it doesn't work.

So PLEASE (please, please, please,...) implement SOMETHING -- a fix, a hack, a kludge, whatever -- to allow F11 to work and THEN concentrate on doing this properly.
It's a priority already, just more complicated than you want it to be to fix.

If you have an amazing whizz-bang solution, great!  Please provide it in the form of a patch or an add-on.  If you don't know how to write those, I'm sorry to say you cannot possibly understand the internal plumbing problems that are almost guaranteed to exist in your proposed solutions.

Just because you want a car to run without using any form of coolant, doesn't mean proposing "just stop putting coolant in" is helpful.  That part is obvious, and maybe completely impossible.  A practically feasible and detailed technical plan is required.

Mozilla's developers are not fools, this bug hasn't remained unfixed because no one realized "hey, we could just pay attention when the user presses <key> instead of letting the plugin do it."  "Wow, I can't believe I never thought of that.  You're so smart!"  Treating them as if they are this dumb is a great form of repellant you're dousing this bug with.  Congrats.

So please answer this bug with source code rather than more repeat comments (nothing has been posted in the last several weeks that hasn't been posted to this bug before.)  Talking on a third-party forum elsewhere to develop this source code is a very wise and effective solution.

Sorry for replying again.

-[Unknown]
(In reply to comment #438)
> If you have an amazing whizz-bang solution, great!  Please provide it in the
> form of a patch or an add-on.  If you don't know how to write those, I'm sorry
> to say you cannot possibly understand the internal plumbing problems that are
> almost guaranteed to exist in your proposed solutions.

For fairness sake, isn't there an head-on problem with chosen solution:
- plugins must be updated for this to work. If they won't be all updated (since there are many of them), in these cases plugin won't pass anything, and no events would be processed by browser;
- even if updated and intending to behave nicely, plugins just can't know which shortcuts they can use freely, and which are used for fundamental browser functions (there's no API for that). What if there are keys changed/added by addons, or if it's another browser with completely different shortcuts?
(In reply to comment #439)
> For fairness sake, isn't there an head-on problem with chosen solution:
> - plugins must be updated for this to work. If they won't be all updated (since
> there are many of them), in these cases plugin won't pass anything, and no
> events would be processed by browser;
> - even if updated and intending to behave nicely, plugins just can't know which
> shortcuts they can use freely, and which are used for fundamental browser
> functions (there's no API for that). What if there are keys changed/added by
> addons, or if it's another browser with completely different shortcuts?

Not only that, but for proposed API to be successfull (even though it is "bass ackwards" to begin with) all browser vendors (Opera, Microsoft, Google, Mozilla) have to sit together with plugin vendors and work on specification. I don't see that happening in any foreseeable future. It means that this bug will never be resolved from an end user point of view. It won't make it into IE9, Opera 11, Firefox 4 and whatever is the latest version of Chrome.

(In reply to comment #438)
> It's a priority already...

Newsflash: If something is a priority, then you devote more resources to work on it. There has been _no progress for 10 years_ here.

So either nobody is working on it (which means it is not a priority), or those working on it are totally incompetent. Take your pick.

(In reply to comment #438)
> ... you cannot possibly understand the internal plumbing problems...

And we don't have to understand them. When you go to a mechanic to change your car's air filter you don't care whether mechanic has to take the engine apart or just to open the hood as long as he changes the filter. Software developers have become awfully spoiled prima donnas lately.

(In reply to comment #438)
>A practically feasible and detailed technical plan is required.

Please don't insult everyone's intelligence here by saying that it takes 10 years to do that.

(In reply to comment #438)
> Treating them as if they are this dumb is a great
> form of repellant you're dousing this bug with.

The mere existence of this bug for 10 years speaks for itself. It is time for this issue to get the attention of wider audience, and because you are treating end users "as if they are this dumb", I am now personally going to take care of that either by contacting some IT journalists that I know, or by writing an article myself. Enough is enough.
Let's not bicker and argue about who killed who... 
let's try to be humble and constructive for a while.

The main problem has not been solved for 10 years because it is fundamentally complex and partly out of the developers' reach. This is understandable.
The users, on the other hand, are very eager to get rid of the problem's symptoms because they are very annoying. This is also understandable.

To be realistic, the main problem will probably not be solved in several years - but note that the users don't primarily want a solution to the problem, they primarily want to get rid of the *symptoms*! Some of these can be avoided even long before there exists a solution to the main problem, even if it doesn't help at all in finding that solution.

To take the car with the broken cooling system as an example again:
The mechanic wants to fix the cooling system, otherwise the car is not considered functional from his/her point of view, but due to missing components the repair has to wait.
The owner, on the other hand, primarily needs a car that can be driven, even if it means driving slowly for a minute with the hood open and then stopping to cool the motor down for 5 minutes. This car is worth much more than a car that stands still waiting for the perfect repair, even if both of them are considered just as non-functional from the mechanic's point of view.

What I'm aiming at here is that *workarounds* are getting more and more important.

* On a 10-year perspective, I'd prefer to have this bug solved by having the webcam track the user's eyes, and only pass key events to the plug-in when the user looks at it. It's a logical and handy solution and I'm sure that it is doable in that timeframe. (What I'm not sure about is whether Chrome will be the only existing browser left to make use of it, or if Firefox is still around.)

* On a somewhat shorter perspective, I'd prefer a solution where key events are only passed to the plug-in while the mouse pointer hovers it. It makes more sense than the current behaviour, and it doesn't raise as many standardization questions as other solutions. (Btw, it seems like some scroll events already work in this way, in some respect.)

* But first of all the behaviour should be improved as much as possible with workarounds, even if they are not at all part of a way to the solution of the main problem. For instance, the problems with focused plug-ins stealing key events can be made less annoying if Firefox actively removes the focus from the plug-in at various points in time, for instance when switching between tabs or windows, or when the user in other ways indicates that he/she doesn't currently use the plug-in.
Are there any specifications or design rules or users that demand that the plug-in should keep its focus in all such cases? Probably not. Please discuss and vote for the workaround Bug 625806 to handle tab/window switching in a better way, and please discuss and vote for the workaround Bug 625808 to simplify for the user to take focus from a plug-in. Moreover, the very annoying lost scroll events mentioned in parenthesis above seems to be handled in Bug 483136, so please discuss and vote for that one too. None of them solves this (unsolvable) bug, but it reduces the user annoyances from it. Also suggest other workarounds that you can come up with, even as suggested add-ons. Thank you.
Idea with a webcam fails when a plugin takes whole window (PDF reader for example) -- user simply has nowhere else to look.

Problem here is that browser keyboard shortcuts (and thus keyboard navigation) simply do not work in the presence of plugins -- either at all, or as intended (see related Bug #627315 which I reported recently).

That problem is easy to solve by not passing reserved key combinations to plugins, at least those that I listed in Comment #424.

If some plugins break because of that then let those who use such plugins report a bug, and then kindly refer them to the web app developer who mindlessly (ab)used reserved key combination(s) when they wrote their web app.

In the meantime, work with plugin vendors and web app developers to define an API which would enable them to receive reserved keys if absolutely necessary and with user consent which will be remembered as a per-site preference. That is how it should have been done in the first place if anyone involved cared about user experience.

Instead, what we have for the last 10 years is a *kludge* that enables plugin vendors and web app developers to do whatever they want with keyboard events, and nobody is doing anything to fix it because both plugin vendors and web app developers got what they wanted -- they have no incenitive for a change because that change requires work on their end.

After 10 years, I believe it is about time to return (keyboard) control to the end user, because plugin vendors and web app developers have shown themselves as irresponsible and careless so far. They need to be brought into a position which will force them to act in order to get what they want, instead of having everything at their disposal by default.
(In reply to comment #440)
> all browser vendors (Opera, Microsoft, Google, Mozilla) have to sit together with plugin vendors and work on specification.

I don't know about Chrome nor Opera, but IE has never had this issue. Plugin interaction and other controls (tabs, browser shortcuts, ...) have been working nicely even in IE6! Safari 4 doesn't seem to suffer from that either.

PS: I know this doesn't help. Please someone implement the key-ignoring scheme as told in comments 424, 425 and/or 435 for Firefox 4. This will already be a workaround good enough for the vast majority of the use cases.

PPS: If adding a few if statements in the key handling in the NSPlugin controller is difficult enough to require an architectural change, well... Too bad!

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
Attached is a patch for working around in the GTK2 and Windows NSPlugin containers.

Here is how it has been obtained:

  1. Download ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0b10/source/firefox-4.0b10.source.tar.bz2
  2. Extract it once as firefox-4.0b10, and a second time as firefox-patch-78414
  3. Modify the files in firefox-patch-78414
  4. Extract the diff using:
    diff -ur firefox-patch-78414/ firefox-4.0b10

The expected behaviour after this patch:

  * On GTK2, the plugin gives focus to parent (i.e., the Web page) when:
    - key presses F1 to F24
    - any key pressed together with a modifier (CTRL or ALT), except for
      CTRL + Z, CTRL + Y, CTRL + A, CTRL + C, CTRL + V, CTRL + X
  * On Windows, the plugin shall loose focus when either any key from F1
    to F24, CTRL or ALT is down

On MacOS X, the current behaviour is the following:

  * When a plugin is focused, CMD + W, CMD + K, CMD + L, CMD + ALT + LEFT/RIGHT, ... are redirected to Firefox
  * Only CMD + 0 up to CMD + 9 are eaten by the plugin

Can anyone verify?

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
Attachment #508230 - Attachment is patch: true
Attachment #508230 - Attachment mime type: application/octet-stream → text/plain
The patch doesn't work for me on Windows. PluginWndProc does not receive any events when the plugin is focused and keys are pressed. Additionally, PostMessage WM_KILLFOCUS doesn't have any effect even when it does get executed. I believe the former issue has been hinted at in the early comments on this bug.

My own kludge sets a timer and uses GetKeyState to observe keys being pressed, but being thorougly unfamiliar with the codebase I could not find the right widget to focus.

To summarize:

    ::PostMessage(hWnd, WM_KILLFOCUS, NULL, NULL);

doesn't unfocus the plugin at all for me; it still shows the yellow focus rectangles and TAB tabs through the plugin's controls.

          nsCOMPtr<nsIWidget> widget;
          win->GetPluginWidget(getter_AddRefs(widget));
          while (widget != NULL)
          {
            widget->SetFocus(false);
            widget = widget->GetParent();
          }

This unfocuses the plugin (TAB no longer tabs through plugin's controls), but whatever this does focus is not what we want; all keys are still swallowed. Moreover, Alt+Tab and back re-focuses the plugin. So my snippet is pretty wrong too.

Would it make more sense to discuss the specifics of the workaround patch in bug 625809?
(In reply to comment #446)

Hello

Thanks for the testing. Could you please modify the code in order to:

  1. Get the HWND of the parent
  2. Send a message WM_SETFOCUS to that HWND after having sent WM_KILLFOCUS
     to the plugin

PS: 625809 is marked as a duplicate...

Thank you

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #442)
> Idea with a webcam fails when a plugin takes whole window (PDF reader for
> example) -- user simply has nowhere else to look.

Sounds a bit tragic. For some people it would work. There is a whole world outside the computer screen. :-)

> Problem here is that browser keyboard shortcuts (and thus keyboard navigation)
> simply do not work in the presence of plugins -- either at all, or as intended
> (see related Bug #627315 which I reported recently).
> 
> That problem is easy to solve by not passing reserved key combinations to
> plugins, at least those that I listed in Comment #424.
> 
> If some plugins break because of that then let those who use such plugins
> report a bug, and then kindly refer them to the web app developer who
> mindlessly (ab)used reserved key combination(s) when they wrote their web app.

Sounds perfect. This is exactly what the workaround Bug 625809 suggests. I'd expect very few bug reports and many many more happy Firefox users if the problem is turned around like this.
(In reply to comment #447)
>   1. Get the HWND of the parent
>   2. Send a message WM_SETFOCUS to that HWND after having sent WM_KILLFOCUS
>      to the plugin

No change. I've also tried:

          HWND parent = GetParent(hWnd);
          if (parent)
            SetFocus(parent);
and
          HWND parent = GetParent(GetFocus());
          if (parent)
            SetFocus(parent);

The above examples clear the yellow focus rectangle, but TAB still tabs through the plugin's controls.

I think this is the wrong approach though; https://developer.mozilla.org/en/Code_snippets/Finding_Window_Handles suggests that there is only one native window in Firefox 4. I reckon something like my "widget->GetParent()" snippet is required.

Some help from anyone familiar with how to locate the tab widget and focus it properly would be appreciated.
I belive, that END USERS would be IN LOVE for Mozilla if, at least, may this
workaround that we are speaking here, land in Firefox (if 4.0 then better for
Mozilla)

Just don't let browser shortcuts to be gone and END USERS will be HAPPY!
Any dev's shouldn't force browser to be frozen because of lack of major
functionality...
(In reply to comment #449)
> I think this is the wrong approach though;
> https://developer.mozilla.org/en/Code_snippets/Finding_Window_Handles suggests
> that there is only one native window in Firefox 4. I reckon something like my
> "widget->GetParent()" snippet is required.

The page indicates indeed that the parent HWND is the browser itself (and not the Web page nor the tab). I guess we need to focus some "focusable" element (text box, text, ... and NOT a whole window).

The CPP file has a GetProp of NS_PLUGIN_WINDOW_PROPERTY_ASSOCIATION on the HWND. Can you please check if the HWND has other properties assigned, perhaps we can find the hosting Web page that way...

Also, did anyone check the patch for GTK2 (Linux)? If the patch for Linux seem to work fine, can anyone check it on to the trunk?

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #446)
> Moreover, Alt+Tab and back re-focuses the plugin. So my snippet is pretty wrong
> too.
> 

Hmm, i think it happens, because patch has brought focus from plug-in to window, but then Firefox after any key combination will focus again on plug-in (because plug-in still has focus somewhere deeper)

There must be some way to kill plug-in focus, only then it will be able to use combinations without losing focus again
There is an Unfocus add-on that seems to do this well, although right now it's implemented as a command line option. It's in JavaScript of course, but how about using the same underlying mechanism? Looking at the source (save xpi as zip and open components/cmd.js), this appears to be the code that actually does the unfocusing:

function unfocus() {
    var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"]
                    .getService(Components.interfaces.nsIWindowMediator);
    var browserWindow = wm.getMostRecentWindow("navigator:browser");

    if(browserWindow.document.commandDispatcher.focusedElement)
        browserWindow.document.commandDispatcher.focusedElement.blur()

    browserWindow.focus();
    browserWindow.focus();
}
(In reply to comment #453)
>     if(browserWindow.document.commandDispatcher.focusedElement)
>         browserWindow.document.commandDispatcher.focusedElement.blur()

Great! :)

Does anyone know what blur() calls on the C++ side? Perhaps if we call the same methods when the plugin is focused and CTRL/ALT/Fx are pressed this will be worked around pretty nicely.

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
https://developer.mozilla.org/en/DOM/element.blur
The blur method removes keyboard focus from the current element. 

So blur() is a keyboard focus.

Only way is to push text focus to another place (somewhere outside plug-in)
Few caveats regarding Windows code:

1. If you call SetFocus() API, it internally sends WM_KILLFOCUS to the current focus owner, and WM_SETFOCUS to a window whose HWND you passed in. That means it is not necessary to kill focus manually first, because it is done automatically.

2. If Firefox does not set parent window for plugins (which I doubt it can do anyway), your GetParent() call may return NULL. In that case, SetFocus() won't work.

3. GetFocus() returns window handle only if that window is attached to the calling thread's message queue which I doubt to be the case for plugins.

So, most likely a proper way to SetFocus() would be to find browser window's HWND by using some built-in method from the browser code itself.
Hello

(In reply to comment #456)
> So, most likely a proper way to SetFocus() would be to find browser window's
> HWND by using some built-in method from the browser code itself.

Does that resemble the code in coment 446 ?

>           nsCOMPtr<nsIWidget> widget;
>           win->GetPluginWidget(getter_AddRefs(widget));
>           while (widget != NULL)
>           {
>             widget->SetFocus(false);
>             widget = widget->GetParent();
>           }

Roman, can you please test with a Windows patch that does not SetFocus(false) to everything but rather finds the topmost widget (i.e. the widget just before the GetParent became NULL) and call SetFocus(true) on that one?

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
How about the browser window itself? That's what the rest of the Unfocus JS code does:

    var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"]
                    .getService(Components.interfaces.nsIWindowMediator);
    var browserWindow = wm.getMostRecentWindow("navigator:browser");

    browserWindow.focus();
What is the C++ code for getting to the browser itself?

https://developer.mozilla.org/en/Code_snippets/Finding_Window_Handles says it should be something like:

>    nativeWindow hwnd;
>    nsresult rv = window->GetParentNativeWindow(&hwnd);
>    if (NS_FAILED(rv)) return NULL;
>    return (HWND)hwnd;

Can anyone test?

Cheers

S. Ali Tokmen
http://ali.tokmen.com/
(In reply to comment #454)
> >     if(browserWindow.document.commandDispatcher.focusedElement)
> >         browserWindow.document.commandDispatcher.focusedElement.blur()
> Great! :)

I don't know how to do the equivalent in C++ :)

> Roman, can you please test with a Windows patch that does not SetFocus(false)
> to everything but rather finds the topmost widget (i.e. the widget just
> before the GetParent became NULL) and call SetFocus(true) on that one?

Done that; no luck.

> widget->GetTopLevelWidget();
> widget->SetFocus(true);

No luck either.

>    nativeWindow hwnd;
>    nsresult rv = window->GetParentNativeWindow(&hwnd);
>    if (NS_FAILED(rv)) return NULL;
>    return (HWND)hwnd;

Couldn't turn this into something that compiles. I have an nsPluginNativeWindowWin and an nsIWidget, neither of which has a GetParentNativeWin.

I'm sorry but I don't want to keep poking in the dark. I encourage everyone who wants to keep trying to follow the instructions in https://developer.mozilla.org/En/Simple_Firefox_build - they worked perfectly for me (although there was a lot of waiting involved).
(In reply to comment #460)
> I'm sorry but I don't want to keep poking in the dark. I encourage everyone who
> wants to keep trying to follow the instructions in
> https://developer.mozilla.org/En/Simple_Firefox_build - they worked perfectly
> for me (although there was a lot of waiting involved).

Thanks for the link; I'll set up a FF build environment on my machine when I have a little more time and look at the component hierarchy in some more detail. My last time poking around in the Firefox source code was when it was still called phoenix, so it's gonna take a while to get familiar with the code-base again :-). Still, this "feature" has been annoying many people for years, so it's worth it.
Flags: in-testsuite?
Flags: in-testsuite?
Also, viewing an SWF in the entire browser area COMPLETELY disabled keyboard shortcuts.
(In reply to comment #462)
> Also, viewing an SWF in the entire browser area COMPLETELY disabled keyboard
> shortcuts.

Exactly, and this is a common issue with today's web. What is even worse, keyboard shortcuts are still disabled after visiting another tab or another window. It's extremely annoying when Alt-Tabbing through different tabs gets interrupted by some old tab that still steals all keyboard events.

However, there is a suggested simple workaround for this, please give it priority:
Bug 625806 - "Keyboard command enhancement: keep tab navigation"
There is no reason to wait for a solution to the whole shortcut key handling issue before fixing the worst results like this, especially the easily-fixed ones.
Dearest Friends,

OMG please fix this.

Blessings,
Shahar
(In reply to comment #464)
> Dearest Friends,
> 
> OMG please fix this.
> 
> Blessings,
> Shahar

We have a voting system here, if you just look closer to the top of the page.

Sorry for the bugspam guys.
(In reply to comment #465)
> We have a voting system here, if you just look closer to the top of the page.

Probably one of the best ways to get a bug ignored is to vote for it.
10 years and the bug is still not fixed, despite the user outcry? Unbelievable! Even Microsoft will not drag their feet so long. So much for Mozilla, time to switch to Chrome.
(In reply to comment #468)
> So much for Mozilla, time to switch to Chrome.

Chrome has its own problems. Mozilla is hard at work making FF a Chrome clone anyway. You shouldn't have to wait to long for all the reasons you didn't use Chrome to come to Firefox.
For the record, I tried this under Chrome, and f11, ctrl-t, and ctrl-r do NOT work when the flash app I was using had the focus.
(In reply to comment #470)
> For the record, I tried this under Chrome, and f11, ctrl-t, and ctrl-r do NOT
> work when the flash app I was using had the focus.

You are correct, both FF and Chrome have the problem. On the other hand IE and Safari do not: a great example of open vs closed source. While Mozilla developers continue talking how fundamentally difficult this problem is, their closed source competitors simply work as expected.
(In reply to comment #471)
> (In reply to comment #470)
> > For the record, I tried this under Chrome, and f11, ctrl-t, and ctrl-r do NOT
> > work when the flash app I was using had the focus.
> 
> You are correct, both FF and Chrome have the problem. On the other hand IE and
> Safari do not: a great example of open vs closed source. While Mozilla
> developers continue talking how fundamentally difficult this problem is, their
> closed source competitors simply work as expected.


Wow I won't even begin to explain the fallacies in that statement. Can someone ban this guy from the thread?  inb4 Microsoft false flag instigator.
I don't know about Safari, but at least in IE this is a fact. It doesn't block the Ctrl+T, Ctrl+Tab, and Ctrl+F4 - the three most important key combos when Flash video has the focus. What's so 'fallacious' about this statement that makes you feel he should be banned from the thread? Please enlighten others.
As a user, I can say this: This bug has been semi-fixed, outside of flash/shockwave/java objects, the shortcut keys now work, but when viewing flash/shockwave/java from local media, the shortcuts still do not work.
(In reply to comment #478)
> As a user, I can say this: This bug has been semi-fixed, outside of
> flash/shockwave/java objects, the shortcut keys now work, but when viewing
> flash/shockwave/java from local media, the shortcuts still do not work.

So, good work, says I :D
If you click on the window title, it still does not work. It's not only if the plugin has the focus...it's if the plugin is running.

just my $2.
(In reply to comment #482)

But clicking the window title doesn't change the focus, does it?
I wouldn't know...
I don't think that a plugin can have the focus, windows have the focus, not a plugin running inside it.
I wouldn't know...
I don't think that a plugin can have the focus, windows have the focus, not a plugin running inside them.
(in reply to comment #485)

Plugins can have focus (or rather a manifestation of a plugin, such as a particular embed tag, can have focus). Links can have focus. A lot of GUI elements within a window and on a rendered page can have focus. Please read the 481 comments made before yours.
Comment on attachment 483216 [details] [diff] [review]
Patch for fixing this issue on Linux/Gtk2

This patch denies plugins many events that they have always received and thus it'll break a non-trivial number of existing plugin-based applications.
Attachment #483216 - Flags: review?(joshmoz) → review-
Wonderful ! To hell with those 'non-trivial' number of plugins who don't know how to behave. They will have to update themselves, including Adobe Flash. 

Waiting for Windows patch. 

Thanks for fixing this bug superman :)
I use Alt-D to get to the address bar, and whenever there's any kind of video or flash e.g. a Youtube video but sometimes less obvious things anywhere on the page it doesn't work.  I just checked and Alt-D works in IE9 even when there is a Youtube video actually playing.  Any chance of getting this fixed?   I have Firefox 4.0.1 with Windows XP Home.  

I find it difficult to believe that this is a manifestation of a 10-year old bug.  I'm not sure I've noticed the other problems.  For some reason or other (maybe Firefox-related, I can't remember) I've been using CTRL-W instead of CTRL-F4 recently, but some programs don't have CTRL-W, so I would like to be able to go back to CTRL-F4.
>Comment on attachment 483216 [details] [diff] [review]
>Patch for fixing this issue on Linux/Gtk2

No, it's false. It fixes Youtube video, but many other flashes are not fixed.

And also if you activate other oprogram window and then click to flash in firefox, it will false in Youtube too.

I found that browser Midori work perfect, and it have not this bug. But it's alpha and webkit.
The problem with NPAPI - if I interpreted it correctly - is that it is a cooperative solution, the plugin has to give focus back. So with old plugins it doesn't seem to solve anything. And even after that the user is completely left out of the loop, as you still can't configure which keys don't get sent to the plugin. Though it'd be better by lightyears than the current state.
Keywords: common-issue?
Josh Aas, which events should be let through, in order to not break a non-trivial number of existing plugin-based applications? It's a fairly minimal amount of key press events that are blocked in my Gtk2 patch (and as I understand, people want additional keys to go to Firefox, like Ctrl-F4 and Alt-D).

S. Ali Tokmen, please give credit where credit is due.
(In reply to comment #495)
> Josh Aas, which events should be let through, in order to not break a
> non-trivial number of existing plugin-based applications? It's a fairly
> minimal amount of key press events that are blocked in my Gtk2 patch (and as
> I understand, people want additional keys to go to Firefox, like Ctrl-F4 and
> Alt-D).
> 
> S. Ali Tokmen, please give credit where credit is due.

Hi Alexander

Please don't hesitate to update the patch accordingly.

I personally run on a Mac, and on MacOS X all shortcuts always start with CMD (Apple key); which is solved with the current version of Firefox.

I assume some more effort is needed for Linux and Windows; but I have little idea on creating the "useful" patch for it.

So, please; patch propositions are welcome.
this bug is now a decade old! happy birthday!!!
Should the flash app be able to respond to or remap ctrl-alt-del or alt+f4 or alt+tab?  If not, why not?  ctrl+t or ctrl+n is based on the same principle of escape...
Basicly, it should not, because it's standard system level hotkeys.
But there are different OSes with different hotkeyes, e.g.Ctrl-Alt-BS ...
The best solution is to allow user to select allowed (or denied) hotkeys manually, but maybe it's hard to implement.
Browser must respond to basic browser level hotkeys (ctrl+t, ctrl+n, ctrl+w, ctrl+l).
(Btw maybe it's good to map ctrl+e to restore last closed tab.)
And browser (not flash) in ideal must respond to common system level hotkeys normally.
Alexander Rødseth, your patch is good for Youtube flash and other simple flashes.
But there are flashes, which it can't fix.http://vkontakte.ru/video-7378435_157142315
And if switch between browser windows and other window by keyboard (Alt+Tab), I saw problems with focus too.
test
I see that this is a major discussion since there is no easy resolution of the problem in terms of global compatibility. However, I would kindly request the Mozilla Developers to implement an easy solution for people like me: In all my years of internet consume I have never ever used a single keyboard shortcut provided by a plugin. Now maybe I am an extreme exception since I never play flash games, rarely watch youtube and co, always open my PDFs externally because I dont like them to be stuck in the browser and so on. But still on a large amount of pages I cannot use any of my favourite shortcuts (with Flashblock providing only a minor relief). Thus a simple config option allowing me to disable all plugin-provided keyboard-hits would be a great relief for me and maybe for others, too. I know this is by far not a sophisticated solution as proposed above, but as radical as it may seem, it would make my internet experience much more comfortable.
The problem is this variant is not easier to implement.
This sucker is in for 10 years now. Congratulations.
to harald.dunkel@aixigo.de:

Man, it's very bad idea to annoy developers of free software =)
The bug really hard to fix.
Only Midori and Internet Explorer don't have this bug, but Midori is alpha, and IE is "IE". Opera try to fix it too, but opera's solution is too buggy.
Sorry, I didn't mean to annoy anybody. But since the File-->Close menu item has been streamlined away this bug has become even more painful.
>harald.dunkel@aixigo.de 2011-06-16 03:26:12 PDT
>
>Sorry, I didn't mean to annoy anybody. But since the File-->Close menu item has >been streamlined away this bug has become even more painful.

You can temporery use variants:
1) close tab by Middle Mouse Click
2) close browser by closing all it widows by x icon (Alt+F4 or other other stadard hotkey of your system)
3) click to Location Bar, then all hotkeys will be ungrabbed.
(In reply to comment #506)
> to harald.dunkel@aixigo.de:
> 
> Man, it's very bad idea to annoy developers of free software =)
> The bug really hard to fix.
> Only Midori and Internet Explorer don't have this bug, but Midori is alpha,
> and IE is "IE". Opera try to fix it too, but opera's solution is too buggy.

Yeah right... Because protecting the basic browser hotkeys (that no sane flash developer ever used) is just a mountain that cannot be climbed.
AFAIR this bug report is not restricted to flash. Does a similar problem exist with webm?
(In reply to comment #513)
> AFAIR this bug report is not restricted to flash. Does a similar problem
> exist with webm?

Webm has nothing to do with plugins. And html videos work like any other "normal" elements of the page.
Hmm, maybe just let ctrl+tab be over any other shortcut (browser could always listening for ctrl+tab -> even if focus is for plug-in)? It should allow us to jump to another site and release focus
I have a Dell Inspiron 15r and while flash apps aren't a big issue (clicking outside the app or in a different tab allows scrolling), adobe reader plugin takes scrolling functions, even when the tab reloaded while not focused. This problem exists in all versions, from 3.5 to 7.0a1
smacharia8@gmail.com, last I heard that problem was fixed in some of the recent updates to adobe reader. What version are you using?
I see the same issue with Acrobat Pro loading in a background tab (middle-clicked link) stealing focus from the active tab. I use Acrobat Professional 9.X on Windows 7 x64.
I have some idea, but I have not enough skills to realize it...
Let's create transparent gtk widget, which covers flash plugin's rectangle (above every plugin's widget).
This widget will handle every single event, which plugin handles before.
This widget will filtrate come keyboard binding, which browser needs.
Other events this widget will resend to plugin's widget and immidiately restore focus, if needed (maybe focus will not grabbed by flash at all in this case, but force restoring after every event will be better).
*will filtrate some
(In reply to comment #519)
> smacharia8@gmail.com, last I heard that problem was fixed in some of the
> recent updates to adobe reader. What version are you using?

I have Adobe Reader and Acrobat X Pro.

My problem is identical to Jerry's; Acrobat/Reader steals my touchpad's scrolling functions from my active tab, even when opened via middle click or ctrl+click.

The touchpad on my system uses Synaptics drivers, and I'm running Windows 7 Pro.
The stolen focus and scrolling problems are bug 273456.
In the meantime it would be nice if focus could return to FF when the user clicks on the toolbar/application surround. (If Flash has focus and is maximised, simply moving the mouse to an edge of the screen and clicking would be such an easy way to regain focus.)
PS At the moment focus can only be regained by clicking white space within the web page itself..
(In reply to graemew@gmail.com from comment #529)
> PS At the moment focus can only be regained by clicking white space within
> the web page itself..

For me clicking in the application chrome (the current tab on the tab bar, another tab, the URL bar, …) works too. If Flash is maximized, Esc will usually exit full screen, or else any mouse move brings up a Flash toolbar near the bottom, which includes a widget with four arrows pointing inwards, to exit full screen mode by clicking it.

Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110911 Firefox/9.0a1 SeaMonkey/2.6a1 ID:20110911003152
No, I mean maximesed, not full screen. I mean that the most convenient way of gaining focus, for me, would be to sweep the mouse upwards and clicking once at the top of the window. Not fiddling around finding whitespace or the address bar. I mean, if we can't manage a way to share focus as IE does for keys such as TAB, ALT+TAB etc at least this would make life a little easier (as if this is a real difficulty, I'm so spoiled..)
Is there a desktop browser that doesn't experience this bug at all?
Internet Explorer doesn't experience this bug at all
I think this bug will be fixed when 1 million bugs will be marked duplicate of it.
Will this bug EVER be repaired ?
Hey, as a workaround, please, give us keyboard addicted ones an über-meta combination to focus back to the browser. f.i., CTRL+META+<configurable>. And you'll also spare a lot of RSI wrist pain to poor mouse dependent ones ;-)

Cheers,

  ^s
I got so used to it that i forgot about it. I definitely think this should be fixed ASAP. It hurt user experience when using Firefox.
(In reply to dave shultz from comment #0)
> 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.
(In reply to Alexander Rødseth from comment #495)
> Josh Aas, which events should be let through, in order to not break a
> non-trivial number of existing plugin-based applications? It's a fairly
> minimal amount of key press events that are blocked in my Gtk2 patch (and as
> I understand, people want additional keys to go to Firefox, like Ctrl-F4 and
> Alt-D).

Josh,

Please kindly answer, or provide some information on which you base your comment #487 (especially "This patch denies plugins many events that they have always received" part), so that patch can be tweaked.

If you have some tests/test that you base this of, please share.
This bug shouldn't really be fixed in the browser but in the plugins themselves.  I need CTRL+W and other stuff be stolen from the window to the plugin so LogMeIn Remote Control can send them off into the computer I'm controlling without affecting the tab on the controlling computer itself.
The bug is that if the browser is playing a flash file, it's NON-RESPONSIVE to application shortcut keys, henry.  It's a bug that has caused many people grief when they go to play flash files on their own machine whether they made it themselves and are testing it or are watching flashes they obtained online pretty much.  So please READ THE BUG DESCRIPTION AND THE COMMENTS.

Anyway...

Back to my bug reporting self and as to how I can think of a solution...

Has anyone tried looking at the code that directs the commands between the browser and any plugin loaded?  Maybe there's something within those lines causing commands to be lost?  (Maybe it's sending them to the flash rather than parsing them first to see if the user is trying to execute a command?)

I know when I try to fullscreen during a flash file, I hit F11 and nothing happens AT ALL.  It's like the shortcut didn't even exist.
Adobe Flash Player and Adobe Reader make Firefox shortcut keys unresponsive on: 
Firefox 10.0.1 ESR, Firefox 10.0.1 and Firefox 11 Beta 2, even if the focus is set on the Bookmarks Toolbar, Add-ons Toolbar or Firefox button.

Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Is bug 725614 a DUPE of this bug?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #546)
> Is bug 725614 a DUPE of this bug?

No, although it's a substantially similar situation. See my comment over there.
Still reproducible on latest ESR: 
Mozilla/5.0 (Windows NT 6.1; rv:10.0.3) Gecko/20100101 Firefox/10.0.3
I'm going to get the workaround patch and see if this fixes the problem.  If it does, is there a way to nominate/vote the patch for the next release?
Nevermind, sorry for the double comment, but this bug seems to cause another problem which it will utilize 100% CPU.  Can someone streamline that fix?
(In reply to DK from comment #532)

> Is there a desktop browser that doesn't experience this bug at all?

Safari, OmniWeb and especially iCab are quite good at it.
Suggestion. Some shortcut keys should be freed from the application and interpreted by the browser. For example, CTRL+Tab and ALT+F4.
I'm having similar problems with Nightly, latest update. I update whenever I get the "update is available" popup. Ctrl-tab and ctrl-shift-tab appear to shift focus in a tab where flash-player is active. This was working just a few days ago but is now failing.
I can reproduce this on ESR
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.4) Gecko/20100101 Firefox/10.0.4 and WebGL

http://www.demonixis.net/lab/index.php?p=threejs-maze3d 
here is a maze game that if in focus the keyboard shortcuts are unavailable
Wow. Bugreport is from May 2001, Now it's May 2012, that's more than 10 years, and the bug is still there... No tabbing into and out of flash videos...
Yes, very soon it will be preserved just because it'll have great archaic and heritage value, worth not fixing it ever :). 

On the other hand, if HTML5 becomes really popular, it might replace Flash altogether, removing the need of fixing this bug - but I'm sure Adobe will do something to not let that happen so soon...
(In reply to Piyush Soni from comment #557)
> if HTML5 becomes really popular, it might replace Flash
> altogether, removing the need of fixing this bug - but I'm sure Adobe will
> do something to not let that happen so soon...

Adobe already started the process of pushing webmasters to stop using Flash. I couldn't find the link I wanted to put here as reference, but here's a related one explaining Adobe will no longer develop Flash for "Linux": http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html

Please read whiteboard before commenting about age.
(In reply to Piyush Soni from comment #557)
> On the other hand, if HTML5 becomes really popular, it might replace Flash
> altogether, removing the need of fixing this bug...

Whilst the focus of this bug is on Flash, due to it's current ubiquity, the bug affects all plugins.  Therefore, even if Flash is abandoned, as long as there are still plugins in general, this bug will still need fixing.

Also, it's worth mentioning that even if Flash were to be discontinued, there is still a huge wealth of Flash-based content out there (games and cartoons in particular) which won't simply disappear.  So even if ads and video-streaming move into HTML5, and even if no new Flash content is being generated, people will still be using Flash to access content for a long time to come.
[:SarcasticSmile:] Not to offend anyone, but at the speed this bugfix is progressing, it won't be fixed in 10 more years.

At that point, my guess is Firefox will be obsolete.
I wish I could say that what follows is sarcastic, but it isn't. As far as I am concerned, Firefox is already obsolete. Any project that has a serious bug like this that lasts for 11 years cannot be taken seriously. Combined with the recent trend to "rapid releases", better described as "constantly broken"; and the attempt to turn it into a visual clone of Chrome, I decided to just use Chrome instead.

I had forgotten that I was still subscribed to this bug -- something I'm about to remedy.
This is my understanding of the issue. After getting 'click to play' enabled builds of Firefox and when you click on a "ctp" content, Firefox loses focus just like how it did even before ctp came out(you can tell when the (tested in windows 8) layout/theme color fades when a window loses focus in ctp builds) which is the bottom line. Firefox loses focus in order to start the plugin, restored after clicked on the content with mouse. 
The hurdle is to merge the plugin content with the Firefox layout without both losing focus amirite? 

(In reply to Tim H. from comment #561)
> with the recent trend to "rapid releases", better described as "constantly
> broken"; and the attempt to turn it into a visual clone of Chrome, I decided
> to just use Chrome instead.

The memory improvements you might be seeing these days in the "rapid release" builds are because of the implementation speeds based off the rapid release schedules.Don't tell me you like slow browsers (many benchmarks even prove Firefox handles memory much better than chrome these days). There are changes to designs proposed for Firefox and are already being worked on. These designs are a big improvement to what you see now, more space to view content compared to earlier versions. Now, why all such hate on the new theme especially when both of us know its better than it ever was. Mozilla gets it that some people don't like the theme which is why new designs are on the table. Wait till it gets out, constant complaining about known matters don't help much unless you have a patch that can be reviewed on what you want. 

This is for everyone from here.
I don't understand the complaints. Firefox keeps getting faster and better with every iteration.

I have noticed that the problems extends to PDFs as well, rendered by Adobe plugin. Will see if pdf.js also has this problem. Clicking outside the video, for example in the white space around a youtube video, restores this functionality.
Firefox will be even greater if they cook up an easier way to prevent crashes and to save tabs.
Well except me, no one I know try to save tabs or sessions. I'm sure the Mozilla team has to focus limited resources on use cases beneficial to almost all users not just a few features here and there- same reason Opera seems to be abolishing some of its built in features. But thats why there is add-on support in the product. I recommend session manager.
And I dont know about the crashes, but even with 50+ tabs open firefox rarely crashes on me, maybe once a week.
This discussion is really far off of the topic of an actual fix for this bug. Take it to the newsgroups please. See comment 315 and comment 320.
(In reply to Felix Miata from comment #558)
> Please read whiteboard before commenting about age.

I don't think it is fair to expect everyone to know that they have to read the whiteboard before commenting here, especially when it is not flashing red in big font letters. :) It is just another field out of tens of them. So first work could be done in making that more noticeable if you really want that. 

Secondly, now when I've read the whiteboard and comment 403, I'm even more surprised that you could point me to that comment which says it is one of the highest priority bugs and it has a definite solution, *just that it could not be shipped with Firefox 4.0 as it was out of door*. It's been more than one year after that. I hope you realize that it's time to change the whiteboard !! :)
"Adding more comments here isn't necessary. It's a priority to fix, it's one of the top ten issues as far as the User Experience team is concerned, it just didn't have a clear solution for 4.0."

There wasn't clear solution then. There is no clear solution now.
Probably they are working on it - as it's visible on Aurora, and its sometimes working shortcuts.
Seriously, as has been voiced several times already, complaining about this bug and talking about the health of the Firefox project is not helpful and should not happen here.

Before posting anything, ask yourself:
 1. Do I understand this problem from a technical perspective?
 2. Am I helping to move towards a solution? 
 3. Am I venting my frustration? 

Then make a decision. We're at nearly 600 comments, and using this bug report to fix the actual bug is nigh impossible as it is. This bug will soon be closed if conversation doesn't becoming more focused on *fixing* the bug.

Mozilla is very open about their development process, but this kind of bug report makes it a real struggle.
(In reply to Mike Lissner from comment #569)
> Before posting anything, ask yourself:
>  1. Do I understand this problem from a technical perspective?
>  2. Am I helping to move towards a solution? 
>  3. Am I venting my frustration? 


3. I was venting my frustration. And I think that is critically important, as this *alone* decides the severity level of a bug. No, silent 'voting' is not enough. 

Of course, we could have a 'Vote up'/'Vote down' specifically for comments, so that more useless comments are pushed down.
(In reply to Mike Lissner from comment #569)
> Seriously, as has been voiced several times already, complaining about this
> bug and talking about the health of the Firefox project is not helpful and
> should not happen here.
> 
> Before posting anything, ask yourself:
>  1. Do I understand this problem from a technical perspective?
>  2. Am I helping to move towards a solution? 
>  3. Am I venting my frustration? 

The answers to these should be as follows: Yes, Yes, No.  If you can't answer the questions in that sequence, then you need to curtail your commenting.  I am backing up Mike in saying that these kinds of "Vent Frustration" comments need to be kept to a minimum and he did say himself that he will close this bug without it being resolved if nobody is willing to try to move toward a solution.

Now I may have a theory as to how the hotkeys are being misplaced.

1. plugin opens.
2. until plugin has focus, Firefox checks hotkeys.
3. when plugin has focus, something either messes up or does as it's supposed to and stops the checking of hotkeys in case the plugin needs them.
4. Hotkeys no longer work.
Seems using the pdf.js (PDF viewer) doesn't steal focus from the chrome- the shortcuts work despite the document being in focus.
Hope that helps somehow.
(In reply to Kshitij Chawla from comment #572)
> Seems using the pdf.js (PDF viewer) doesn't steal focus from the chrome- the
> shortcuts work despite the document being in focus.
> Hope that helps somehow.

That's because pdf.js is just that, Javascript. It is not a plug-in.
The way I see it, there are two major problems which are neither acknowledged nor being discussed:

• The prioritisation of bugs is severely out of kilter with the priorities that users expect. This may be because BugZilla provides no realistic means for users to express their priorities (e.g. ranked-choice voting). You can fix this by fixing BugZilla. Until you do, users will continue to attempt to express it via off-topic comments.

• Off-topic comments (such as this one) hamper your work. This is as much a problem with BugZilla as it is with the hundreds of commenters. You can fix this by fixing BugZilla (e.g. comment rating system). You’re attempting instead the much less realistic option of “fixing” the hundreds of commenters, including future ones, by posting *even more* off-topic comments.
10 years+...
Why not make it the default that 99% of all browser special keys (Ctrl+1-9, ...) are NOT passed to the plugin, unless the plugin is in a special list of plugins?
Or even better something like this:

plugin.pass_keystrokes_to_plugins         boolean default=true
plugin.keystroke_plugin_exclusion_list    string

If pass_keystrokes_to_plugins==true, then keystroke_plugin_exclusion_list is a list of plugins not to pass keys to.
If pass_keystrokes_to_plugins==false, then keystroke_plugin_exclusion_list is a list of plugins to pass keys to.

Would a clean patch implementing this be accepted into mainstream?

Oskar
That would require implementing an exception list for said plugins, and the additional coding that entails.  However, it could be simplified if it's kept local to the browser and is set via the user.

Or, we could just reroute the keys:
<psuedocode>
On keyboard.keypress
{
   key = plugin.keyboard_input
   If key == firefox.any_system_command then
   firefox.keyboard_input = key
}
This event would check every time a key was pressed/held down and would pass the plugin key input back to firefox through it's own internal keyboard input.
As long as Firefox fails to process the key (!) commands — like Ctrl L, Ctrl W — when the plugin has the focus, Firefox must not abandon the focus to the plugin as soon as Firefox loads the requested document. Currently, he does that, and the combination of both of these behaviours give awkward situations.
See bug 759089.
Knock! Knock!
Has anyone noted that Firefox 13 resolved these issues?

My findings are that Firefox 13 has resolved all the problems related to this forum post, and also it is tons quicker than earlier versions. Lastly, I also find that scrolling is MUCH smoother than the last couple of versions.

I reckon this thread could be closed?
Firefox 13 has not resolved this problem. Are you posting on the correct bug?
I just tested again and verified that this problem definitely still exists in the latest version of Firefox, so I'm guessing giepie may have inadvertently posted to the wrong bug report.
My problem was more specifically with Adobe Acrobat files open. This is where I first noted my problem seems to have been fixed. I have also tried with Youtube and scrolling works perfectly fine, even when the Youtube Video has focus (ie, after you clicked on pause and play etc)

If this helps at all, my machine is a Acer TravelMater 8572G with Synaptics touch pad. I make use of two-finger scrolling.
If it is working for you with YouTube, you might want to make sure it is STILL a flash video and not an html5 one, which they have been rolling out for quite some time.
Could you please also specify your OS and the versions of the plugins involved? Also, in case of YouTube, are you sure that the video uses flash and not html5?
Sure!

I'm using:
Windows 7 Pro x64 
Adobe Acrobat 10.1.3.23
Shockwave Flash 11.2.202.235
QuickTime Plug-in 7.7.1 7.7.1.0
Microsoft Windows Media Player Firefox Plugin 1.0.0.8
Java Deployment Toolkit 6.0.260.3 6.0.260.3

I am not sure about the Youtubes I viewed, I'll have to go check. I always assumed Youtube only used flash (yes I know, assumtion is the mother of all...)

Ok, I just tried a random Youtube vid (impractical jokers, AWESOME series), and scrolling stops working the moment it has focus.

This is really a bummer. I must have been lucky with a few html5 vids then.

At least there is some sort of progress, seeing that Acrobat is now working fine for me. This was the largest problem to me, since I sometimes have several PDF files open within Firefox.
Hi,

I have this problem CURRENTLY on the Nightly version of Firefox on my Fedora (Core) 16 x86_64 system.

I get this by navigating from tab to tab with ctrl-tab key. When I traverse my tabs, the tab with a vid playing stops obeying the ctrl-tab and appears to give focus to the vid that's running. I can no longer traverse the tabs at this point.

How do you tell just what is showing the video that's running?

George...
I can assure you that a fix to this problem is not just going to slip into a release of Firefox, or somehow be caused by some other unrelated bug being fixed. It's a fundamental design decision with how NPAPI works. Fixing this bug will involve changing that directly.

Please don't comment on this bug trying to figure out whether it has magically been fixed - it hasn't. Also please read the whole thread before commenting, difficult as that may be.

In fact, there is probably very little anyone can say on this bug report that will actually be useful, unless they are a Mozilla employee. That includes this comment (apologies in advance for posting it).
Hi Flamingspinach

I;ve been keeping up to date with this thread since I joined. As I said, my biggest problem was with PDF files and the fact that I couldn't scroll when a PDF was open (the PDF document would scroll up and down when I'm actually scrolling a on a different tab).

I was really surprised when this was fixed with the latest release.

My second test was Youtube, and to my amazement, I was able to scroll the page, even when the vid had focus. However, I wasn't aware there was html5 and flash videos and that one of them would work differently.

I can sort of live with the current problems (although the shift-tab function would still be a pain, even though I learned to deal with it).

Sorry for posting something before thorroughly testing every single aspect. I don't usually post when I don't have all the facts. 

Thanks for everyone's help!

G
giepie, notice that PDF scrolling in another tab is a completely different issue. See bug 273456 and bug 626813. The last one is even marked as fixed in FF13 so something could really change for you.
Hmmm, now how did I end up in this thread?

Ace, you're the man!

Sorry for sparking everyone's emotions, I'm just very happy that a portion of my FF problems have been resolved. I seriously considered moving to Chrome. Luckilly FF13 has become usable and quick again.

Thanks for everyone's input!
Assignee: joshmoz → nobody
Warning sign! Please fix this! It's a bug labelled as Major, that has been open for more than ten (!) years! And it's a very irritating bug. I should be able to ctrl-t any time to open a new tab or ctrl-l to go to the location bar. It's really bad that a bug like this takes ten years to fix. 
A major bug that has't been fixed for ten years! I think it is a proof that mozilla has been focussing less and less on the end-user, sorry to say.  I actually switched to Chrome because of it. Usability first!
DON'T HAVE PATCH, PLEASE DON'T WRITE HERE.
THANK YOU!

PS. it's already partially fixed.
> PS. it's already partially fixed.

This is a lie. No fix has been made to actual Firefox. A couple of half-baked “workaround” patches posted on this bug doesn’t fix anything for anyone.
In reply to comment #591 and comment #593: Please read:
1) comment #403 as mentioned in the Whiteboard;
2) https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
and then shut up unless you have something to contribute which will make the bug move forward.
- Back-seat driving doesn't help. It may even make developers *less* willing to try their hand at fixing the bug.
- If you think you know how to fix the problem, then feel free to ASSIGN the bug to yourself, attach the proposed patch as an attachment, and have it reviewed by some appropriate reviewer. In this case, https://wiki.mozilla.org/Modules/Core#Plugins might be of help to find who to ask for a review.
In reply to Tony Mechelynck [:tonymec] from comment #594

Blindly pointing to Comment #403 doesn't help, because it is outdated, and more importantly, *misleading*. Please read that again yourself. Anyway we never saw Alex Limi after comment #406 here who was passionate for fixing this. At least create a new comment to point people to. 
I propose the following changes to comment #403

1). Change "it just didn't have" to "it still doesn't have"
2). Change Firefox "4.0" --> Firefox 13.0 (or 14, 15)
3). Remove the junk that follows. 

I hope my post contributed something.
(In reply to Piyush Soni from comment #595)
> In reply to Tony Mechelynck [:tonymec] from comment #594
> 
> Blindly pointing to Comment #403 doesn't help, because it is outdated, and
> more importantly, *misleading*. [...]

Then the Whiteboard shouldn't point to it, but maybe to your comment #595, or maybe to no comment at all, or maybe directly to the netiquette page, or maybe to an updated (but full) version of "what to do before posting" which would not amend but replace comment #403.

I would have changed it myself if I had known what to change it to.
****IMPORTANT (NEW) REGRESSION, NOT RUN OF THE MILL POST **** !!!!!!

Alright. This problem has gone to another level now. Over the years I had built it in my muscle memory to click once on empty page any time I click in the YouTube player even by mistake - so that my keys are not locked. 

But now, with the latest update in Firefox (13.0.1) / Flash/ or YouTube, I can't even do that! So things have become even more frustrating, and fixing this even more important. Even scrolling doesn't work. 

NOTE : It does NOT happen in Chrome now, so it's all Firefox. At least fix this one urgently.


Also, having noted that the Whiteboard points to misleading post, I still want to know why is no one working on this. If you lack resources, stop working on useless enhancements please. Why are you not prioritizing the bugs, it is out of my understanding. None of the reasons you gave can justify waiting for more than 10 years for fixing a critical bug.
(Also, I already tested that it happens on multiple machines, even with a clean profile)
The recent issue is actually a regression in Flash 11.3. Would be good to see Firefox mitigate this, but in the meantime, you can disable Flash's protected mode and the clicking will work again.
Piyush Soni: Different problem and unrelated to this report.
Plus you missed to read comment 403 first, as told before commenting.
I'm not missing reading comment 403, you're missing reading comment 595(and 596). 

I beg to differ from your statement that this is an 'unrelated problem'. It might be from a developer's perspective, but not from a user's perspective. It very much adds to the same problem of keys not working once you click on the flash object. The new addition being even clicking outside doesn't leave the keyboard, making the bug worse. 

I repeat, Chrome doesn't have this problem by default even with flash 11.3 (protected mode enabled or disabled).
Giving up on this bug. I'm switching to a different browser.
Can we please close this bug and open new one?
it's starting to be impossible to find ANYTHING here...
(In reply to HaWaN from comment #603)
> Can we please close this bug and open new one?
> it's starting to be impossible to find ANYTHING here...

Why? People at least come to rant here on the eternal bug instead of several other bugs.
Implement a simple vote up/vote down to comments like every other website does these days. That will drive useless comments down and solve that problem at least.
It's not a Flash-bug, because it also happens in Adobe Reader. It's not a Flash-bug because it doesn't happen in Chrome. 

About 'Back-seat driving': I am not able to fix it, because I'm not that good at programming. If this back-seat behavior of me makes developers less willing to fix bugs, I can understand that with small OSS project in his (her?) free-time. But this is Mozilla. They are paying developers to fix serious bugs. I find it interesting that bugs like this aren't fixed by a multi-million dollar franchise, which Mozilla has become.  I'm sorry, but it's bad. I have been a fan of Firefox since Phoenix 0.1, but I am writing this post in Chrome.
(In reply to Wouter van Wijk from comment #606)
> I have been a fan of Firefox since Phoenix 0.1, but I am writing
> this post in Chrome.

Don't say things like that. It makes Mozilla think that they need to imitate Chrome's more annoying features, like hiding the protocol in the URL bar, instead of imitating the parts like not having this bug.
(In reply to Wouter van Wijk from comment #606)
> It's not a Flash-bug, because it also happens in Adobe Reader. It's not a
> Flash-bug because it doesn't happen in Chrome. 
> 
> About 'Back-seat driving': I am not able to fix it, because I'm not that
> good at programming. If this back-seat behavior of me makes developers less
> willing to fix bugs, I can understand that with small OSS project in his
> (her?) free-time. But this is Mozilla. They are paying developers to fix
> serious bugs. I find it interesting that bugs like this aren't fixed by a
> multi-million dollar franchise, which Mozilla has become.  I'm sorry, but
> it's bad. I have been a fan of Firefox since Phoenix 0.1, but I am writing
> this post in Chrome.

I'd use Chrome if it had a decent customizable GUI with real themes. And comparable addon capabilities. Someone wanna fork it to implement the good stuff from firefox? :)
I'm bit of a noob when it comes to all this. But one thing I've noted. The bug doesn't exists on full screen. 

Let me explain. I have those multimedia type keyboard with volume buttons. What happens is, when flash player is in focus, even those volume up/down keys don't work. But when the flash player is in full screen mode, they (vol keys) work perfectly fine.

Hope that helps.
I haven't upgraded firefox for some time. Yesterday i decided to upgrade from version 5.0 to latest version 13.0.1. Most of my plugins stopped working like the Kaspersky virtual keyboard etc. But one thing it's anoying me most it's my keyboard volume buttons stopped working when watching youtube videos. I've uninstalled firefox 13.0.1 installed firefox 5.0 again, voila. All my plugins working great and keyboard shortcuts working again. I guarantee, this problem doesn't exist in firefox 5
I guarantee, this problem (meaning the problem which this bug #78414 is about) has existed for eleven years, since before Firefox was even called Firefox. Please understand the problem before telling us whether it exists or not.
(In reply to flamingspinach from comment #611)
> I guarantee, this problem (meaning the problem which this bug #78414 is
> about) has existed for eleven years, since before Firefox was even called
> Firefox. Please understand the problem before telling us whether it exists
> or not.

What you mean is that mozilla hasn't made anything about it meanwhile ?
Have you tried yourself version 5 before commenting ?
If not, i feel sorry for your poor comment.
(In reply to Rubino from comment #612)
> 
> What you mean is that mozilla hasn't made anything about it meanwhile ?
> Have you tried yourself version 5 before commenting ?
> If not, i feel sorry for your poor comment.

@Rubino,
As flamingspinach said, you need to understand the real problem this bug is about. Yes, it was there in Firefox 5.0, and earlier.
This bug brings risk of physical harm to those of us who for medical reasons need to use the mouse as little as possible. Please don't let Firefox be a browser that unnecessarily excludes users with hand/arm health issues.

Alex Limi's post #403 "rules" for commenting are not convincing, given that Limi claimed to "care passionately" about fixing this bug neither Limi nor a fix is to be found here one and a half year later. Someone with a twitter account should ask http://twitter.com/limi about this bug.

To see a major bug go unsolved is one thing. But to not see someone from FF taking responsibility for it after so long time is really frustrating. There must be someone developing FF who knows enough about the nature of the problem to spend a little time making a modest blog post that describe (1) why only Firefox but not Chrome or IE has this problem. (2) what the prospects for fixing the problem are and (3) if there are any non-Firefox based workarounds. For example are there any other windows tools that can override Firefox control to a hotkey so that we can script the hotkey to do what we want and pass it on to Firefox only under certain circumstances?
On Firefox v14.0.1 mouse scroll will stop working on a new tab with an embedded pdf.

To recreate:
1. go to http://www.pdfobject.com/markup/examples/sized-element.html
2. resize firefox so the vertical scrollbar shows
3. try scrolling the page but outside the embedded pdf.

If mouse scroll does not work go another tab -> scroll the page -> return to the tab with the embedded pdf -- and now it works.

4. refesh the page -- now it does not work again.

I'm making a site with plenty of pdf's and I'm worried that users could be turned away due to this issue.  I tried both javascript and html versions to embed but getting same results on Firefox only.

OS: Win7
Hardware: Vaio VGN-NS11M
Firefox addons: disabled one by one while testing
(In reply to Hiro from comment #615)
> embed but getting same results on Firefox only.

The other browsers I use:

- Mozilla SeaMonkey 2.11
- IE 9
- Safari 9
- Chrome 9
- Opera 12

I'm surprised pdf works fine on Seamonkey.
(In reply to Hiro from comment #615)

On my good old Firefox 3.6.23, this works. Regression?
Adobe has an entry for this: https://bugbase.adobe.com/index.cfm?event=bug&id=2944796

They have asked people to vote on it and describe how it impacts everyone. Please do express your frustrations over there, since they are specifically after this. It appears this helps them prioritise work on the issue.
(In reply to Roman from comment #618)
> Adobe has an entry for this:
> https://bugbase.adobe.com/index.cfm?event=bug&id=2944796
> 
> They have asked people to vote on it and describe how it impacts everyone.
> Please do express your frustrations over there, since they are specifically
> after this. It appears this helps them prioritise work on the issue.

Thanks for the link. Do note however that this bug is not only about Flash. It really does need to be solved on Firefox's end.
Depends on: 380637
As annoying as it is that Flash and other plug-ins consume all keyboard input once they receive focus, I thought this was supposed to be intentional so that the plug-in could do whatever it wanted with keyboard input without the user accidentally screwing up the browser (such as unwanted scrolling, tab-closing, tab-changing, menu commands, etc.).  This is particularly important with interactive plug-ins such as games.

The simple workaround is to click somewhere outside of the plug-in before trying to use any of the browser's keyboard commands.
...and a simple technique for a malicious coder would be to take up the entire window/screen so that you can't click outside it.

I'm not sure if this is a further advancement of this problem, but I've noticed that ctrl-w and ctrl-F4 don't work when a plugin has focus in Windows.  This means you are trapped unless you can find a place to click, or you close FF entirely.

At the very least, there need to be some keys/shortcuts that are off limits to all plugins.  Shortcuts to close the tab and window should be at the top of that list.

Currently some plugins, such as Acrobat Reader, will exit the plugin when ctrl-F4 is used, but one still needs to click outside the tab or window to get keyboard control back.
*** IMPORTANT UPDATE***

It seems Google Chrome has now COMPLETELY fixed this issue (Version 21.0.1180.83). So open any flash video and you can press all your favorite key combinations ! (Like Ctrl + T, Ctrl + Tab, Ctrl + F4 / Ctrl + W etc. ). This problem has historically affected Chrome as well, and it was the only respite Firefox had. 

Firefox STILL cannot do that.
(In reply to bugzilla from comment #621)

> I'm not sure if this is a further advancement of this problem, but I've
> noticed that ctrl-w and ctrl-F4 don't work when a plugin has focus in
> Windows.  This means you are trapped unless you can find a place to click,
> or you close FF entirely.

In this case, it would make sense to escape from the trap by pressing... Escape.

> At the very least, there need to be some keys/shortcuts that are off limits
> to all plugins.  Shortcuts to close the tab and window should be at the top
> of that list.

And Ctrl L / Apple L too.

(In reply to Piyush Soni from comment #622)

> This problem has historically affected Chrome as well, and it was the only
> respite Firefox had. 

When another browser has the same problem as Firefox, this is not a good thing for Firefox. We are not at war.
(In reply to Nicolas Barbulesco from comment #623)
> We are not at war.
Aah. Yes, I was wrong. "Chrome has that too" was not the only respite FF had. "We're not at war with any other browser" is the one too. 

There is no war, but please note that if there is no feeling of competition, the browser will sink very soon. Most of my friends/relatives have moved to Chrome. For those of us who are still here just for the love of it, the reasons of sticking to it are reducing day by day, and that should be a matter of concern for Mozilla. 


Is there no one who can look at Chrome's source (and diff) and check how are they doing it now, especially since they started by picking a lot of things from FF and have had the same problem before?
As far as I can tell from several years of following this bug, the problem is that The Powers That Be at MoCo have failed to come to a decision as to what, exactly, the "right" behaviour is.

It's not at all clear that https://wiki.mozilla.org/Plugins:AdvancedKeyHandling , linked in comment 269, is still the current plan, and it's VERY clear that such a plan does _absolutely nothing_ to address existing versions of plug-ins. I do not believe -- and most of the saner commenters here seem to agree -- that a solution requiring third-party vendors to release new versions of their plug-ins is a viable one. The fix needs to be made in Gecko itself. The problem is convincing Firefox drivers that this "advanced key handling" spec is a non-starter.
Is there agreement among users as to what, exactly, the "right" behavior is?  Does bugzilla include a polling mechanism to ask?

It seems to me that the right behavior would be to have the browser respond to any keys it's configured to respond to, and pass any other keys to whatever page element has focus.  If plugins rely on keys the browser uses, the user should have the option of changing the browsers key bindings (except in safe mode).
My understanding of the problem (and I'm sure someone will correct me if I'm wrong) is that currently Firefox loads the plugin in a separate process and therefore has *no control* over how it handles keyboard events.

In other words, when a plugin has the focus, the chain of events is as follows:

 KEYPRESS -> OS -> PLUGIN

and not

 KEYPRESS -> OS -> FIREFOX -> PLUGIN

Therefore to fix this, the way plugins work needs to be re-engineered so that Firefox sits in the chain.  From my reading, this is the hard bit that is stopping this bug being fixed.  Once that has been resolved, it will be trivial for Firefox to filter which keys get passed to the plugin, and we can have a nice bit of bike-shedding to decide on the details.

As far as I can see (and again, I may be wrong) the Advanced Key Handling document is an attempt to get plugin vendors to respect certain key combinations as 'browser reserved' and therefore to ignore them, passing them back to Firefox, which would result in the following chain:

 KEYPRESS -> OS -> PLUGIN -> FIREFOX

However, I agree with previous comments that this is a non-starter.
(In reply to Mark Clements from comment #627)
> My understanding of the problem (and I'm sure someone will correct me if I'm
> wrong) is that currently Firefox loads the plugin in a separate process and
> therefore has *no control* over how it handles keyboard events.
> 
> In other words, when a plugin has the focus, the chain of events is as
> follows:
> 
>  KEYPRESS -> OS -> PLUGIN
> 
> and not
> 
>  KEYPRESS -> OS -> FIREFOX -> PLUGIN
> 
> Therefore to fix this, the way plugins work needs to be re-engineered so
> that Firefox sits in the chain.  From my reading, this is the hard bit that
> is stopping this bug being fixed.  Once that has been resolved, it will be
> trivial for Firefox to filter which keys get passed to the plugin, and we
> can have a nice bit of bike-shedding to decide on the details.
> 
> As far as I can see (and again, I may be wrong) the Advanced Key Handling
> document is an attempt to get plugin vendors to respect certain key
> combinations as 'browser reserved' and therefore to ignore them, passing
> them back to Firefox, which would result in the following chain:
> 
>  KEYPRESS -> OS -> PLUGIN -> FIREFOX
> 
> However, I agree with previous comments that this is a non-starter.

I doubt that the plugin container is an issue. It always worked like this. Far before the plugin container. 
The simple workaround they did in (preventing some keyboard shortcuts from being stolen by the plugins) chrome was recommended here several times. It also would have worked swell all these years, until a more elegant solution is possible. (If ever)
Also I didn't see any flash/java stuff that had a crazy enough developer to use shortcuts that the browsers use for the necessary events. (tab switching/closing, jump to urlbar, etc...)
Couldn't you insert Firefox invisibly between the keyboard and the plugin using an invisible window? Place an invisible window over the plugin. All user interaction would go to that window, which would then filter out any hotkeys, and pass the rest onto the plugin.

KEYPRESS -> OS -> FIREFOX's invisible window -> PLUGIN
Mozilla took different approach to Chrome - Chrome decided to take back keyboard, FF doesn't want to harm Flash plug-ins that might be using it. That is also why Roth's patch was rejected.

When Flash adopts the NPAPI proposal and makes necessary changes, so will Mozilla. No sooner will this be fixed than that, because otherwise it's hard to test.
I recommend closing this / marking as "won't fix" with appropriate comment "waiting for Adobe".

If someone has information why the approach "not to take back keyboard unless Flash allows us to" was chosen, please share. I'd say it's wrong approach, but my perspective is personal, and perhaps there are facts speaking in favour for plug-ins.

PS. A bit of irony: under the window I'm writing this in, there's "Status: NEW". :-)
I was not aware that this was idealogical issue.  I thought it was purely technical!

If that is the case then it seems like the idealogical battle has been already lost, as Firefox is now the only browser that contains this broken UI.

I can guarantee that if we are waiting for all plugin makers (and remember, this isn't just about Flash) to update their plugins to support a spec. that applies to only one browser, well, it just ain't gonna happen!
I just wanted to say that I waited for this for some time, and it wasn't fixed. There was another bug today "Your connection has been reset". Seeing how mozilla manages bug reports, I truthfully didn't have the time to look for a work-around to another problem so now I've passed to Chrome.

BTW - for those of you who "still" have the problem where a plugin doesn't respond to ALT+F4 - I've used a macro command in windows to execute: taskkill.exe /IM firefox.exe /F
So I just pressed my key and firefox would close...  
(I have a keyboard with additional assignable macro keys)

If you happen to have a keyboard or a mouse with macro keys, you're in luck :)

Have fun guys! 
(I didn't even know there was ad block plus for Chrome - silly me :P )
Depends on: 788718
So this means holding back a better user-experience only because Adobe and other plugin-writers are lazy? Or because there are a couple of old flash-apps which 'might' use keyboard-shortcuts they shouldn't have used at all? Now that's for a strange, user-unfriendly decision. 
Take a look at the discussion, the number of votes on this bug. Marking this as WONTFIX equals WEDONTCAREABOUTUSERS imhoe. If this is the state Mozilla is in, it's a sad day for me.

(In reply to LAFK from comment #630)
> Mozilla took different approach to Chrome - Chrome decided to take back
> keyboard, FF doesn't want to harm Flash plug-ins that might be using it.
> That is also why Roth's patch was rejected.
> 
> When Flash adopts the NPAPI proposal and makes necessary changes, so will
> Mozilla. No sooner will this be fixed than that, because otherwise it's hard
> to test.
> I recommend closing this / marking as "won't fix" with appropriate comment
> "waiting for Adobe".
> 
> If someone has information why the approach "not to take back keyboard
> unless Flash allows us to" was chosen, please share. I'd say it's wrong
> approach, but my perspective is personal, and perhaps there are facts
> speaking in favour for plug-ins.
> 
> PS. A bit of irony: under the window I'm writing this in, there's "Status:
> NEW". :-)
(In reply to LAFK from comment #630)
> Mozilla took different approach to Chrome - Chrome decided to take back
> keyboard, FF doesn't want to harm Flash plug-ins that might be using it.
> That is also why Roth's patch was rejected.
> 
> When Flash adopts the NPAPI proposal and makes necessary changes, so will
> Mozilla. No sooner will this be fixed than that, because otherwise it's hard
> to test.
> I recommend closing this / marking as "won't fix" with appropriate comment
> "waiting for Adobe".

Isnt firefox about user choice?  Please excuse my technical ignorance but why can't there be a about:config pref that allows users to decide if they want plugins or the browser to get hotkeys first?

Seems that a great number of people here want this.  If the option is there then there would be no reason to complain! Even if the pref was the default option, the 0.00001% of firefox users that have their flash game broken can set it back no problems.  Everyone wins.

I would argue that a change like this affects less people negatively then E4X depredation for addons.  Yet, the call was made that the benefits outweighed the negatives.  I believe mozilla can do the right thing again.
Stop pleading your case in this bug. They used to say Mozilla was great because open source meant more responsiveness to what users want, then they abandoned that and moved on to "submit a patch", and then they started rejecting patches they didn't like. It should be very clear by now that Mozilla is not about fixing bugs that users want fixed, and they even actively resist patches for bugs users want fixed. This isn't the first bug where this is the case, and it won't be the last. Pleading in here is not going to change the egos involved. Just use Firefox or don't. Their market share will tell them how they're doing.
Few thoughts:

1) I'm quite certain Mozilla had reasons to wait for Adobe/Flash. I'd like to know whether they still stand. Perhaps they don't. 

2) I recommended WON'T FIX to Mozilla to actually clear up bug status. It took me a while (and some effort) to actually learn why this bug is NOT being worked upon and what has been done. I'm not tied to Mozilla AT ALL. This means it's my own personal recommendation for Mozilla team IF THEY DECIDE TO STICK WITH WAITING FOR FLASH, which I - again, personally - think is wrong course of action. 

Still, it's better then current situation, because every person coming here is bound to misunderstand (pointer to comment 403 doesn't help either).

3) Switching to Chrome and about Open Source (OS) - and plug-ins.

Chrome is actually quite good browser, though proprietary. Chromium is also good, and it's free (OS, non-proprietary). If you find them to your liking, good for you - and I don't write in a "I don't give a damn" way, it's actually true.

OS is open, but it's not free for whoever makes it. And they make mistakes as everybody else. Fixing takes time and effort, these aren't free - and sometimes it's not easy (shouldn't take 12 years, sure, I don't claim otherwise, I think something else is at hand here). 

It's good to be passionate about web-browser, but honestly - and I don't mean to preach - I don't think announcing how Chrome is better and FF sucks because of this bug will (don't lynch me yet) speed up the fix coming.

Not trying to defend anyone here, just showing another view of the situation, which might be broader in some aspects. I am an avid fan of mouseless navigation (avid Vimperator and Pentadactyl user) and this bug has been a pain for such a long time now. I totally understand, how frustrating it is and am far from condemning anyone for being irritated at n-th time losing ability to use this-or-that keystroke.

I just think that we may be missing the info on the other side - the plug-in users. They don't come here (obviously, why should they) since they like the way it is. But perhaps it is us, who are in minority. I don't know, but it may be so.


4) Most important. What can help?

So, again, if you guys have the info on plug-in usage, some figures about it, or the knowledge about the reasons Mozilla decided to wait for Flash, please share.
PSA: Every time you post a comment on this bug, you are spamming 375 email addresses. I don't know about you people, but I CC'd myself to this bug so that I could receive updates about what Mozilla developers are doing about it. I did NOT CC myself to this bug so that I could hear people complain about it constantly. I assume the majority of people CC'd to the bug had similar reasoning when adding their email address.

So please do not comment unless you are working at Mozilla, or are a user *providing information about the issue*. This is basic netiquette for every bug tracker ever. Considering that this issue is extremely well understood by Mozilla (though apparently not by most of the people commenting here), there should be no need for users to provide more information about the issue. So in short, STOP COMMENTING UNLESS YOU WORK AT MOZILLA. Thank you.
WHERE THIS BUG STANDS AS OF TODAY

There is a technical side to this issue: Firefox is technically UNABLE TO FILTER THE KEYS: confirmed in comment #3, comment #27, comment #181, comment #185, comment #627 (an explanation rather than a confirmation). The hundreds of comments asking Firefox to "just" filter some keys (often going to a lot of specifics) can only be useful once Firefox can intercept plugin keys - which it can't, see bug 788718.

Mozilla has always wanted to fix this bug by changing the plugin API to allow plugins to send back "unused" keys. This is confirmed in comment #188, comment #315, comment #337. Last time this has been confirmed is end of 2009. There have been a few specific proposals: comment #236, comment #269. But, possibly due to the sheer scale of this work, it has not been completed, and seems more unlikely than ever before.

In comment #487, a patch was proposed by Josh Aas from Mozilla which filters what events plugins see, thus departing from the "let's fix the plugin API" approach. The patch was Linux only. This appears to confirm that at least some people at Mozilla are OK with the "filter the keys" approach. There are other linux-only work-arounds: comment #260, comment #385.

There have been some attempts at fixing the bug by providing a way to unfocus the plugin, sidestepping Firefox's inability to filter keys before the plugin sees them: comment #303, comment #308 and my own comment #446 (in which I failed to actually figure out a way to unfocus the plugin - the fact that the plugin captures all keys was not a problem because I used an OS-wide keyboard hook).

Mozilla is asking for patches, but it's been a while since comment #337 and it's no longer entirely clear whether a patch filtering the keys would still be rejected outright. A comment in bug 788718 from someone at Mozilla would clear up this uncertainty.

There is a bounty standing at $164 as of today on this bug: comment #334.


P.S. I shall be bold now and update the whiteboard to point to this comment. The point of this post is to compensate for Bugzilla's lack of a comment voting feature, making the above comments get lost in the noise, and since comment 403 has been repeatedly called "outdated".
Whiteboard: [PL2:NA][READ COMMENT 403 BEFORE COMMENTING][wanted2.1?] → [PL2:NA][READ COMMENT 638 BEFORE COMMENTING][wanted2.1?]
Hvis is where I un-cc. This is spamming my mail, and not a damn thing is beeing done. Firefox has grown slow and unresponsive, and I've gone to Chrome too. Byebye.
Hvis is where I un-cc. This is spamming my mail, and not a damn thing is beeing done. Firefox has grown slow and unresponsive, and I've gone to Chrome too. Byebye.
But thanks indeed for spamming the bug.
> I did NOT CC myself to this bug so that I could hear people complain about
> it constantly.
Actually I think I’m rather enjoying it :) I love Firefox, no other browser has such an entertaining crowd of frustrated users bashing it in a woefully inadequate bugtracker :)
Roman, comment #385 is not an "other linux-only work-around" compared to comment #487, but the very same.
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

If enabling the context menu on a flash content, several mouse click are needed to dismiss it. While the context menu is enabled the focus is completely lost and Firefox does not respond to any command.

Please let me know if I should open a new bug for this.
(In reply to Sduibek from comment #532)
> Is there a desktop browser that doesn't experience this bug at all?

Midori Browser
(In reply to LAFK from comment #540)
> (In reply to Alexander Rødseth from comment #495)
> > Josh Aas, which events should be let through, in order to not break a
> > non-trivial number of existing plugin-based applications? It's a fairly
> > minimal amount of key press events that are blocked in my Gtk2 patch (and as
> > I understand, people want additional keys to go to Firefox, like Ctrl-F4 and
> > Alt-D).
> 
> Josh,
> 
> Please kindly answer, or provide some information on which you base your
> comment #487 (especially "This patch denies plugins many events that they
> have always received" part), so that patch can be tweaked.
> 
> If you have some tests/test that you base this of, please share.

This patch do nothing with flash on many sites, but works on youtube. I tested it already.
Priority: -- → P3
This ticket was just set to priority P3. According to https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation for enhancements. Does that mean that this issue is considered an enhancement request rather than a bug report?
(In reply to flamingspinach from comment #650)
> This ticket was just set to priority P3. According to
> https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation
> for enhancements. Does that mean that this issue is considered an
> enhancement request rather than a bug report?

https://bugzilla.mozilla.org/page.cgi?id=fields.html#priority seems more up to date.

Enhancement requests are characterized by having their Severity set to "enhancement". This one is currently set to "major" instead, which places it only one step lower than a "critical" (i.e. crash, hang or dataloss) bug.
I'm restricting further comments on this bug because it's the issues are well understood (see comment 638), and further comments just spam the 386 users CC'd to this bug. The newsgroups are more suited to general discussion, and developers can update this bug as needed when new information becomes available.

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
Restrict Comments: true
This proposal is a sensible workaround (as a "complete" solution would
require the collaboration of every single plugin developer, which
doesn't seem feasible) for Windows. Is my understanding that OSX is
not affected, and a solution already exists for GNU/Linux, please
correct me if I'm wrong.

I've implemented two different strategies, one for plugins running in
its own window, and the other for the winless ones. The first one
installs a keyboard hook, which looks for well known keystrokes, and
passes the focus to the main window when one is found. The second
passes all key events to both the plugin and the DOM, except for the
ones which generates movement events (arrow keys, space,
pageup/pagedown...).

This patch is intended as a Proof-of-Concept, it needs betters
comments, an approved list of keystrokes to watch, and (probably) the
ability to be enabled/disabled via "about:config". But I wanted to
obtain early feedback from the devs prior to investing more work on
it.
Comment on attachment 827318 [details] [diff] [review]
PoC patch for both winless and windowed plugins. (Windows)

See comment #656.
Attachment #827318 - Flags: feedback?(benjamin)
Whiteboard: [PL2:NA][READ COMMENT 638 BEFORE COMMENTING][wanted2.1?] → [PL2:NA][READ COMMENT 638 BEFORE COMMENTING]
"The second passes all key events to both the plugin and the DOM, except for the ones which generates movement events (arrow keys, space, pageup/pagedown...)." What does this mean precisely? In Windowless mode, plugins are supposed to return true/false whether they handled any particular keystroke, and we should only propagate the keystroke if the plugin didn't handle it. This works on Mac, IIRC: does it not work on Windows (at least for the popular plugins)? We can't have arrow keys that move the page around and also do things within the plugin like text navigation or gaming commands.

Are control-t/w/r localized? I suspect they are, and so we can't just hardcode the English letters, but really need the application frontend to tell the plugin which keystrokes are "special". Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is this primarily for Flash?

jmathies will be the eventual reviewer for this, but I think we should probably break it apart into the windowless and windowed-mode patches, which are pretty different.
Attachment #827318 - Flags: feedback?(benjamin)
Sergio, will you be able to address comment 659?
Flags: needinfo?(mozilla)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #659)
> "The second passes all key events to both the plugin and the DOM, except for
> the ones which generates movement events (arrow keys, space,
> pageup/pagedown...)." What does this mean precisely? In Windowless mode,
> plugins are supposed to return true/false whether they handled any
> particular keystroke, and we should only propagate the keystroke if the
> plugin didn't handle it. This works on Mac, IIRC: does it not work on
> Windows (at least for the popular plugins)? We can't have arrow keys that
> move the page around and also do things within the plugin like text
> navigation or gaming commands.

This patch, instead of killing all events going to the plugin, only kills the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT, SPACE...). I don't know about Mac, but on Windows, Java applets (or, at least, the ones I've tested) doesn't properly return the event feedback to the browser.

> Are control-t/w/r localized? I suspect they are, and so we can't just
> hardcode the English letters, but really need the application frontend to
> tell the plugin which keystrokes are "special".

Yes, there should be a way for enabling/disabling this functionality, and for configuring which keystrokes should be processed/ignored. I'm not familiar with the "mozilla way" for doing this kind of things, but if you could point me to dome docs or a piece of code with similar functionality, I can give it a try.

> Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is
> this primarily for Flash?

Yes, it should. In fact, even if it appears to be embedded, Flash is just a bunch of windows which share the Device Context with the browser. The problem I've noticed with some plugins, is that with some of them the instance owner doesn't notice when they request focus, so the hook doesn't get installed. But this just means that we should look for another place for installing it.

> jmathies will be the eventual reviewer for this, but I think we should
> probably break it apart into the windowless and windowed-mode patches, which
> are pretty different.

I'm OK with this.
Flags: needinfo?(mozilla)
> This patch, instead of killing all events going to the plugin, only kills
> the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT,
> SPACE...). I don't know about Mac, but on Windows, Java applets (or, at
> least, the ones I've tested) doesn't properly return the event feedback to
> the browser.

That doesn't answer my question. Does the patch kill the events *before* they get to the plugin, or *after*? We must certainly send plugins the arrow keys and space.

> > Are control-t/w/r localized? I suspect they are, and so we can't just
> > hardcode the English letters, but really need the application frontend to
> > tell the plugin which keystrokes are "special".
> 
> Yes, there should be a way for enabling/disabling this functionality,

The Firefox frontend should be in charge of this: perhaps the best option is to have an API that the Firefox frontend can call "set browser shortcut keys" and then the Firefox frontend can collect the keys that matter from the <command> elements in the Firefox chrome.

> > Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is
> > this primarily for Flash?
> 
> Yes, it should. In fact, even if it appears to be embedded, Flash is just a
> bunch of windows which share the Device Context with the browser.

Flash is typically a single subwindow. Acrobat is a whole hierarchy of subwindows, and we only hook keystrokes for the toplevel window. That's why I was asking about it.
Whiteboard: [PL2:NA][READ COMMENT 638 BEFORE COMMENTING] → [triage][PL2:NA][READ COMMENT 638 BEFORE COMMENTING]
No longer blocks: fxdesktopbacklog
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #664)
> The Firefox frontend should be in charge of this: perhaps the best option is
> to have an API that the Firefox frontend can call "set browser shortcut
> keys" and then the Firefox frontend can collect the keys that matter from
> the <command> elements in the Firefox chrome.

This sounds like a fine approach. Would it be acceptable to intercept all the keys that fit this category?
Flags: needinfo?(benjamin)
I suspect not: Control-C/V/X at least still need to go to the plugin.
Flags: needinfo?(benjamin)
Sergio, would you still be interested in working on this? If not, would it be possible to put this on a backlog somewhere? Personally, I'm mostly concerned about Flash and CTRL + W (that is, tab closing)...
Flags: needinfo?(mozilla)
This is now (Fx 48~), fixed by bug 1203059 only for "reserved" shortcut keys.

If you think that it's not enough to reserve shortcut keys for some functions, please file a bug for each shortcut key.

Our agreement is, we do NOT enable whole shortcut keys on plugins, e.g., Ctrl+C, etc. So, be careful when you judge if a shortcut key should be "reserved".
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 22 years ago8 years ago
Flags: needinfo?(mozilla)
Keywords: helpwanted
Resolution: --- → FIXED
FYI:

Windows specific fix: bug 1257759
Mac specific fix: bug 1257760

And note that this is WONTFIX on Linux due to event handling model limitation, technically.
Depends on: 1257759, 1257760
Target Milestone: --- → mozilla48
>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
                (all bugs mentioned in comment 676 , comment 677 are already fixed)
STR:
1. Open attachment 8675621 [details]
2. Click in searchbar, then click on the flash
3. Press  Ctrl+L,  or one of the following:  Ctrl+N,  Ctrl+W,  Ctrl+F4,  Ctrl+T,  Ctrl+Tab

AR:  None of them work  (tested in both e10s and non-e10s modes)
ER:  At least some said hotkeys should work (it's really UNCLEAR what hotkeys exactly are "reserved")

So I will (try to) reopen this if there's no reasonable response from your side in 24 hours.
Flags: needinfo?(masayuki)
Hey, I said, "If you think that it's not enough to reserve shortcut keys for some functions, please file a bug for each shortcut key".

And Ctrl+N, Ctrl+W and Ctrl+T should work on Windows. They are reserved shortcut keys.
Flags: needinfo?(masayuki)
And nobody shouldn't reopen this bug because I implemented a way to override shortcut keys even if a plugin has focus. So, if you find specific problem, please file a bug for each problem. This bug has too many CC list and a lot of comments. So, it doesn't make sense to keep discussing on this bug.
Release Note Request (optional, but appreciated)
[Why is this notable]:  Anyone who ever used Firefox is aware of this annoying bug, and now it's fixed
[Suggested wording]:    Reserved Firefox shortcuts now work in plugins like Flash & Acrobat Reader
[Links (documentation, blog post, etc)]:   https://bugzilla.mozilla.org/show_bug.cgi?id=78414#c676
relnote-firefox: --- → ?
Blocks: 533289
Removing the release note flag. Whatever was going on here was happening in the Firefox 48 timeframe.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.