Closed Bug 625806 Opened 10 years ago Closed 4 years ago

Don't focus on plug-in objects after tab or window loses and regains focus

Categories

(Core :: Plug-ins, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mr, Unassigned)

Details

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

Please include this enhancement in Firefox 4.


Reproducible: Always

Steps to Reproduce:
1. In one of many tabs, load a Youtube page and click Play to give the plug-in focus.
2. Click another tab.
3. Cycle between tabs with Ctrl-Tab.
Actual Results:  
The plug-in still has focus when its tab is shown. Ctrl-Tab is then stolen by the plug-in.

Expected Results:  
Normal Ctrl-Tab tab cycling functionality. The plug-in should not still have focus.
*Addition, covering more similar cases*

When a Firefox window regains focus after some other window had focus, never give back focus to a plugin object.
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 previously focused plug-in should be in focus again after having its tab or window out of focus?

Q2a:
Are there any technical difficulties in preventing a plug-in from having focus when its tab gets re-shown?

Q2b:
Are there any technical difficulties in preventing a plug-in from having focus when its window regains focus?


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.
A workaround is where you work around a bug without code e.g. enabling browser.tabs.ctrlTabPreviews (or whatever it was).
Summary: Keyboard command enhancement: keep tab navigation (workaround for Bug 78414) → Don't pass Ctrl+Tab to plugins
Sounds like a narrow definition. The important part is to do something.


[Btw, Merriam-Webster definition of WORK-AROUND:

"a plan or method to circumvent a problem (as in computer software) without eliminating it"

Wiktionary definition of workaround:

"1. A means of overcoming some obstacle, especially an obstacle consisting of laws, regulations, or constraints.
 2. (computing) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a better solution can be provided; a kluge.
 3. (project management) An impromptu and temporary response to an unforeseen problem or risk." ]
I'm not religious, but I PRAY this gets fixed before Bug 78414 does. Heck, I'll even write the code myself if nobody else does.  Someone already made a workaround for that bug using Greasemonkey, for goodness sake.

(Voting and adding myself to CC list)

Also, perhaps a better title for this bug would be "Don't focus on plugin objects after tab or window loses and regains focus" since the CTRL+TAB part isn't actually a key part of the problem.
(In reply to comment #5)
> I'm not religious, but I PRAY this gets fixed before Bug 78414 does. Heck, I'll
> even write the code myself if nobody else does.  Someone already made a
> workaround for that bug using Greasemonkey, for goodness sake.

As any non-religious person knows, praying has no effect whatsoever. Nobody else wrote this for years. Please write it yourself if you can; what this bug needs is a patch.
Well, I had a feeling someone was going to shoot me down for saying that, but I think I made my point - that Firefox users deserve closure on this.

So, here we go.  I have never contributed to a Mozilla project before but I've gone to ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.6.14/source/ and downloaded the source.  If someone could point me to the part that handles switching tabs, that would be very useful.
(In reply to comment #5)
> Also, perhaps a better title for this bug would be "Don't focus on plugin
> objects after tab or window loses and regains focus" since the CTRL+TAB part
> isn't actually a key part of the problem.

Very good suggestion, I fully agree.
Summary: Don't pass Ctrl+Tab to plugins → Don't focus on plug-in objects after tab or window loses and regains focus
So hacking Mozilla, aren't we? 

https://wiki.mozilla.org/Modules/All#Plugins

https://developer.mozilla.org/en/An_introduction_to_hacking_Mozilla
https://developer.mozilla.org/En/Developer_Guide

Also, I recommend using the live source code, directly from mercurial: http://hg.mozilla.org/mozilla-central/file/4e771e65764a/modules/plugin/base/src

Setting up a build environment is a bit tricky (at least a few years ago it wasn't that straightforward as I thought it could've been), but (since then) Dev.Moz.org has been Shepherded into its current great shape, so it good luck and have fun. :)
It's Firefox 4, and this behaviour seems unchanged. The users still get stuck in plug-in objects, even in places where they shouldn't have to.
I repeat my questions to developers:

Q1:
Are there any specifications or design rules or users that demand that a
previously focused plug-in should be in focus again after having its tab or
window out of focus?

Q2a:
Are there any technical difficulties in preventing a plug-in from having focus
when its tab gets re-shown?

Q2b:
Are there any technical difficulties in preventing a plug-in from having focus
when its window regains focus?

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.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.