Last Comment Bug 78414 - (PluginShortcuts) Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus
(PluginShortcuts)
: Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fai...
Status: RESOLVED FIXED
[triage][PL2:NA][READ COMMENT 638 BEF...
: access, common-issue?, shockwave, top100, topembed+
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: P3 major with 428 votes (vote)
: mozilla48
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28))
:
Mentors:
: 84159 94900 96091 104829 112299 120921 137077 140566 155843 158168 168639 176078 176925 177961 180096 180580 195151 199984 201186 217857 224489 229865 233159 234469 236571 236653 236731 237134 239687 241880 246517 262404 265508 265613 265779 273744 275541 275895 276695 278389 278538 278964 279532 279625 279767 291536 293262 296093 296595 298085 313128 313875 314104 314282 318267 318870 320386 321869 341813 349426 351862 353082 356765 358343 359781 373471 376356 384413 390118 390150 394306 403119 413756 413986 423117 423927 427274 427635 428911 428949 429028 432283 434720 434760 435180 435671 436001 436958 437839 437913 439079 439685 441148 441571 442073 444514 448066 448670 449923 449968 450998 452182 457006 466270 468813 469638 469959 471237 471600 482121 484213 484908 486116 489599 498285 499517 502247 503182 505689 508535 511209 513043 517675 521978 524024 524156 524425 526983 533289 541845 549467 556968 561136 566783 569016 570111 574646 575284 576754 577640 584958 592016 594015 596940 599643 600400 609220 609234 614835 616464 619856 625809 640173 642849 644539 645928 652453 662333 665361 683453 688528 723836 744544 801880 811225 819566 931686 936902 938309 939422 992628 1029444 1077155 1111982 1164860 1174902 1274240 1288978 (view as bug list)
Depends on: 181177 380637 491141 502128 78846 348279 788718 1203059 1257759 1257760
Blocks: 93149 491178 cuts-focus 164421 273456 395980 477256
  Show dependency treegraph
 
Reported: 2001-05-01 14:28 PDT by dave shultz
Modified: 2016-08-03 05:00 PDT (History)
440 users (show)
jst: blocking1.9.2-
jst: blocking1.9.1-
jst: wanted1.9.1+
pavlov: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
?


Attachments
code example (6.10 KB, application/x-zip-compressed)
2010-05-22 13:40 PDT, u304036
no flags Details
Patch for fixing this issue on Linux/Gtk2 (4.01 KB, patch)
2010-10-14 11:49 PDT, Alexander Rødseth
jaas: review-
Details | Diff | Splinter Review
Workaround patch for Windows and GTK2 (3.81 KB, patch)
2011-01-30 05:56 PST, S. Ali Tokmen
no flags Details | Diff | Splinter Review
PoC patch for both winless and windowed plugins. (Windows) (8.72 KB, patch)
2013-11-05 02:22 PST, Sergio Lopez
no flags Details | Diff | Splinter Review

Description dave shultz 2001-05-01 14:28:21 PDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
BuildID:    2001042508

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

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

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

Expected Results:  The movie should be able to play and the application 
keyboard commands should not be affected by Shockwave playback.
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 4 karnaze (gone) 2001-05-15 13:27:10 PDT Comment hidden (obsolete)
Comment 5 Peter Lubczynski 2001-06-05 16:49:03 PDT Comment hidden (obsolete)
Comment 6 Peter Lubczynski 2001-07-24 09:13:28 PDT Comment hidden (obsolete)
Comment 7 shrirang khanzode 2001-08-13 10:05:01 PDT Comment hidden (obsolete)
Comment 8 mdimitrio 2001-08-13 10:31:56 PDT Comment hidden (obsolete)
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 10 Matthias Versen [:Matti] 2001-08-21 00:02:59 PDT Comment hidden (obsolete)
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 12 Jesse Ruderman 2001-11-23 17:35:18 PST Comment hidden (obsolete)
Comment 13 sairuh (rarely reading bugmail) 2001-11-27 19:08:11 PST Comment hidden (obsolete)
Comment 14 scottputterman 2002-03-04 19:23:18 PST Comment hidden (obsolete)
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 16 Jesse Ruderman 2002-04-12 22:39:36 PDT Comment hidden (obsolete)
Comment 17 rubydoo123 2002-07-11 12:11:49 PDT Comment hidden (obsolete)
Comment 18 rubydoo123 2002-07-18 13:08:26 PDT Comment hidden (obsolete)
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 29 WD 2002-10-23 07:53:58 PDT Comment hidden (obsolete)
Comment 30 WD 2002-10-26 16:17:16 PDT Comment hidden (obsolete)
Comment 31 R.K.Aa. 2002-11-14 03:07:57 PST Comment hidden (obsolete)
Comment 32 R.K.Aa. 2002-11-14 03:12:21 PST Comment hidden (obsolete)
Comment 33 R.K.Aa. 2002-11-17 07:31:05 PST Comment hidden (obsolete)
Comment 34 Chris Lyon 2002-11-29 10:00:30 PST Comment hidden (obsolete)
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 44 Gilles Durys 2003-03-31 12:29:38 PST Comment hidden (obsolete)
Comment 45 Chris Lyon 2003-04-02 12:15:00 PST Comment hidden (obsolete)
Comment 46 Torben 2003-04-08 13:58:08 PDT Comment hidden (obsolete)
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 48 Mike Connor [:mconnor] 2003-09-25 17:41:24 PDT Comment hidden (obsolete)
Comment 49 Bill Mason 2003-11-02 15:14:35 PST Comment hidden (obsolete)
Comment 50 Torben 2003-12-28 12:44:44 PST Comment hidden (obsolete)
Comment 51 José Jeria 2004-01-01 16:55:41 PST Comment hidden (obsolete)
Comment 52 José Jeria 2004-01-06 07:28:30 PST Comment hidden (obsolete)
Comment 53 Alexander 'Chewie' Hirzel 2004-02-06 07:29:48 PST Comment hidden (obsolete)
Comment 54 José Jeria 2004-02-16 01:48:41 PST Comment hidden (obsolete)
Comment 55 Kyle Yuan 2004-02-23 18:07:39 PST Comment hidden (obsolete)
Comment 56 Isaac Hwak Han 2004-03-05 09:28:09 PST Comment hidden (obsolete)
Comment 57 Jo Hermans 2004-03-06 02:20:54 PST Comment hidden (obsolete)
Comment 58 José Jeria 2004-03-07 09:38:23 PST Comment hidden (obsolete)
Comment 59 José Jeria 2004-03-25 16:57:05 PST Comment hidden (obsolete)
Comment 60 José Jeria 2004-04-05 07:21:35 PDT Comment hidden (obsolete)
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 62 Bill Mason 2004-04-27 09:49:28 PDT Comment hidden (obsolete)
Comment 63 Alex Fihman 2004-07-09 11:20:08 PDT Comment hidden (obsolete)
Comment 64 Alex Fihman 2004-07-09 11:26:07 PDT Comment hidden (obsolete)
Comment 65 Marc Bejarano 2004-07-16 13:39:42 PDT Comment hidden (obsolete)
Comment 66 Frank Wein [:mcsmurf] 2004-07-28 10:55:33 PDT Comment hidden (obsolete)
Comment 67 sairuh (rarely reading bugmail) 2004-07-30 12:00:34 PDT Comment hidden (obsolete)
Comment 68 Jo Hermans 2004-10-01 12:19:16 PDT Comment hidden (obsolete)
Comment 69 Bill Mason 2004-10-21 14:21:59 PDT Comment hidden (obsolete)
Comment 70 José Jeria 2004-10-22 14:52:26 PDT Comment hidden (obsolete)
Comment 71 Bill Mason 2004-12-06 16:20:15 PST Comment hidden (obsolete)
Comment 72 Jo Hermans 2004-12-08 09:01:53 PST Comment hidden (obsolete)
Comment 73 Jo Hermans 2004-12-21 07:43:05 PST Comment hidden (obsolete)
Comment 74 Jesse Ruderman 2004-12-25 16:15:48 PST Comment hidden (obsolete)
Comment 75 José Jeria 2005-01-01 12:58:27 PST Comment hidden (obsolete)
Comment 76 Kevin Brosnan 2005-01-14 08:03:04 PST Comment hidden (obsolete)
Comment 77 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-15 13:31:39 PST Comment hidden (obsolete)
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 82 Olivier Cahagne 2005-01-19 03:22:35 PST Comment hidden (obsolete)
Comment 83 Wayne Mery (:wsmwk, NI 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 84 Wayne Mery (:wsmwk, NI for questions) 2005-01-24 05:41:19 PST Comment hidden (obsolete)
Comment 85 Kevin Brosnan 2005-01-24 11:22:47 PST Comment hidden (obsolete)
Comment 86 Jo Hermans 2005-01-25 08:11:27 PST Comment hidden (obsolete)
Comment 87 Jo Hermans 2005-03-24 01:37:57 PST
*** Bug 287467 has been marked as a duplicate of this bug. ***
Comment 88 Brian 2005-04-18 19:37:17 PDT Comment hidden (obsolete)
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 90 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-04-22 16:59:31 PDT Comment hidden (obsolete)
Comment 91 Kevin Brosnan 2005-05-07 09:25:33 PDT Comment hidden (obsolete)
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 93 Patrick 2005-05-31 11:31:36 PDT Comment hidden (obsolete)
Comment 94 José Jeria 2005-06-04 03:05:37 PDT Comment hidden (obsolete)
Comment 95 José Jeria 2005-06-18 09:16:14 PDT Comment hidden (obsolete)
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 97 Pieter Botha 2005-08-09 13:16:41 PDT Comment hidden (obsolete)
Comment 98 Stephen Donner [:stephend] 2005-08-09 13:18:44 PDT Comment hidden (obsolete)
Comment 99 :Mook 2005-08-11 01:53:56 PDT Comment hidden (obsolete)
Comment 100 Kevin Brosnan 2005-10-20 05:29:22 PDT Comment hidden (obsolete)
Comment 101 José Jeria 2005-10-27 13:03:54 PDT Comment hidden (obsolete)
Comment 102 José Jeria 2005-10-28 03:01:50 PDT Comment hidden (obsolete)
Comment 103 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-10-28 19:50:29 PDT Comment hidden (obsolete)
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 107 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-11-30 08:28:41 PST Comment hidden (obsolete)
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 109 Reed Loden [:reed] (use needinfo?) 2005-12-02 22:16:32 PST Comment hidden (obsolete)
Comment 110 Patrick 2005-12-15 11:59:46 PST Comment hidden (obsolete)
Comment 111 Adam Guthrie 2005-12-30 17:43:10 PST Comment hidden (obsolete)
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 114 Aaron D. 2006-04-15 20:10:17 PDT Comment hidden (obsolete)
Comment 115 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-18 10:29:24 PDT Comment hidden (obsolete)
Comment 116 len 2006-05-23 12:40:25 PDT Comment hidden (obsolete)
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 119 Wayne Mery (:wsmwk, NI for questions) 2006-06-15 07:21:52 PDT Comment hidden (obsolete)
Comment 120 Wayne Mery (:wsmwk, NI 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, NI 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 125 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-06-16 14:26:22 PDT Comment hidden (obsolete)
Comment 126 Wayne Mery (:wsmwk, NI for questions) 2006-06-26 06:02:51 PDT Comment hidden (obsolete)
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 128 Jo Hermans 2006-08-20 12:07:11 PDT Comment hidden (obsolete)
Comment 129 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-09-08 13:30:50 PDT Comment hidden (obsolete)
Comment 130 Adam Guthrie 2006-09-17 19:37:30 PDT Comment hidden (obsolete)
Comment 131 Ria Klaassen (not reading all bugmail) 2006-10-15 23:39:08 PDT Comment hidden (obsolete)
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 134 Gilles Durys 2006-10-27 02:59:04 PDT Comment hidden (obsolete)
Comment 135 Ria Klaassen (not reading all bugmail) 2006-11-07 03:40:42 PST Comment hidden (obsolete)
Comment 136 Martin K 2007-01-22 15:55:32 PST Comment hidden (obsolete)
Comment 137 Brian Polidoro 2007-03-10 20:53:44 PST Comment hidden (obsolete)
Comment 138 Ria Klaassen (not reading all bugmail) 2007-04-03 08:28:41 PDT Comment hidden (obsolete)
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 141 Jo Hermans 2007-06-14 06:49:55 PDT Comment hidden (obsolete)
Comment 142 Stephen Donner [:stephend] 2007-07-30 03:00:08 PDT Comment hidden (obsolete)
Comment 143 Adam Guthrie 2007-07-30 10:42:18 PDT Comment hidden (obsolete)
Comment 144 Jo Hermans 2007-08-30 06:41:00 PDT Comment hidden (obsolete)
Comment 145 Aaron Leventhal 2007-11-08 17:26:11 PST Comment hidden (obsolete)
Comment 146 Kevin Brosnan 2008-01-23 16:32:48 PST Comment hidden (obsolete)
Comment 147 Jo Hermans 2008-03-15 04:43:01 PDT Comment hidden (obsolete)
Comment 148 Kevin Brosnan 2008-03-19 11:55:49 PDT Comment hidden (obsolete)
Comment 149 Jo Hermans 2008-04-05 12:49:02 PDT Comment hidden (obsolete)
Comment 150 S. Ali Tokmen 2008-04-07 14:43:56 PDT Comment hidden (obsolete)
Comment 151 S. Ali Tokmen 2008-04-07 14:45:10 PDT Comment hidden (obsolete)
Comment 152 u88484 2008-04-07 16:35:24 PDT Comment hidden (obsolete)
Comment 153 S. Ali Tokmen 2008-04-09 11:48:08 PDT Comment hidden (obsolete)
Comment 154 Alex Hosking 2008-04-09 14:36:53 PDT Comment hidden (obsolete)
Comment 155 Andrés G. Aragoneses 2008-04-10 03:10:12 PDT Comment hidden (obsolete)
Comment 156 Jo Hermans 2008-04-14 07:01:06 PDT Comment hidden (obsolete)
Comment 157 Phil Ringnalda (:philor) 2008-04-14 10:45:37 PDT Comment hidden (obsolete)
Comment 158 Simon Bünzli 2008-04-15 00:36:28 PDT Comment hidden (obsolete)
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 160 Kevin Brosnan 2008-05-05 12:08:17 PDT Comment hidden (obsolete)
Comment 161 Carsten Book [:Tomcat] 2008-05-20 13:58:33 PDT Comment hidden (obsolete)
Comment 162 Jo Hermans 2008-05-22 07:23:46 PDT Comment hidden (obsolete)
Comment 163 Dave Tinker 2008-05-22 08:37:09 PDT Comment hidden (obsolete)
Comment 164 Sy Ali 2008-05-22 08:58:07 PDT Comment hidden (obsolete)
Comment 165 Ciaran Welch 2008-05-22 13:13:34 PDT Comment hidden (obsolete)
Comment 166 Gabriel Chadwick 2008-05-22 13:48:48 PDT Comment hidden (obsolete)
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 169 Unknown W. Brackets 2008-05-23 10:16:02 PDT Comment hidden (obsolete)
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 189 Ryan A. C. 2008-05-25 21:15:17 PDT Comment hidden (obsolete)
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 191 Kevin Brosnan 2008-06-02 17:33:21 PDT Comment hidden (obsolete)
Comment 192 Steve England [:stevee] 2008-06-13 09:22:58 PDT Comment hidden (obsolete)
Comment 193 Dão Gottwald [:dao] 2008-06-18 05:27:22 PDT Comment hidden (obsolete)
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 195 S. Ali Tokmen 2008-06-18 15:31:17 PDT Comment hidden (obsolete)
Comment 196 Andrés G. Aragoneses 2008-06-19 02:06:19 PDT Comment hidden (obsolete)
Comment 197 Timwi 2008-06-19 03:27:42 PDT Comment hidden (obsolete)
Comment 198 Andrés G. Aragoneses 2008-06-19 04:36:42 PDT Comment hidden (obsolete)
Comment 199 Jerry Baker 2008-06-19 11:17:03 PDT Comment hidden (obsolete)
Comment 200 Timwi 2008-06-19 12:44:22 PDT Comment hidden (obsolete)
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 205 Jo Hermans 2008-06-22 09:01:40 PDT Comment hidden (obsolete)
Comment 206 José Jeria 2008-06-24 10:12:31 PDT Comment hidden (obsolete)
Comment 207 Phil Ringnalda (:philor) 2008-06-26 17:37:00 PDT Comment hidden (obsolete)
Comment 208 Dão Gottwald [:dao] 2008-07-04 05:40:03 PDT Comment hidden (obsolete)
Comment 209 Dão Gottwald [:dao] 2008-07-04 05:44:07 PDT Comment hidden (obsolete)
Comment 210 Steve Bussetti 2008-07-07 23:36:41 PDT
http://www.fossfactory.org/project.php?p=p81
Comment 211 Bruno Faria 2008-07-20 12:02:58 PDT Comment hidden (obsolete)
Comment 212 Damian Shaw [Quan] 2008-07-20 12:21:15 PDT Comment hidden (obsolete)
Comment 213 Ryan S. Scheel [:havvy] 2008-07-20 21:49:42 PDT Comment hidden (obsolete)
Comment 214 Chris Taylor 2008-07-21 01:11:59 PDT Comment hidden (obsolete)
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 218 Matthias Versen [:Matti] 2008-07-25 22:09:42 PDT Comment hidden (obsolete)
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 Tobias (:Tobbi) Markus 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 Tobias (:Tobbi) Markus 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 234 u88484 2008-07-31 14:10:38 PDT Comment hidden (obsolete)
Comment 235 Ginn Chen 2008-08-03 07:47:23 PDT Comment hidden (obsolete)
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 237 Kevin Brosnan 2008-08-09 13:05:07 PDT Comment hidden (obsolete)
Comment 238 Tyler Downer [:Tyler] 2008-08-09 18:23:59 PDT Comment hidden (obsolete)
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 240 Matthias Versen [:Matti] 2008-08-18 03:31:31 PDT Comment hidden (obsolete)
Comment 241 Simon Bünzli 2008-08-30 18:19:03 PDT Comment hidden (obsolete)
Comment 242 James Hannan 2008-09-02 14:21:58 PDT Comment hidden (obsolete)
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 u88484 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 246 Thomas K. (:tom) 2008-09-28 14:32:48 PDT Comment hidden (obsolete)
Comment 247 Thomas K. (:tom) 2008-09-28 14:33:04 PDT Comment hidden (obsolete)
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 Tobias (:Tobbi) Markus 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 252 Simon Bünzli 2008-11-22 03:09:42 PST Comment hidden (obsolete)
Comment 253 Matthias Versen [:Matti] 2008-12-10 09:44:26 PST Comment hidden (obsolete)
Comment 254 Dão Gottwald [:dao] 2008-12-15 01:51:20 PST Comment hidden (obsolete)
Comment 255 Matthias Versen [:Matti] 2008-12-17 03:39:10 PST Comment hidden (obsolete)
Comment 256 Dão Gottwald [:dao] 2008-12-27 01:38:03 PST Comment hidden (obsolete)
Comment 257 Emil 2008-12-31 04:25:55 PST Comment hidden (obsolete)
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 262 Simon Bünzli 2009-03-08 06:25:08 PDT Comment hidden (obsolete)
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 265 L. Mohan Arun 2009-03-17 22:19:21 PDT Comment hidden (obsolete)
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 268 Kevin Brosnan 2009-03-19 21:47:04 PDT Comment hidden (obsolete)
Comment 269 Josh Aas 2009-03-20 12:41:13 PDT
There is a specification addressing this problem here:

https://wiki.mozilla.org/Plugins:AdvancedKeyHandling
Comment 270 Kevin Brosnan 2009-03-24 12:22:20 PDT Comment hidden (obsolete)
Comment 271 Steve England [:stevee] 2009-03-31 08:15:29 PDT Comment hidden (obsolete)
Comment 272 Sean Carolan 2009-03-31 08:18:28 PDT Comment hidden (obsolete)
Comment 273 BoffinbraiN 2009-04-04 17:12:51 PDT Comment hidden (obsolete)
Comment 274 orion.mozilla 2009-04-04 20:42:26 PDT Comment hidden (obsolete)
Comment 275 L. Mohan Arun 2009-04-04 22:26:08 PDT Comment hidden (obsolete)
Comment 276 BoffinbraiN 2009-04-05 23:11:21 PDT Comment hidden (obsolete)
Comment 277 Steve England [:stevee] 2009-04-22 09:37:21 PDT Comment hidden (obsolete)
Comment 278 Michael Kohler [:mkohler] 2009-04-29 15:45:57 PDT Comment hidden (obsolete)
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 280 Matthias Versen [:Matti] 2009-06-19 13:21:08 PDT Comment hidden (obsolete)
Comment 281 :Gavin Sharp [email: gavin@gavinsharp.com] 2009-06-20 16:04:06 PDT Comment hidden (obsolete)
Comment 282 Kevin Brosnan 2009-07-03 10:20:51 PDT Comment hidden (obsolete)
Comment 283 Jo Hermans 2009-07-08 15:10:52 PDT Comment hidden (obsolete)
Comment 284 Sylvain Pasche 2009-07-17 22:42:42 PDT Comment hidden (obsolete)
Comment 285 Dão Gottwald [:dao] 2009-07-22 01:42:29 PDT Comment hidden (obsolete)
Comment 286 Johnny Stenback (:jst, jst@mozilla.com) 2009-07-22 16:45:39 PDT Comment hidden (obsolete)
Comment 287 Matthias Versen [:Matti] 2009-08-05 13:45:36 PDT Comment hidden (obsolete)
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 u304036 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 290 Chris Taylor 2009-08-14 03:39:19 PDT Comment hidden (obsolete)
Comment 291 Andrés G. Aragoneses 2009-08-14 08:42:41 PDT Comment hidden (obsolete)
Comment 292 spiralofhope 2009-08-14 12:39:12 PDT Comment hidden (obsolete)
Comment 293 Dão Gottwald [:dao] 2009-08-21 01:49:02 PDT Comment hidden (obsolete)
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 295 S. Ali Tokmen 2009-08-26 13:39:30 PDT Comment hidden (obsolete)
Comment 296 Ria Klaassen (not reading all bugmail) 2009-08-27 14:10:30 PDT Comment hidden (obsolete)
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 309 u88484 2009-09-03 12:33:35 PDT Comment hidden (obsolete)
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 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 u88484 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 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 321 Tanner Filip [:tanner] 2009-09-13 07:13:51 PDT Comment hidden (obsolete)
Comment 322 Filip Zakrzewski 2009-09-22 23:14:49 PDT Comment hidden (obsolete)
Comment 323 Tobias (:Tobbi) Markus 2009-10-13 05:11:53 PDT Comment hidden (obsolete)
Comment 324 Jo Hermans 2009-10-23 02:04:23 PDT Comment hidden (obsolete)
Comment 325 Dão Gottwald [:dao] 2009-10-26 00:51:01 PDT Comment hidden (obsolete)
Comment 326 Dão Gottwald [:dao] 2009-10-26 00:57:29 PDT Comment hidden (obsolete)
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 329 Jo Hermans 2009-11-06 05:54:15 PST Comment hidden (obsolete)
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 332 BoffinbraiN 2009-12-04 12:31:12 PST Comment hidden (obsolete)
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 335 Ria Klaassen (not reading all bugmail) 2009-12-07 11:48:03 PST Comment hidden (obsolete)
Comment 336 Emerson Prado 2009-12-07 13:04:42 PST Comment hidden (obsolete)
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 339 Matthias Versen [:Matti] 2010-01-24 12:03:07 PST Comment hidden (obsolete)
Comment 340 tsmith35 2010-01-29 23:19:48 PST Comment hidden (obsolete)
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 342 Samuel 2010-02-08 21:05:04 PST Comment hidden (obsolete)
Comment 343 Jo Hermans 2010-03-01 15:19:45 PST Comment hidden (obsolete)
Comment 344 Matthias Versen [:Matti] 2010-04-03 01:47:42 PDT Comment hidden (obsolete)
Comment 345 Virtual_ManPL [:Virtual] - (ni? me) 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 347 Josh Aas 2010-04-22 21:02:41 PDT Comment hidden (obsolete)
Comment 348 eyal gruss (eyaler) 2010-05-13 11:02:45 PDT
also relevant for pressing Alt to show the hidden menu bar
Comment 349 Tim (fmdeveloper) 2010-05-18 21:49:48 PDT Comment hidden (obsolete)
Comment 350 u304036 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 u304036 2010-05-22 13:40:25 PDT
Created attachment 446914 [details]
code example
Comment 352 Dave Garrett 2010-05-29 14:29:50 PDT Comment hidden (obsolete)
Comment 353 Ria Klaassen (not reading all bugmail) 2010-06-04 06:45:02 PDT Comment hidden (obsolete)
Comment 354 u304036 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 357 romiangulo 2010-06-23 04:27:28 PDT Comment hidden (obsolete)
Comment 358 Tiago Sá 2010-06-23 04:39:23 PDT Comment hidden (obsolete)
Comment 359 romiangulo 2010-06-23 04:48:09 PDT Comment hidden (obsolete)
Comment 360 Tiago Sá 2010-06-23 04:53:33 PDT Comment hidden (obsolete)
Comment 361 Damian Shaw [Quan] 2010-06-23 05:01:18 PDT Comment hidden (obsolete)
Comment 362 Emerson Prado 2010-06-23 05:47:46 PDT Comment hidden (obsolete)
Comment 363 Kevin Brosnan 2010-06-28 08:30:29 PDT Comment hidden (obsolete)
Comment 364 Kevin Brosnan 2010-07-03 05:30:24 PDT Comment hidden (obsolete)
Comment 365 soget 2010-07-29 01:16:04 PDT Comment hidden (obsolete)
Comment 366 bugzilla 2010-07-29 09:31:30 PDT Comment hidden (obsolete)
Comment 367 u304036 2010-07-30 07:45:25 PDT Comment hidden (obsolete)
Comment 368 Tim (fmdeveloper) 2010-08-06 13:01:47 PDT Comment hidden (obsolete)
Comment 369 Josh Aas 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 370 Mardeg 2010-09-16 04:06:48 PDT Comment hidden (obsolete)
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 372 Virtual_ManPL [:Virtual] - (ni? me) 2010-09-19 04:47:09 PDT Comment hidden (obsolete)
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 374 Kevin Brosnan 2010-09-25 12:52:12 PDT Comment hidden (obsolete)
Comment 375 Tyler Downer [:Tyler] 2010-09-28 18:07:28 PDT Comment hidden (obsolete)
Comment 377 Jonathan Boyai 2010-10-12 18:13:53 PDT Comment hidden (obsolete)
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 381 EP 2010-10-13 07:54:17 PDT Comment hidden (obsolete)
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 383 Igor Levicki 2010-10-13 11:35:32 PDT Comment hidden (obsolete)
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 386 Dão Gottwald [:dao] 2010-11-03 14:08:34 PDT Comment hidden (obsolete)
Comment 387 Matthias Versen [:Matti] 2010-11-03 15:03:03 PDT Comment hidden (obsolete)
Comment 388 Alice0775 White 2010-11-25 11:29:27 PST Comment hidden (obsolete)
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 393 Mardeg 2010-12-03 07:36:17 PST Comment hidden (obsolete)
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 395 Dão Gottwald [:dao] 2010-12-17 05:31:54 PST Comment hidden (obsolete)
Comment 396 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-09 06:52:17 PST Comment hidden (obsolete)
Comment 397 Benjamin Smedberg [:bsmedberg] 2011-01-10 06:48:15 PST Comment hidden (obsolete)
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 399 Travis G 2011-01-14 16:07:38 PST Comment hidden (obsolete)
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 David [: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 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] - (ni? me) 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.
Comment 500 W 2011-06-03 09:53:28 PDT
Alexander Rødseth, your patch is good for Youtube flash and other simple flashes.
But there are flashes, which it can't fix.http://vkontakte.ru/video-7378435_157142315
And if switch between browser windows and other window by keyboard (Alt+Tab), I saw problems with focus too.
Comment 501 Thomas Ahlblom 2011-06-06 12:27:24 PDT
*** Bug 662333 has been marked as a duplicate of this bug. ***
Comment 502 sharmilee 2011-06-13 00:03:54 PDT
test
Comment 503 Christoph Schulz 2011-06-13 00:04:35 PDT
I see that this is a major discussion since there is no easy resolution of the problem in terms of global compatibility. However, I would kindly request the Mozilla Developers to implement an easy solution for people like me: In all my years of internet consume I have never ever used a single keyboard shortcut provided by a plugin. Now maybe I am an extreme exception since I never play flash games, rarely watch youtube and co, always open my PDFs externally because I dont like them to be stuck in the browser and so on. But still on a large amount of pages I cannot use any of my favourite shortcuts (with Flashblock providing only a minor relief). Thus a simple config option allowing me to disable all plugin-provided keyboard-hits would be a great relief for me and maybe for others, too. I know this is by far not a sophisticated solution as proposed above, but as radical as it may seem, it would make my internet experience much more comfortable.
Comment 504 W 2011-06-13 00:22:53 PDT
The problem is this variant is not easier to implement.
Comment 505 harald.dunkel 2011-06-16 01:31:00 PDT
This sucker is in for 10 years now. Congratulations.
Comment 506 W 2011-06-16 03:12:06 PDT
to harald.dunkel@aixigo.de:

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

You can temporery use variants:
1) close tab by Middle Mouse Click
2) close browser by closing all it widows by x icon (Alt+F4 or other other stadard hotkey of your system)
3) click to Location Bar, then all hotkeys will be ungrabbed.
Comment 509 W 2011-06-16 03:49:29 PDT
Also variants:
1) use this hard way ("How to ungrab Firefox hotkeys from Flash players"): https://www.ibm.com/developerworks/opensource/library/os-78414-firefox-flash/?S_TACT=105AGX54&S_CMP=B1218&ca=dnw-950&open&cm_mmc=4481-_-n-_-vrm_newsletter-_-10731_99952&cmibm_em=dm::13623675

2) block all flash with flashblock and watch flash in Midori: http://www.twotoasts.de/index.php?/pages/midori_summary.html
Comment 512 avada 2011-06-16 04:13:35 PDT
(In reply to comment #506)
> to harald.dunkel@aixigo.de:
> 
> Man, it's very bad idea to annoy developers of free software =)
> The bug really hard to fix.
> Only Midori and Internet Explorer don't have this bug, but Midori is alpha,
> and IE is "IE". Opera try to fix it too, but opera's solution is too buggy.

Yeah right... Because protecting the basic browser hotkeys (that no sane flash developer ever used) is just a mountain that cannot be climbed.
Comment 513 harald.dunkel 2011-06-16 05:34:22 PDT
AFAIR this bug report is not restricted to flash. Does a similar problem exist with webm?
Comment 514 avada 2011-06-16 07:43:49 PDT
(In reply to comment #513)
> AFAIR this bug report is not restricted to flash. Does a similar problem
> exist with webm?

Webm has nothing to do with plugins. And html videos work like any other "normal" elements of the page.
Comment 515 :Ms2ger (⌚ UTC+1/+2) 2011-06-19 10:31:25 PDT
*** Bug 665361 has been marked as a duplicate of this bug. ***
Comment 516 Filip Zakrzewski 2011-06-20 12:41:52 PDT
*** Bug 577640 has been marked as a duplicate of this bug. ***
Comment 517 Filip Zakrzewski 2011-06-20 12:44:53 PDT
Hmm, maybe just let ctrl+tab be over any other shortcut (browser could always listening for ctrl+tab -> even if focus is for plug-in)? It should allow us to jump to another site and release focus
Comment 518 smacharia8 2011-06-21 13:26:06 PDT
I have a Dell Inspiron 15r and while flash apps aren't a big issue (clicking outside the app or in a different tab allows scrolling), adobe reader plugin takes scrolling functions, even when the tab reloaded while not focused. This problem exists in all versions, from 3.5 to 7.0a1
Comment 519 Johnny Stenback (:jst, jst@mozilla.com) 2011-06-22 09:20:54 PDT
smacharia8@gmail.com, last I heard that problem was fixed in some of the recent updates to adobe reader. What version are you using?
Comment 520 Jerry Baker 2011-06-22 09:29:15 PDT
I see the same issue with Acrobat Pro loading in a background tab (middle-clicked link) stealing focus from the active tab. I use Acrobat Professional 9.X on Windows 7 x64.
Comment 521 W 2011-07-01 22:53:07 PDT
I have some idea, but I have not enough skills to realize it...
Let's create transparent gtk widget, which covers flash plugin's rectangle (above every plugin's widget).
This widget will handle every single event, which plugin handles before.
This widget will filtrate come keyboard binding, which browser needs.
Other events this widget will resend to plugin's widget and immidiately restore focus, if needed (maybe focus will not grabbed by flash at all in this case, but force restoring after every event will be better).
Comment 522 W 2011-07-01 22:54:36 PDT
*will filtrate some
Comment 523 smacharia8 2011-07-05 00:58:07 PDT
(In reply to comment #519)
> smacharia8@gmail.com, last I heard that problem was fixed in some of the
> recent updates to adobe reader. What version are you using?

I have Adobe Reader and Acrobat X Pro.

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

The touchpad on my system uses Synaptics drivers, and I'm running Windows 7 Pro.
Comment 524 Wayne Mery (:wsmwk, NI for questions) 2011-07-20 09:54:51 PDT
*** Bug 574646 has been marked as a duplicate of this bug. ***
Comment 525 :aceman 2011-08-31 04:02:40 PDT
The stolen focus and scrolling problems are bug 273456.
Comment 526 Jo Hermans 2011-08-31 15:41:10 PDT
*** Bug 683453 has been marked as a duplicate of this bug. ***
Comment 527 Tim (fmdeveloper) 2011-09-03 21:06:31 PDT
*** Bug 444514 has been marked as a duplicate of this bug. ***
Comment 528 graemew@gmail.com 2011-09-12 02:49:33 PDT
In the meantime it would be nice if focus could return to FF when the user clicks on the toolbar/application surround. (If Flash has focus and is maximised, simply moving the mouse to an edge of the screen and clicking would be such an easy way to regain focus.)
Comment 529 graemew@gmail.com 2011-09-12 02:51:47 PDT
PS At the moment focus can only be regained by clicking white space within the web page itself..
Comment 530 Tony Mechelynck [:tonymec] 2011-09-12 07:03:52 PDT
(In reply to graemew@gmail.com from comment #529)
> PS At the moment focus can only be regained by clicking white space within
> the web page itself..

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

Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110911 Firefox/9.0a1 SeaMonkey/2.6a1 ID:20110911003152
Comment 531 graemew@gmail.com 2011-09-12 07:51:00 PDT
No, I mean maximesed, not full screen. I mean that the most convenient way of gaining focus, for me, would be to sweep the mouse upwards and clicking once at the top of the window. Not fiddling around finding whitespace or the address bar. I mean, if we can't manage a way to share focus as IE does for keys such as TAB, ALT+TAB etc at least this would make life a little easier (as if this is a real difficulty, I'm so spoiled..)
Comment 532 u304036 2011-09-12 21:07:31 PDT
Is there a desktop browser that doesn't experience this bug at all?
Comment 533 graemew@gmail.com 2011-09-13 00:41:12 PDT
Internet Explorer doesn't experience this bug at all
Comment 534 Jo Hermans 2011-09-22 11:39:55 PDT
*** Bug 688528 has been marked as a duplicate of this bug. ***
Comment 535 Piyush Soni 2011-09-22 13:14:42 PDT
I think this bug will be fixed when 1 million bugs will be marked duplicate of it.
Comment 536 aksr 2011-10-18 11:59:14 PDT
Will this bug EVER be repaired ?
Comment 537 sphakka 2011-10-27 05:41:05 PDT
Hey, as a workaround, please, give us keyboard addicted ones an über-meta combination to focus back to the browser. f.i., CTRL+META+<configurable>. And you'll also spare a lot of RSI wrist pain to poor mouse dependent ones ;-)

Cheers,

  ^s
Comment 538 Ksec 2011-11-08 19:57:03 PST
I got so used to it that i forgot about it. I definitely think this should be fixed ASAP. It hurt user experience when using Firefox.
Comment 539 hexadecimaal 2011-11-10 01:27:54 PST
(In reply to dave shultz from comment #0)
> From Bugzilla Helper:
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
> BuildID:    2001042508
> 
> When any Shockwave content is loaded in the current active 
> frame/window, you cannot use any of the application keyboard functions 
> such as command -Q or Command-W. Seems like when I did command 
> Q on some movies, the plugin failed and I could no longer use the movie.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. make sure you have the Shockwave plugin installed
> 2. go to the url above.
> 3. play the game for a second 
> 4. using the keyboard commands, try to close the window or quit the 
> browser
> 
> Actual Results:  If I hit command - W, nothing happens. If I hit command - 
> Q, the shockwave movie stops playing and the page has to be reloaded 
> using the navigator bar button.  Even after you click to close the browser 
> window, you still will not be able to use the keyboard command functions
> 
> Expected Results:  The movie should be able to play and the application 
> keyboard commands should not be affected by Shockwave playback.
Comment 540 LAFK 2011-12-19 16:17:24 PST
(In reply to Alexander Rødseth from comment #495)
> Josh Aas, which events should be let through, in order to not break a
> non-trivial number of existing plugin-based applications? It's a fairly
> minimal amount of key press events that are blocked in my Gtk2 patch (and as
> I understand, people want additional keys to go to Firefox, like Ctrl-F4 and
> Alt-D).

Josh,

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

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

Anyway...

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

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

I know when I try to fullscreen during a flash file, I hit F11 and nothing happens AT ALL.  It's like the shortcut didn't even exist.
Comment 543 Josh Aas 2012-01-25 23:34:41 PST
*** Bug 84159 has been marked as a duplicate of this bug. ***
Comment 544 Matthias Versen [:Matti] 2012-02-03 15:47:10 PST
*** Bug 723836 has been marked as a duplicate of this bug. ***
Comment 545 Simona B [:simonab ] 2012-02-09 06:18:48 PST
Adobe Flash Player and Adobe Reader make Firefox shortcut keys unresponsive on: 
Firefox 10.0.1 ESR, Firefox 10.0.1 and Firefox 11 Beta 2, even if the focus is set on the Bookmarks Toolbar, Add-ons Toolbar or Firefox button.

Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 546 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-09 10:42:56 PST
Is bug 725614 a DUPE of this bug?
Comment 547 Chris Lawson (gone) 2012-02-09 11:32:59 PST
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #546)
> Is bug 725614 a DUPE of this bug?

No, although it's a substantially similar situation. See my comment over there.
Comment 548 Mihaela Velimiroviciu (:mihaelav) 2012-03-05 06:38:11 PST
Still reproducible on latest ESR: 
Mozilla/5.0 (Windows NT 6.1; rv:10.0.3) Gecko/20100101 Firefox/10.0.3
Comment 549 mushu5t 2012-03-06 12:47:44 PST
I'm going to get the workaround patch and see if this fixes the problem.  If it does, is there a way to nominate/vote the patch for the next release?
Comment 550 mushu5t 2012-03-06 12:49:53 PST
Nevermind, sorry for the double comment, but this bug seems to cause another problem which it will utilize 100% CPU.  Can someone streamline that fix?
Comment 551 Nicolas Barbulesco 2012-03-13 08:26:01 PDT
(In reply to DK from comment #532)

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

Safari, OmniWeb and especially iCab are quite good at it.
Comment 552 Eric Brown 2012-04-03 15:48:25 PDT
Suggestion. Some shortcut keys should be freed from the application and interpreted by the browser. For example, CTRL+Tab and ALT+F4.
Comment 553 George R. Goffe 2012-04-03 22:26:37 PDT
I'm having similar problems with Nightly, latest update. I update whenever I get the "update is available" popup. Ctrl-tab and ctrl-shift-tab appear to shift focus in a tab where flash-player is active. This was working just a few days ago but is now failing.
Comment 554 Kevin Brosnan [:kbrosnan] 2012-04-11 12:47:32 PDT
*** Bug 744544 has been marked as a duplicate of this bug. ***
Comment 555 Florin Strugariu [:Bebe] 2012-04-23 06:53:32 PDT
I can reproduce this on ESR
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.4) Gecko/20100101 Firefox/10.0.4 and WebGL

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

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

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

Please read whiteboard before commenting about age.
Comment 559 Mark Clements 2012-05-08 03:39:45 PDT
(In reply to Piyush Soni from comment #557)
> On the other hand, if HTML5 becomes really popular, it might replace Flash
> altogether, removing the need of fixing this bug...

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

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

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

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

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

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

This is for everyone from here.
Comment 563 Kshitij Chawla 2012-05-09 07:22:18 PDT
I don't understand the complaints. Firefox keeps getting faster and better with every iteration.

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

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

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

There wasn't clear solution then. There is no clear solution now.
Probably they are working on it - as it's visible on Aurora, and its sometimes working shortcuts.
Comment 569 mlissner@michaeljaylissner.com 2012-05-09 15:04:22 PDT
Seriously, as has been voiced several times already, complaining about this bug and talking about the health of the Firefox project is not helpful and should not happen here.

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

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

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


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

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

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

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

1. plugin opens.
2. until plugin has focus, Firefox checks hotkeys.
3. when plugin has focus, something either messes up or does as it's supposed to and stops the checking of hotkeys in case the plugin needs them.
4. Hotkeys no longer work.
Comment 572 Kshitij Chawla 2012-05-09 18:38:26 PDT
Seems using the pdf.js (PDF viewer) doesn't steal focus from the chrome- the shortcuts work despite the document being in focus.
Hope that helps somehow.
Comment 573 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-09 20:09:53 PDT
(In reply to Kshitij Chawla from comment #572)
> Seems using the pdf.js (PDF viewer) doesn't steal focus from the chrome- the
> shortcuts work despite the document being in focus.
> Hope that helps somehow.

That's because pdf.js is just that, Javascript. It is not a plug-in.
Comment 574 Timwi 2012-05-09 22:27:06 PDT
The way I see it, there are two major problems which are neither acknowledged nor being discussed:

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

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

plugin.pass_keystrokes_to_plugins         boolean default=true
plugin.keystroke_plugin_exclusion_list    string

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

Would a clean patch implementing this be accepted into mainstream?

Oskar
Comment 576 mushu5t 2012-05-11 08:39:06 PDT
That would require implementing an exception list for said plugins, and the additional coding that entails.  However, it could be simplified if it's kept local to the browser and is set via the user.

Or, we could just reroute the keys:
<psuedocode>
On keyboard.keypress
{
   key = plugin.keyboard_input
   If key == firefox.any_system_command then
   firefox.keyboard_input = key
}
This event would check every time a key was pressed/held down and would pass the plugin key input back to firefox through it's own internal keyboard input.
Comment 577 Nicolas Barbulesco 2012-05-28 06:10:30 PDT
As long as Firefox fails to process the key (!) commands — like Ctrl L, Ctrl W — when the plugin has the focus, Firefox must not abandon the focus to the plugin as soon as Firefox loads the requested document. Currently, he does that, and the combination of both of these behaviours give awkward situations.
See bug 759089.
Comment 578 May 2001 2012-06-07 15:00:56 PDT
Knock! Knock!
Comment 579 giepie@itblanket.net 2012-06-07 15:50:48 PDT
Has anyone noted that Firefox 13 resolved these issues?

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

I reckon this thread could be closed?
Comment 580 flamingspinach 2012-06-07 15:54:51 PDT
Firefox 13 has not resolved this problem. Are you posting on the correct bug?
Comment 581 Mark Baldwin 2012-06-07 15:59:06 PDT
I just tested again and verified that this problem definitely still exists in the latest version of Firefox, so I'm guessing giepie may have inadvertently posted to the wrong bug report.
Comment 582 giepie@itblanket.net 2012-06-07 16:03:33 PDT
My problem was more specifically with Adobe Acrobat files open. This is where I first noted my problem seems to have been fixed. I have also tried with Youtube and scrolling works perfectly fine, even when the Youtube Video has focus (ie, after you clicked on pause and play etc)

If this helps at all, my machine is a Acer TravelMater 8572G with Synaptics touch pad. I make use of two-finger scrolling.
Comment 583 Piyush Soni 2012-06-07 16:11:45 PDT
If it is working for you with YouTube, you might want to make sure it is STILL a flash video and not an html5 one, which they have been rolling out for quite some time.
Comment 584 Tamas Hubai (:htamas) 2012-06-07 16:13:07 PDT
Could you please also specify your OS and the versions of the plugins involved? Also, in case of YouTube, are you sure that the video uses flash and not html5?
Comment 585 giepie@itblanket.net 2012-06-07 16:21:39 PDT
Sure!

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

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

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

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

At least there is some sort of progress, seeing that Acrobat is now working fine for me. This was the largest problem to me, since I sometimes have several PDF files open within Firefox.
Comment 586 George R. Goffe 2012-06-07 22:05:51 PDT
Hi,

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

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

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

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

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

In fact, there is probably very little anyone can say on this bug report that will actually be useful, unless they are a Mozilla employee. That includes this comment (apologies in advance for posting it).
Comment 588 giepie@itblanket.net 2012-06-08 00:00:49 PDT
Hi Flamingspinach

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

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

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

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

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

Thanks for everyone's help!

G
Comment 589 :aceman 2012-06-08 03:11:35 PDT
giepie, notice that PDF scrolling in another tab is a completely different issue. See bug 273456 and bug 626813. The last one is even marked as fixed in FF13 so something could really change for you.
Comment 590 giepie@itblanket.net 2012-06-08 05:36:34 PDT
Hmmm, now how did I end up in this thread?

Ace, you're the man!

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

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

PS. it's already partially fixed.
Comment 593 Timwi 2012-06-15 03:17:56 PDT
> PS. it's already partially fixed.

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

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

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

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

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

I would have changed it myself if I had known what to change it to.
Comment 597 Piyush Soni 2012-06-23 11:25:32 PDT
****IMPORTANT (NEW) REGRESSION, NOT RUN OF THE MILL POST **** !!!!!!

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

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

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


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

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

I repeat, Chrome doesn't have this problem by default even with flash 11.3 (protected mode enabled or disabled).
Comment 602 George R. Goffe 2012-06-25 10:48:39 PDT
Giving up on this bug. I'm switching to a different browser.
Comment 603 Filip Zakrzewski 2012-06-25 10:53:07 PDT
Can we please close this bug and open new one?
it's starting to be impossible to find ANYTHING here...
Comment 604 avada 2012-06-25 12:38:04 PDT
(In reply to HaWaN from comment #603)
> Can we please close this bug and open new one?
> it's starting to be impossible to find ANYTHING here...

Why? People at least come to rant here on the eternal bug instead of several other bugs.
Comment 605 Piyush Soni 2012-06-25 13:21:22 PDT
Implement a simple vote up/vote down to comments like every other website does these days. That will drive useless comments down and solve that problem at least.
Comment 606 Wouter van Wijk 2012-07-01 15:02:36 PDT
It's not a Flash-bug, because it also happens in Adobe Reader. It's not a Flash-bug because it doesn't happen in Chrome. 

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

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

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

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

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

What you mean is that mozilla hasn't made anything about it meanwhile ?
Have you tried yourself version 5 before commenting ?
If not, i feel sorry for your poor comment.
Comment 613 Piyush Soni 2012-07-09 11:53:33 PDT
(In reply to Rubino from comment #612)
> 
> What you mean is that mozilla hasn't made anything about it meanwhile ?
> Have you tried yourself version 5 before commenting ?
> If not, i feel sorry for your poor comment.

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

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

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

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

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

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

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

OS: Win7
Hardware: Vaio VGN-NS11M
Firefox addons: disabled one by one while testing
Comment 616 Hiro 2012-07-24 19:26:36 PDT
(In reply to Hiro from comment #615)
> embed but getting same results on Firefox only.

The other browsers I use:

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

I'm surprised pdf works fine on Seamonkey.
Comment 617 Nicolas Barbulesco 2012-07-25 05:05:42 PDT
(In reply to Hiro from comment #615)

On my good old Firefox 3.6.23, this works. Regression?
Comment 618 Roman 2012-07-26 04:30:12 PDT
Adobe has an entry for this: https://bugbase.adobe.com/index.cfm?event=bug&id=2944796

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

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

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

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

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

Currently some plugins, such as Acrobat Reader, will exit the plugin when ctrl-F4 is used, but one still needs to click outside the tab or window to get keyboard control back.
Comment 622 Piyush Soni 2012-08-29 15:28:41 PDT
*** IMPORTANT UPDATE***

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

Firefox STILL cannot do that.
Comment 623 Nicolas Barbulesco 2012-09-03 05:08:01 PDT
(In reply to bugzilla from comment #621)

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

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

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

And Ctrl L / Apple L too.

(In reply to Piyush Soni from comment #622)

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

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

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


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

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

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

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

 KEYPRESS -> OS -> PLUGIN

and not

 KEYPRESS -> OS -> FIREFOX -> PLUGIN

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

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

 KEYPRESS -> OS -> PLUGIN -> FIREFOX

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

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

KEYPRESS -> OS -> FIREFOX's invisible window -> PLUGIN
Comment 630 LAFK 2012-09-05 06:29:32 PDT
Mozilla took different approach to Chrome - Chrome decided to take back keyboard, FF doesn't want to harm Flash plug-ins that might be using it. That is also why Roth's patch was rejected.

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

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

PS. A bit of irony: under the window I'm writing this in, there's "Status: NEW". :-)
Comment 631 Mark Clements 2012-09-05 11:28:23 PDT
I was not aware that this was idealogical issue.  I thought it was purely technical!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


4) Most important. What can help?

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

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

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

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

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

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

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

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


P.S. I shall be bold now and update the whiteboard to point to this comment. The point of this post is to compensate for Bugzilla's lack of a comment voting feature, making the above comments get lost in the noise, and since comment 403 has been repeatedly called "outdated".
Comment 639 svin83 2012-09-07 06:39:32 PDT
Hvis is where I un-cc. This is spamming my mail, and not a damn thing is beeing done. Firefox has grown slow and unresponsive, and I've gone to Chrome too. Byebye.
Comment 640 svin83 2012-09-07 06:40:30 PDT
Hvis is where I un-cc. This is spamming my mail, and not a damn thing is beeing done. Firefox has grown slow and unresponsive, and I've gone to Chrome too. Byebye.
Comment 641 Julian Reschke 2012-09-07 06:51:09 PDT
But thanks indeed for spamming the bug.
Comment 642 Timwi 2012-09-08 03:58:20 PDT
> I did NOT CC myself to this bug so that I could hear people complain about
> it constantly.
Actually I think I’m rather enjoying it :) I love Firefox, no other browser has such an entertaining crowd of frustrated users bashing it in a woefully inadequate bugtracker :)
Comment 643 Alexander Rødseth 2012-09-09 23:33:01 PDT
Roman, comment #385 is not an "other linux-only work-around" compared to comment #487, but the very same.
Comment 644 Simona B [:simonab ] 2012-10-03 05:03:36 PDT
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

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

Please let me know if I should open a new bug for this.
Comment 645 W 2012-10-09 14:28:26 PDT
(In reply to Sduibek from comment #532)
> Is there a desktop browser that doesn't experience this bug at all?

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

This patch do nothing with flash on many sites, but works on youtube. I tested it already.
Comment 647 Mardeg 2012-10-15 14:50:33 PDT
*** Bug 801880 has been marked as a duplicate of this bug. ***
Comment 648 Manuela Muntean [Away] 2012-12-05 03:05:47 PST
*** Bug 811225 has been marked as a duplicate of this bug. ***
Comment 649 Simona B [:simonab ] 2012-12-11 07:31:04 PST
*** Bug 819566 has been marked as a duplicate of this bug. ***
Comment 650 flamingspinach 2013-02-05 13:18:20 PST
This ticket was just set to priority P3. According to https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation for enhancements. Does that mean that this issue is considered an enhancement request rather than a bug report?
Comment 651 Tony Mechelynck [:tonymec] 2013-02-05 23:21:31 PST
(In reply to flamingspinach from comment #650)
> This ticket was just set to priority P3. According to
> https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation
> for enhancements. Does that mean that this issue is considered an
> enhancement request rather than a bug report?

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

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

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
Comment 653 Kevin Brosnan [:kbrosnan] 2013-04-29 16:11:11 PDT
*** Bug 744544 has been marked as a duplicate of this bug. ***
Comment 654 Paul Silaghi, QA [:pauly] 2013-05-30 07:17:36 PDT
*** Bug 626186 has been marked as a duplicate of this bug. ***
Comment 655 Kevin Brosnan 2013-10-27 23:50:30 PDT
*** Bug 931686 has been marked as a duplicate of this bug. ***
Comment 656 Sergio Lopez 2013-11-05 02:22:44 PST
Created attachment 827318 [details] [diff] [review]
PoC patch for both winless and windowed plugins. (Windows)

This proposal is a sensible workaround (as a "complete" solution would
require the collaboration of every single plugin developer, which
doesn't seem feasible) for Windows. Is my understanding that OSX is
not affected, and a solution already exists for GNU/Linux, please
correct me if I'm wrong.

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

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

See comment #656.
Comment 658 Dave Garrett 2013-11-16 09:59:34 PST
*** Bug 939422 has been marked as a duplicate of this bug. ***
Comment 659 Benjamin Smedberg [:bsmedberg] 2013-11-19 08:48:57 PST
"The second passes all key events to both the plugin and the DOM, except for the ones which generates movement events (arrow keys, space, pageup/pagedown...)." What does this mean precisely? In Windowless mode, plugins are supposed to return true/false whether they handled any particular keystroke, and we should only propagate the keystroke if the plugin didn't handle it. This works on Mac, IIRC: does it not work on Windows (at least for the popular plugins)? We can't have arrow keys that move the page around and also do things within the plugin like text navigation or gaming commands.

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

jmathies will be the eventual reviewer for this, but I think we should probably break it apart into the windowless and windowed-mode patches, which are pretty different.
Comment 660 Liz Henry (:lizzard) (needinfo? me) 2013-11-19 13:13:06 PST
*** Bug 938309 has been marked as a duplicate of this bug. ***
Comment 661 sjw 2013-11-21 08:47:21 PST
*** Bug 936902 has been marked as a duplicate of this bug. ***
Comment 662 Josh Matthews [:jdm] 2013-12-03 09:26:06 PST
Sergio, will you be able to address comment 659?
Comment 663 Sergio Lopez 2013-12-09 03:42:57 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #659)
> "The second passes all key events to both the plugin and the DOM, except for
> the ones which generates movement events (arrow keys, space,
> pageup/pagedown...)." What does this mean precisely? In Windowless mode,
> plugins are supposed to return true/false whether they handled any
> particular keystroke, and we should only propagate the keystroke if the
> plugin didn't handle it. This works on Mac, IIRC: does it not work on
> Windows (at least for the popular plugins)? We can't have arrow keys that
> move the page around and also do things within the plugin like text
> navigation or gaming commands.

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

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

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

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

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

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

I'm OK with this.
Comment 664 Benjamin Smedberg [:bsmedberg] 2013-12-09 05:38:12 PST
> This patch, instead of killing all events going to the plugin, only kills
> the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT,
> SPACE...). I don't know about Mac, but on Windows, Java applets (or, at
> least, the ones I've tested) doesn't properly return the event feedback to
> the browser.

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

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

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

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

Flash is typically a single subwindow. Acrobat is a whole hierarchy of subwindows, and we only hook keystrokes for the toplevel window. That's why I was asking about it.
Comment 665 Alice0775 White 2014-02-17 19:01:07 PST
*** Bug 973760 has been marked as a duplicate of this bug. ***
Comment 666 Dão Gottwald [:dao] 2014-06-24 02:42:36 PDT
*** Bug 1029444 has been marked as a duplicate of this bug. ***
Comment 667 Matthias Versen [:Matti] 2014-10-02 16:54:00 PDT
*** Bug 1077155 has been marked as a duplicate of this bug. ***
Comment 668 Byron Jones ‹:glob› [PTO until 2016-10-10] 2014-12-16 00:00:58 PST
*** Bug 1111982 has been marked as a duplicate of this bug. ***
Comment 669 Jet Villegas (:jet) 2015-05-10 21:38:58 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #664)
> The Firefox frontend should be in charge of this: perhaps the best option is
> to have an API that the Firefox frontend can call "set browser shortcut
> keys" and then the Firefox frontend can collect the keys that matter from
> the <command> elements in the Firefox chrome.

This sounds like a fine approach. Would it be acceptable to intercept all the keys that fit this category?
Comment 670 Kevin Brosnan [:kbrosnan] 2015-05-17 08:30:29 PDT
*** Bug 1164860 has been marked as a duplicate of this bug. ***
Comment 671 Benjamin Smedberg [:bsmedberg] 2015-05-20 06:48:30 PDT
I suspect not: Control-C/V/X at least still need to go to the plugin.
Comment 672 Gingerbread Man 2015-07-06 22:07:12 PDT
*** Bug 1174902 has been marked as a duplicate of this bug. ***
Comment 673 Dirkjan Ochtman (:djc) 2015-09-04 10:42:18 PDT