Comment 1 dave shultz 2001-05-01 14:30:07 PDT

Macromedia Bug 67613

Comment 2 Peter Lubczynski 2001-05-01 15:03:19 PDT

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.

Comment 3 Peter Lubczynski 2001-05-01 21:14:32 PDT

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.

Comment 9 mdimitrio 2001-08-14 14:45:49 PDT

Refining the bug report, and giving the current status.

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

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

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

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

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

Marcos.

Comment 11 mdimitrio 2001-08-21 18:33:06 PDT

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.

Comment 15 Jesse Ruderman 2002-04-12 22:39:14 PDT

This only happens when the plugin has focus, right?  If not, my dups might be
incorrect.

Comment 19 Aleksander Adamowski 2002-08-02 11:38:02 PDT

Sergey Lugenov has created a preliminary patch for a bug which seems to be a
dupe of this one, bug 95541.

Comment 20 Aaron Leventhal 2002-09-06 11:40:46 PDT

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.

Comment 21 Marek Z. Jeziorek 2002-09-13 09:57:29 PDT

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 22 Jaime Rodriguez, Jr. 2002-10-07 16:22:10 PDT

Topembed- as this is not currently needed by a major embedding customer.

Comment 23 Aaron Leventhal 2002-10-07 16:34:27 PDT

Jaime, I think this should be topembed+
It's needed by all major embedding customers with accessibility requirements.

Comment 24 sairuh (rarely reading bugmail) 2002-10-07 17:21:01 PDT

renominating. plugin content really does kill keyboard navigation.

Comment 25 Jaime Rodriguez, Jr. 2002-10-07 17:28:19 PDT

sairuh/aaron: do MSIE, 4.x or other browsers currently have this capability?

Comment 26 Aaron Leventhal 2002-10-07 17:38:21 PDT

Yes, IE does.

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

etc.

Comment 27 rubydoo123 2002-10-08 09:17:15 PDT

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?

Comment 28 Aaron Leventhal 2002-10-10 12:03:29 PDT

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.

Comment 35 rubydoo123 2002-12-03 15:46:38 PST

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.

Comment 36 Aaron Leventhal 2002-12-04 12:43:04 PST

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

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

Comment 37 rubydoo123 2002-12-05 15:31:40 PST

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

Comment 38 sairuh (rarely reading bugmail) 2002-12-09 14:39:02 PST

bug 181177 seems to be an alternative for win32 (and maybe unix?) platforms, but
what about macintosh?

Comment 39 rubydoo123 2002-12-09 15:28:03 PST

they are being covered sarah

Comment 40 sairuh (rarely reading bugmail) 2002-12-16 14:25:53 PST

mac is covered by bug 140566.

v dup.

Comment 41 Aaron Leventhal 2003-03-31 10:15:28 PST

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.

Comment 42 Aaron Leventhal 2003-03-31 10:17:16 PST

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.

Comment 43 Peter Lubczynski 2003-03-31 10:20:51 PST

On Windows, if a plugin wants to send shortcut keys to the browser, I wonder if
it can just get the browser's HWND through NPN_GetValue and call ::SendMessage
or if that will that just go back to the plugin? Need to try out idea in a
sample plugin.

Comment 47 Ferran Casarramona 2003-09-12 00:02:35 PDT

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla
Firebird/0.6.1

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

Comment 61 Maxious 2004-04-20 06:05:11 PDT

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

suggesting that http://www.shockwave.com/sw/home/ be used instead

Comment 78 mozilla3eran 2005-01-15 14:03:10 PST

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

Comment 79 Philipp Ringli 2005-01-16 05:31:13 PST

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

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

Comment 80 mozilla3eran 2005-01-16 05:53:31 PST

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

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

Comment 81 Aaron Leventhal 2005-01-17 10:53:34 PST

We're going to have to implement something like the following to get keyboard
accessibility working with plugins:
www.mozilla.org/access/plugins

Comment 83 Wayne Mery (:wsmwk, use Needinfo for questions) 2005-01-24 05:39:04 PST

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)

Comment 87 Jo Hermans 2005-03-24 01:37:57 PST

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

Comment 89 Brian 2005-04-18 19:38:41 PDT

On my Windows 2000, 1.0.3 machine, I have the same problem. Just thought I'd add
my $.02

Comment 92 Aaron Leventhal 2005-05-09 06:47:54 PDT

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

Comment 96 Miernik 2005-08-09 13:01:24 PDT

This even occurs if there is a flash animation in the page, but the flash plugin
is not installed, and the browser displays "Click here to download plugin" in
that place. When we get focus on that, there is no way to get out of it with
keyboard, TAB doesn't get the focus out of there. Testet in Deer Park Alpha 2
from Debian experimental.

Comment 104 Stefan Pietschmann 2005-10-31 02:26:18 PST

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.

Comment 105 Bart Szyszka 2005-11-16 15:06:05 PST

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

Comment 106 Matthew Ratzloff 2005-11-28 16:37:25 PST

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

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

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

That makes for a pretty **** user experience.

Comment 108 M. LaPlante 2005-11-30 20:29:51 PST

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

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

Comment 112 Berkana 2006-01-05 14:45:17 PST

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

Comment 113 VanillaMozilla 2006-02-14 10:01:47 PST

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?

Comment 117 Patrick 2006-05-23 12:49:55 PDT

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

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

Comment 118 Josh 2006-05-23 13:07:58 PDT

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

Comment 120 Wayne Mery (:wsmwk, use Needinfo for questions) 2006-06-15 07:55:04 PDT

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.

Comment 121 Olivier Vit (just a reporter) 2006-06-15 08:51:48 PDT

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 ? 

Comment 122 Wayne Mery (:wsmwk, use Needinfo for questions) 2006-06-15 08:59:53 PDT

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

Comment 123 Marc Bejarano 2006-06-15 09:22:49 PDT

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

Comment 124 Aaron Leventhal 2006-06-15 11:11:06 PDT

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

Comment 127 Stuart Parmenter 2006-08-10 15:33:02 PDT

we'd like this but it needs a better design/idea on how this will work

Comment 132 Andrés G. Aragoneses 2006-10-20 02:06:46 PDT

Be careful with the summary please.

Comment 133 Luke Schlather 2006-10-26 14:35:03 PDT

Ctrl+w should be essential, especially in the case of adobe, where ctrl+w is supposed to close the current document anyway.

Comment 139 Vasilis Pappas 2007-05-04 03:27:00 PDT

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 ?

Comment 140 Marc Bejarano 2007-05-10 13:23:08 PDT

(In reply to comment #139)

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

Comment 159 Jesse Ruderman 2008-04-15 01:02:18 PDT

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

Comment 167 Radek 'sysKin' Czyz 2008-05-22 21:30:59 PDT

Or, for that matter, someone should document what expected behaviour is. Should plugin *and* browser receive key presses? Should plugin not?

Comment 168 Sy Ali 2008-05-23 07:14:54 PDT

comment 167 brings up a very good point.

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

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

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

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

This is almost the current functionality, is it not?

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

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

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

This seems like a simple workaround for now.. thoughts?

Comment 170 S. Ali Tokmen 2008-05-23 10:20:26 PDT

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/

Comment 171 Radek 'sysKin' Czyz 2008-05-23 10:35:14 PDT

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

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

Same when viewing pdfs.

Comment 172 Domenic Denicola 2008-05-23 10:45:18 PDT

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

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

Hmm :-|.

Comment 173 Jerry Baker 2008-05-23 18:10:21 PDT

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

Comment 174 Domenic Denicola 2008-05-23 18:22:32 PDT

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

Comment 175 Unknown W. Brackets 2008-05-23 18:34:39 PDT

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

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

-[Unknown]

Comment 176 Jerry Baker 2008-05-23 18:47:45 PDT

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

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

Comment 177 S. Ali Tokmen 2008-05-24 02:43:21 PDT

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

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

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

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

Any comments are of course welcome!

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

Comment 178 Jerry Baker 2008-05-24 06:45:20 PDT

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.

Comment 179 Unknown W. Brackets 2008-05-24 11:19:21 PDT

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

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

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

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

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

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

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

It's pretty simple.

-[Unknown]

Comment 180 Chris Kohlhardt 2008-05-24 14:50:40 PDT

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.

Comment 181 Jeff Walden [:Waldo] (remove +bmo to email) 2008-05-24 15:24:19 PDT

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

Comment 182 S. Ali Tokmen 2008-05-25 00:20:43 PDT

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

As behavior (specifications?), I would propose:

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

Is anyone OK or not OK with this?

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

Comment 183 Jerry Baker 2008-05-25 01:00:50 PDT

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

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

Comment 184 Rolf Sponsel 2008-05-25 01:57:57 PDT

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

Comment 185 Unknown W. Brackets 2008-05-25 02:48:33 PDT

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]

Comment 186 Rostislav Hristov 2008-05-25 02:50:54 PDT

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

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

Comment 187 Jerry Baker 2008-05-25 03:02:41 PDT

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

Comment 188 Jeff Walden [:Waldo] (remove +bmo to email) 2008-05-25 09:59:22 PDT

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

Comment 190 Unknown W. Brackets 2008-05-27 15:55:11 PDT

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

Comment 194 Roman 2008-06-18 09:57:38 PDT

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

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

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

Comment 201 Timwi 2008-06-20 04:09:45 PDT

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?

Comment 202 Radek 'sysKin' Czyz 2008-06-20 04:26:26 PDT

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

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

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

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

Comment 203 Timwi 2008-06-20 10:43:26 PDT

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

Comment 204 Unknown W. Brackets 2008-06-20 11:37:56 PDT

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]

Comment 210 Steve Bussetti 2008-07-07 23:36:41 PDT

http://www.fossfactory.org/project.php?p=p81

Comment 215 Zachary 2008-07-22 06:00:05 PDT

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

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

alt-ctrl-f

Comment 216 Timwi 2008-07-22 08:20:51 PDT

No, Ctrl+Alt+Letter is an actual character on most keyboard layouts
(e.g. British: Ctrl+Alt+a = á).

Comment 217 Aleksander Adamowski 2008-07-22 11:26:46 PDT

Alt+letter combinations are typically used to input all Polish diacritical characters. Reserving Alt for different use is a big no-no.

Comment 219 Mark Haferkamp 2008-07-28 16:26:48 PDT

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

Comment 220 Steve Bussetti 2008-07-28 16:35:07 PDT

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

Comment 221 Pas 2008-07-28 17:02:57 PDT

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.

Comment 222 [retired] 2008-07-29 03:08:51 PDT

Well the question is: Can we really solve this bug without doing a regression in some case. What we could do is:

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

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

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

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

Comment 223 Jan N. Klug 2008-07-29 03:25:17 PDT

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

Comment 224 Stewart Gordon 2008-07-29 05:34:42 PDT

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

Comment 225 [retired] 2008-07-29 05:47:04 PDT

> > Any more ideas?
> 
> Why not forward those keystrokes the browser isn't interested in to the plugin?

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

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

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

Comment 226 Jerry Baker 2008-07-29 08:41:59 PDT

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

Comment 227 Pas 2008-07-29 08:47:29 PDT

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

Comment 228 Unknown W. Brackets 2008-07-29 11:33:34 PDT

Asking the user doesn't make any sense.

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

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

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

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

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

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

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

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

-[Unknown]

Comment 229 Timwi 2008-07-29 11:52:40 PDT

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

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

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

Comment 230 S. Ali Tokmen 2008-07-29 12:33:15 PDT

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/

Comment 231 Unknown W. Brackets 2008-07-29 13:04:26 PDT

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

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

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

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

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

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

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

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

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

Another plugin (like Adobe Reader) would work similarly.

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

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

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

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

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

-[Unknown]

Comment 232 Jerry Baker 2008-07-29 13:42:15 PDT

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

Comment 233 Mark Haferkamp 2008-07-29 21:29:23 PDT

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.

Comment 236 Simon Bünzli 2008-08-04 13:59:56 PDT

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.

Comment 239 S. Ali Tokmen 2008-08-10 10:21:47 PDT

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

Comment 243 Emerson Prado 2008-09-16 11:49:57 PDT

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

Comment 244 Johnny Stenback (:jst, jst@mozilla.com) 2008-09-23 14:32:09 PDT

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.

Comment 245 Kurt Schultz (supernova_00) 2008-09-23 14:39:15 PDT

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.

Comment 248 Patrick H. Lauke 2008-09-28 15:02:25 PDT

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

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

Comment 249 Jerry Baker 2008-09-28 15:11:39 PDT

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

Comment 250 Arthur 2008-09-28 22:29:57 PDT

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.

Comment 251 [retired] 2008-11-13 07:09:11 PST

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.

Comment 258 Mike 2009-01-11 01:53:40 PST

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.

Comment 259 J 2009-02-11 07:28:38 PST

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

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

Comment 260 J 2009-02-11 07:32:20 PST

IBM proposal:

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

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

Comment 261 Emerson Prado 2009-02-11 08:45:09 PST

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.

Comment 263 mmortal03 2009-03-17 14:17:11 PDT

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

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

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

Comment 264 mmortal03 2009-03-17 14:20:34 PDT

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

Comment 266 Stewart Gordon 2009-03-18 02:16:48 PDT

(In reply to comment #263)

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

Comment 267 mmortal03 2009-03-18 05:56:04 PDT

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

Comment 269 Josh Aas (Mozilla Corporation) 2009-03-20 12:41:13 PDT

There is a specification addressing this problem here:

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

Comment 279 Brian Carpenter [:geeknik] 2009-05-02 13:36:30 PDT

This is not my bug, so I'm not going to add keywords, but I think sec508 needs to be added to the list.

Comment 288 Seth 2009-08-08 17:12:05 PDT

revisiting Comment #259 and Comment #260

Could not Cycle Input focus [1], an AMO extension, be modified to take focus away from the offending (plugin) object such that CTRL+T will function as expected?



1] https://addons.mozilla.org/en-US/firefox/addon/4319

Comment 289 Sduibek 2009-08-13 15:07:32 PDT

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


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


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


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

Removing my CC from this bug permanently.

Comment 294 Jesse Ruderman 2009-08-26 13:12:50 PDT

It sounds like https://wiki.mozilla.org/Plugins:AdvancedKeyHandling is going to happen :)

Comment 297 mr 2009-08-29 16:44:08 PDT

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

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

I hope you can come with a remedy very soon.

Comment 298 memex 2009-08-30 13:22:48 PDT

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

Reproducible: Always

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

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

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

Comment 299 Veritas 2009-08-31 07:36:14 PDT

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

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

Comment 300 Veritas 2009-08-31 07:38:48 PDT

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

Comment 301 alexleykin 2009-08-31 19:20:26 PDT

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

Comment 302 Brian Carpenter [:geeknik] 2009-08-31 19:35:00 PDT

That greasemonkey script is a nice idea, however in 3.7a1pre, the script breaks every single site I visit because I can't do anything due to windows popping up saying undefined. If you fix it, let me know. :)

Comment 303 alexleykin 2009-08-31 20:28:32 PDT

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;
   }
})();

Comment 304 Brian Carpenter [:geeknik] 2009-08-31 20:33:22 PDT

Much better, thanks.

Comment 305 BoffinbraiN 2009-08-31 20:40:28 PDT

(In reply to comment #303)

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

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

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

Comment 306 James Hannan 2009-08-31 22:04:01 PDT

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

Comment 307 alexleykin 2009-09-01 07:35:31 PDT

To defend my puny piece of code :-)

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

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

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

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

Comment 308 alexleykin 2009-09-01 12:54:30 PDT

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

Comment 310 AlekseyM 2009-09-04 16:30:06 PDT

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

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

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

Well, the proposed solution:

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

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

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

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

Comment 311 Brian Weaver 2009-09-09 16:11:53 PDT

I've a couple comments I hope are constructive.

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

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

My proposed solution: 

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

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

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

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

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

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

Comment 312 Mark Haferkamp 2009-09-09 17:40:05 PDT

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

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

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



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

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

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

Comment 313 Mark Haferkamp 2009-09-09 17:45:00 PDT

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


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

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

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

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

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

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

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

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

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

Comment 314 Emerson Prado 2009-09-10 05:41:01 PDT

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

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

Comment 315 Josh Aas (Mozilla Corporation) 2009-09-10 08:30:27 PDT

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

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

Comment 316 Kurt Schultz (supernova_00) 2009-09-10 08:36:04 PDT

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

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

Comment 317 mr 2009-09-11 11:03:47 PDT

Comment #316 sounds good to me.

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

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

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

Comment 318 mr 2009-09-11 11:07:54 PDT

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

Comment 319 Troy Hoshor 2009-09-11 14:41:56 PDT

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

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

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

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

Comment 320 Josh Aas (Mozilla Corporation) 2009-09-11 15:10:43 PDT

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.

Comment 327 KqHvt7qrU3SaKDX8 2009-11-02 12:12:59 PST

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.

Comment 328 Bjartur Thorlacius 2009-11-03 14:19:11 PST

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.

Comment 330 Travis G 2009-12-03 21:18:24 PST

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

Comment 331 Mark Clements 2009-12-04 03:11:29 PST

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

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

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

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

Comment 333 mr 2009-12-04 16:14:24 PST

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

Here come three related problems and their workarounds:

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

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

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

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

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

Comment 334 Shahar Or 2009-12-05 02:18:16 PST

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?

Comment 337 Tyler Downer [:Tyler] 2009-12-07 13:21:49 PST

Please, no more comments unless you have a constructive patch to submit. See comment315 and comment 320.

Comment 338 Steve Bussetti 2010-01-20 11:20:56 PST

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

Comment 341 Emerson Prado 2010-02-01 05:00:22 PST

Pls definitely see Comment 315, Comment 320 and Comment 337. The first fully answers this question.

Comment 345 Virtual_ManPL [:Virtual] 2010-04-03 04:48:54 PDT

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

Comment 346 Sduibek 2010-04-16 07:45:37 PDT

http://www.fossfactory.org/project/p81

http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1385848

Comment 348 eyal gruss (eyaler) 2010-05-13 11:02:45 PDT

also relevant for pressing Alt to show the hidden menu bar

Comment 350 Sduibek 2010-05-22 13:38:10 PDT

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.

Comment 351 Sduibek 2010-05-22 13:40:25 PDT

Created attachment 446914 [details]
code example

Comment 354 Sduibek 2010-06-04 08:19:02 PDT

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.

Comment 355 flamingspinach 2010-06-05 00:25:26 PDT

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.

Comment 356 Steve Bussetti 2010-06-05 12:18:04 PDT

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.

Comment 369 Josh Aas (Mozilla Corporation) 2010-09-01 08:51:01 PDT

Not blocking for the same reason given in comment 244. This is high on our priority list though.

Comment 371 sean2078@hotmail.com 2010-09-18 09:29:27 PDT

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.

Comment 373 Igor Levicki 2010-09-20 18:16:29 PDT

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.

Comment 376 Bob Smith 2010-10-12 16:20:31 PDT

Hello REDDIT!!!!!!

http://www.reddit.com/r/programming/comments/dq9p0/firefox_bug78414_open_for_9_years_reddit_can_we/

Comment 378 Reed Loden [:reed] (use needinfo?) 2010-10-12 19:23:14 PDT

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

Comment 379 Alexander Rødseth 2010-10-13 07:26:18 PDT

The url of this bug has changed to http://www.adobe.com/products/flash/

Comment 380 Igor Levicki 2010-10-13 07:53:37 PDT

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

Comment 382 S. Ali Tokmen 2010-10-13 11:12:17 PDT

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

Comment 384 Igor Levicki 2010-10-13 11:36:22 PDT

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.

Comment 385 Alexander Rødseth 2010-10-14 11:49:12 PDT

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.

Comment 389 Mounir Lamouri (:mounir) 2010-11-29 03:43:42 PST

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?

Comment 390 desasterman 2010-11-29 12:05:07 PST

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

Comment 391 Takanori MATSUURA 2010-11-29 15:45:13 PST

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

Comment 392 Alex Limi (:limi) — Firefox UX Team 2010-11-30 15:20:10 PST

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

Comment 394 duke578 2010-12-13 11:27:19 PST

i am having the same problem and i have tried to enter the ctrl- key first and the same problem keeps coming back.

Comment 398 mr 2011-01-14 10:35:05 PST

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.

Comment 400 Filip Zakrzewski 2011-01-15 00:21:08 PST

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

Comment 401 Filip Zakrzewski 2011-01-15 00:27:41 PST

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?

Comment 402 avada 2011-01-15 02:44:17 PST

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

Comment 403 Alex Limi (:limi) — Firefox UX Team 2011-01-18 11:31:39 PST

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.

Comment 404 Russell Davis 2011-01-18 13:39:14 PST

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

Comment 405 Pas 2011-01-18 14:52:02 PST

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.

Comment 406 Alex Limi (:limi) — Firefox UX Team 2011-01-19 09:35:50 PST

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

Comment 407 Russell Davis 2011-01-19 11:32:20 PST

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

Comment 408 Steve Chapel 2011-01-19 12:01:32 PST

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.

Comment 409 vldjmxqxevbki 2011-01-19 12:46:09 PST

Cool! After 10 years of having this problem, now we're getting threatened too! That's some etiquette...

Comment 410 mcdreamy81 2011-01-20 00:44:51 PST

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

Comment 411 Hugo Elias 2011-01-20 02:38:12 PST

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.

Comment 412 Eamon Nerbonne 2011-01-20 02:48:33 PST

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

Comment 413 Filip Zakrzewski 2011-01-20 03:08:49 PST

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.

Comment 414 Tamas Hubai (:htamas) 2011-01-20 03:44:21 PST

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.

Comment 415 Alex R. 2011-01-27 05:24:06 PST

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.

Comment 416 Igor Levicki 2011-01-27 06:51:00 PST

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

Comment 417 Alex R. 2011-01-27 07:12:03 PST

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

Comment 418 Igor Levicki 2011-01-27 07:39:14 PST

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

Comment 419 Alex R. 2011-01-27 07:45:53 PST

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

Comment 420 s.mocking 2011-01-27 13:44:23 PST

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

Comment 421 Igor Levicki 2011-01-27 16:38:24 PST

The comment above is exactly what I had in mind, thank you for explaining it so nicely.

Comment 422 L. Mohan Arun 2011-01-28 01:11:32 PST

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

Comment 423 Alex R. 2011-01-28 01:54:20 PST

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

Comment 424 Igor Levicki 2011-01-28 02:30:06 PST

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.

Comment 425 S. Ali Tokmen 2011-01-28 02:53:15 PST

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

Comment 426 Alex R. 2011-01-28 03:10:30 PST

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

Comment 427 Carlo Alberto Ferraris 2011-01-28 05:44:39 PST

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.

Comment 428 Alex R. 2011-01-28 06:08:20 PST

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

Comment 429 Jerry Baker 2011-01-28 06:10:51 PST

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

Comment 430 Jerry Baker 2011-01-28 06:13:59 PST

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

Comment 431 Igor Levicki 2011-01-28 07:33:25 PST

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

Comment 432 s.mocking 2011-01-28 08:36:20 PST

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

Comment 433 Chris Harrington 2011-01-28 08:45:45 PST

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.

Comment 434 Steve Chapel 2011-01-28 08:52:07 PST

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.

Comment 435 bugzilla 2011-01-28 08:56:04 PST

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.

Comment 436 bugzilla 2011-01-28 08:59:32 PST

In response comment 424: mozillazine is a third party site, not actually affiliated with mozilla.  Discussion there has little bearing on what happens here.

Comment 437 Tim H. 2011-01-28 10:38:34 PST

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

Comment 438 Unknown W. Brackets 2011-01-28 18:58:07 PST

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]

Comment 439 Alex R. 2011-01-29 03:35:44 PST

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

Comment 440 Igor Levicki 2011-01-29 09:08:22 PST

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

Comment 441 mr 2011-01-29 10:43:49 PST

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.

Comment 442 Igor Levicki 2011-01-29 11:45:19 PST

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.

Comment 443 S. Ali Tokmen 2011-01-29 13:54:36 PST

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

Comment 444 S. Ali Tokmen 2011-01-30 05:56:18 PST

Created attachment 508230 [details] [diff] [review]
Workaround patch for Windows and GTK2

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/

Comment 445 Mardeg 2011-01-30 07:07:06 PST

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

Comment 446 Roman 2011-01-30 07:11:52 PST

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?

Comment 447 S. Ali Tokmen 2011-01-30 08:02:53 PST

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

Comment 448 mr 2011-01-30 08:28:51 PST

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

Comment 449 Roman 2011-01-30 09:26:14 PST

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

Comment 450 Filip Zakrzewski 2011-01-30 09:35:35 PST

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

Comment 451 S. Ali Tokmen 2011-01-30 10:26:18 PST

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

Comment 452 Filip Zakrzewski 2011-01-31 00:07:26 PST

(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

Comment 453 s.mocking 2011-01-31 05:18:04 PST

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();
}

Comment 454 S. Ali Tokmen 2011-01-31 07:32:10 PST

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

Comment 455 Filip Zakrzewski 2011-01-31 08:07:02 PST

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)

Comment 456 Igor Levicki 2011-01-31 08:34:43 PST

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.

Comment 457 S. Ali Tokmen 2011-01-31 08:51:18 PST

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/

Comment 458 s.mocking 2011-01-31 09:27:44 PST

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();

Comment 459 S. Ali Tokmen 2011-01-31 09:35:32 PST

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/

Comment 460 Roman 2011-01-31 14:48:07 PST

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

Comment 461 s.mocking 2011-01-31 15:04:56 PST

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

Comment 462 mushu5t 2011-03-01 19:40:59 PST

Also, viewing an SWF in the entire browser area COMPLETELY disabled keyboard shortcuts.

Comment 463 mr 2011-03-02 01:59:22 PST

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

Comment 464 Shahar Or 2011-03-03 03:02:12 PST

Dearest Friends,

OMG please fix this.

Blessings,
Shahar

Comment 465 auscompgeek 2011-03-03 03:08:42 PST

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

Comment 466 Jerry Baker 2011-03-03 06:15:12 PST

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

Comment 467 Matthias Versen [:Matti] 2011-03-09 08:10:34 PST

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

Comment 468 xilonic 2011-03-10 09:14:24 PST

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.

Comment 469 Jerry Baker 2011-03-10 09:21:49 PST

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

Comment 470 Jeremy Nickurak 2011-03-10 09:25:32 PST

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.

Comment 471 xilonic 2011-03-10 10:36:46 PST

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

Comment 472 Steve Bussetti 2011-03-10 18:09:54 PST

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

Comment 473 Piyush Soni 2011-03-10 18:25:21 PST

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.

Comment 474 Henrik Skupin (:whimboo) 2011-03-20 17:15:05 PDT

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

Comment 475 Matthias Versen [:Matti] 2011-03-29 06:03:54 PDT

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

Comment 476 Matthias Versen [:Matti] 2011-03-29 06:04:47 PDT

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

Comment 477 Matthias Versen [:Matti] 2011-03-29 06:05:50 PDT

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

Comment 478 mushu5t 2011-03-29 13:36:49 PDT

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.

Comment 479 mushu5t 2011-03-29 13:38:21 PDT

(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

Comment 480 Matthias Versen [:Matti] 2011-04-01 17:35:24 PDT

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

Comment 481 Matthias Versen [:Matti] 2011-04-01 18:30:54 PDT

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

Comment 482 Jorge Vidal Wulff 2011-04-12 09:17:29 PDT

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.

Comment 483 mr 2011-04-12 09:56:50 PDT

(In reply to comment #482)

But clicking the window title doesn't change the focus, does it?

Comment 484 Jorge Vidal Wulff 2011-04-12 10:05:55 PDT

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.

Comment 485 Jorge Vidal Wulff 2011-04-12 10:06:33 PDT

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.

Comment 486 flamingspinach 2011-04-12 16:43:45 PDT

(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 487 Josh Aas (Mozilla Corporation) 2011-04-19 12:53:22 PDT

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.

Comment 488 Piyush Soni 2011-04-19 13:22:51 PDT

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

Comment 489 Virtual_ManPL [:Virtual] 2011-04-26 01:14:22 PDT

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

Comment 490 Peter Reynolds 2011-04-30 05:48:49 PDT

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 491 W 2011-04-30 14:17:37 PDT

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

Comment 492 W 2011-04-30 14:25:22 PDT

And what about this? https://wiki.mozilla.org/NPAPI:AdvancedKeyHandling

Comment 493 Pas 2011-04-30 17:15:55 PDT

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.

Comment 494 :aceman 2011-05-14 05:04:08 PDT

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

Comment 495 Alexander Rødseth 2011-05-26 09:49:03 PDT

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.

Comment 496 S. Ali Tokmen 2011-05-26 10:30:58 PDT

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

Comment 497 Veritas 2011-05-26 10:37:22 PDT

this bug is now a decade old! happy birthday!!!

Comment 498 dopra winfree 2011-06-03 06:51:10 PDT

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

Comment 499 W 2011-06-03 09:38:13 PDT

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.