625808 - Keyboard command enhancement: safe click zones (workaround for Bug 78414)

Status: RESOLVED INCOMPLETE

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

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. Click the tab above the page.
3. Hit a keyboard shortcut such as Ctrl-Tab.
Actual Results:  
The keyboard shortcut is stolen by the plug-in.

Expected Results:  
The plug-in should have lost focus and the keyboard shortdut should be handled by Firefox.

Comment 1

[mr]

When a website with a plug-in is initially displayed, the plug-in does not have focus. When the user clicks it, it gets focus. When the user clicks beside it, it loses focus.

Questions to developers:

Q1:
Are there any specifications or design rules or users that demand that a plug-in should stay in focus when the user clicks a tab?

Q2:
Are there any technical difficulties in removing the focus from a plug-in when the user clicks a tab?


If the above is neither specified nor technically difficult, this workaround should definitely be implemented as soon as possible, at the latest in Firefox 4. I expect it to be really simple, and it would make Firefox behave much better by removing a completely unnecessary annoyance. Please give it priority.

Comment 2

[Roman]

There's a lot more on this in bug 491178, which I think this is a dupe of. It would be cool if everyone interested in this one vote for 491178.

Comment 3

[mr]

I do not agree that it is a duplicate. This workaround is about removing focus from a plug-in on a page, just like the plug-in didn't have focus from the start. Bug 491178 deals with the ability to focus the tab bar, which is still possible (click address field, then press Tab) and seems to solve this issue as well, BUT focus is actually not removed from the plug-in on webpage level. I made a simple case to demonstrate, try it:

1. have multiple tabs open
2. go to a youtube video page
3. click the video to give plug-in focus

(now all keyboard commands such as ctrl-tab will be stolen by the plug-in)

4. click the address field *
5. press Tab

(now the tab bar has focus)

6. go to another tab by pressing right arrow or Ctrl-Tab or Ctrl-PgDn
7. click on the page to give it focus, like in a normal usecase
8. return to the youtube tab by pressing Shift-Ctrl-Tab or Ctrl-PgUp

Now the plug-in has focus (again/still)! 

On the webpage level, the plug-in kept its focus, just like it does when its tab is not shown. Then, when its tab became the active one again, the plug-in got the focus and all keyboard input. So solving bug 491178 does not solve this. They could be combined though, if the old tab-focus behaviour is desired. If not, this workaround should be implemented on its own.

* Btw, the address field is not available when in full-screen mode. And it's not possible to exit full-screen when a plug-in has focus and steals F11, so it's actually not always possible to give focus to the tab bar! This is another reason to implement this workaround regardless of bug 491178. Moreover, that bug has had no activity since 2010-03-12.

Comment 4

[mr]

Sorry about the double post, but I must clarify a bit: When writing the initial bug report, I did not expect the plug-in to be able to regain focus (or to keep in-page focus) like it does as described in steps 1-8 in my comment 3. 

Therefore this workaround and bug 491178 may look similar, but bug 491178 requests that clicking on the tab focuses the tab - probably leaving the webpage's focus order untouched - and what I am requesting here is that clicking on a tab removes the _focus within the webpage_ from the plug-in just like it would do by clicking just outside the plug-in area of a webpage with a non-fullpage plug-in. 
(The tab could then also take the focus from the page, if that is desired.)

Comment 5

[mr]

This behaviour is still here in Firefox 4.
The users still get stuck in plug-in objects.
I repeat my questions to developers:

Q1:
Are there any specifications or design rules or users that demand that a
plug-in should stay in focus when the user clicks a tab?

Q2:
Are there any technical difficulties in removing the focus from a plug-in when
the user clicks a tab?

If the above is neither specified nor technically difficult, this workaround
should definitely be implemented as soon as possible, at the latest in Firefox
4. (sic) I expect it to be really simple, and it would make Firefox behave much
better by removing a completely unnecessary annoyance. Please give it priority.

Comment 6

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.