625809 - Keyboard command enhancement: reclaim Firefox functionality (workaround for Bug 78414)

Status: RESOLVED DUPLICATE of bug 78414

(Core Graveyard :: Plug-ins, enhancement)

Description

[mr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 (.NET CLR 3.5.30729)

[ 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" ]

Bug 78414 (Importance: major) was reported on 2001-05-01 and has not yet been solved - and it's not planned for Firefox 4 either. During the years its severity has grown along the ever broader use of flash and other plugins. Simply put, it makes Firefox a bad product. Since key handling inside/outside plugin objects is a delicate matter, people could discuss the theoretically best solution forever - instead of changing the behaviour to something better.

Here is a workaround for one of the most annoying results of the bug:

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!

Please include this enhancement in Firefox 4.


Reproducible: Always

Steps to Reproduce:
1. Load a Youtube page and click Play to give the plug-in focus.
2. Hit a keyboard shortcut such as F11, Ctrl-T, Ctrl-W, Ctrl-Tab, Ctrl-Shift-Tab, Ctrl-PgUp, or Ctrl-PgDn.
Actual Results:  
The plug-in steals the keyboard shortcut.

Expected Results:  
The shortcuts F11, Ctrl-T, Ctrl-W, Ctrl-Tab, Ctrl-Shift-Tab, Ctrl-PgUp, and Ctrl-PgDn should always be handled by Firefox until bug reports are filed.

Comment 1

[Mardeg]

Rather than a "workaround" request I see this as a duplicate of bug 78414

Comment 2

[mr]

It is not a duplicate, since
1) it only suggests *some* of the shortcuts in bug 78414 to be reclaimed
2) it gives serious problems to any plug-ins that might need those shortcuts.

It is a try to find a more useful resting point between two conflicting needs. The 9½ years old bug 78414 doesn't seem to ever reach a solution, and meanwhile we are stuck in an unwanted compromise. The enhancement request describes another compromise to the problem, and I'm quite sure almost everyone would find it much more comfortable then the current compromise.

Q1:
Can anybody find any plug-in that needs the shortcuts 
F11, Ctrl-T, Ctrl-W, Ctrl-Tab, Ctrl-Shift-Tab, Ctrl-PgUp, or Ctrl-PgDn?

Q2:
Can anybody find any user that does not want the shortcuts 
F11, Ctrl-T, Ctrl-W, Ctrl-Tab, Ctrl-Shift-Tab, Ctrl-PgUp, or Ctrl-PgDn
be handled by Firefox at all times?

Unless any can be found, nearly a billion(!) Firefox users have a bad user experience without any reason whatsoever. If some are found, their loss should be compared to the needs of the near-billion users.

Comment 3

[Roman]

I thought, as per bug 78414 comment 185 (https://bugzilla.mozilla.org/show_bug.cgi?id=78414#c185) the problem is not about _what_ to do, but _how_ to do it. The way I read that comment is that the browser never sees the keys. The plugin window is focused. It gets all input bypassing the browser. With the current NPAPI the browser cannot prevent this and thus cannot filter the keys. Hence, an updated API is required, along with updated plugins.

I am not entirely sure I'm reading the comment correctly though.

Comment 4

[Mardeg]

(In reply to comment #3)
> I thought, as per bug 78414 comment 185
> (https://bugzilla.mozilla.org/show_bug.cgi?id=78414#c185) the problem is not
> about _what_ to do, but _how_ to do it. The way I read that comment is that the
> browser never sees the keys. The plugin window is focused. It gets all input
> bypassing the browser. With the current NPAPI the browser cannot prevent this
> and thus cannot filter the keys. Hence, an updated API is required, along with
> updated plugins.
> 
> I am not entirely sure I'm reading the comment correctly though.

That seems about right, and if it is that means changing the NPAPI which is not a workaround (I'd like to be proven wrong about this so I'll leave the outcome of this bug for others to determine) and would be dependant on either bug 78414 being fixed first, or every plugin being rewritten by their authors. Either way this definitely won't happen before Firefox 4 is released as the description of this bug wants. 

A workaround for an existing bug would be something done externally regardless of what happens to the core code, like an extension, gm script, etc. which would also be fine to request, but again, that's not what this bug is requesting.
The dismissive statement about bug 78414 is also disrespecting every other bug that was duped to it, as many of them are narrower in scope. The wording is more appropriate for a forum discussion instead of a filed bug.

Since the linked comment was made, plugin handling has been rewritten to run in a separate process, and the focus code was completely refactored in bug 178324. Whether these caused more delay to a fix I can't say, but work is already under way to separate the UI and content into separate processes too. Hopefully that won't mean more delays.

Comment 5

[Mardeg]

Looks like someone posted such a workaround patch in the original bug 78414.