Last Comment Bug 273456 - Plugins (mainly PDF/Java) steal shortcut keys/focus/mouse events when tab is out of focus (inactive).
: Plugins (mainly PDF/Java) steal shortcut keys/focus/mouse events when tab is ...
Status: RESOLVED FIXED
: common-issue?, testcase
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Windows 7
: -- major with 22 votes (vote)
: mozilla9
Assigned To: Tim Abraldes [:TimAbraldes] [:tabraldes]
:
Mentors:
: 272849 288002 296594 315513 541368 543027 564716 594398 601344 607848 617758 619032 627275 641299 643835 648713 650510 652347 654584 655948 661516 665363 687377 (view as bug list)
Depends on: PluginShortcuts
Blocks: 601889 709996 315513 594500
  Show dependency treegraph
 
Reported: 2004-12-06 16:14 PST by M. LaPlante
Modified: 2012-02-01 13:52 PST (History)
70 users (show)
benjamin: blocking1.8b3-
benjamin: blocking‑aviary1.5-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (362 bytes, text/html)
2005-06-04 07:23 PDT, José Jeria
no flags Details
wheel scroll test case (1.71 KB, text/html)
2011-08-19 10:19 PDT, Jim Mathies [:jimm]
no flags Details
Pointing to a different pdf. (1.40 KB, text/html)
2011-08-24 15:18 PDT, Tim Abraldes [:TimAbraldes] [:tabraldes]
no flags Details
Proof of concept patch (Note: plugin cannot be activated) (5.59 KB, patch)
2011-08-24 15:48 PDT, Tim Abraldes [:TimAbraldes] [:tabraldes]
no flags Details | Diff | Splinter Review
Patch v2 - Absolute minimal patch that fixes the issue. Plugins now activate when their tabs are switched to (1.64 KB, patch)
2011-08-30 13:44 PDT, Tim Abraldes [:TimAbraldes] [:tabraldes]
no flags Details | Diff | Splinter Review
Patch v3 - Comments added (2.10 KB, patch)
2011-08-31 09:09 PDT, Tim Abraldes [:TimAbraldes] [:tabraldes]
jmathies: review+
Details | Diff | Splinter Review
Patch v4 - Integrated review comments (2.07 KB, patch)
2011-08-31 11:50 PDT, Tim Abraldes [:TimAbraldes] [:tabraldes]
timabraldes: review+
Details | Diff | Splinter Review

Description M. LaPlante 2004-12-06 16:14:16 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This problem has been bugging me for awhile now and it always seems to crop up
when I have a pdf file open in one of my FireFox tabs.  It seems to be an issue
of FireFox misdirecting keyboard shortcuts to the wrong tabs.  If I have a PDF
file open in one browser tab, and attempt to Ctrl+T to open a new tab, much of
the time I'm presented with an acrobat dialog, rather than a new FireFox tab. 
When an adobe PDF is in focus, ctrl+T brings up the "Summarize Options" dialog.
 Unfortunately, it also appears many times when I'm on an entirely different tab
than the pdf file.  Usually manually changing to another tab will allow me to
ctrl+t a new tab, but its a great annoyance to have to do so.

Reproducible: Sometimes
Steps to Reproduce:
Comment 1 Bill Mason 2004-12-06 16:20:06 PST

*** This bug has been marked as a duplicate of 78414 ***
Comment 2 M. LaPlante 2004-12-06 16:26:35 PST
I just read Bug #78414.  That bug and this one are two separate issues.  That
bug complains that shortcut keys do not function while a specific application
has focus (such as acrobat or flash).  My complaint is almost the opposite;
shortcut keys failing when the entire tab (and the application at fault) is
*out* of focus.
Comment 3 José Jeria 2004-12-07 01:01:01 PST
(In reply to comment #2)
> My complaint is almost the opposite;
> shortcut keys failing when the entire tab (and the application at fault) is
> *out* of focus.

So you mean that shortcut keys fail when Firefox has no focus? I must have
misunderstood you... To me this looks like a dupe as well.
Comment 4 M. LaPlante 2004-12-11 07:10:17 PST
(In reply to comment #3)
> (In reply to comment #2)
> > My complaint is almost the opposite;
> > shortcut keys failing when the entire tab (and the application at fault) is
> > *out* of focus.
> 
> So you mean that shortcut keys fail when Firefox has no focus? I must have
> misunderstood you... To me this looks like a dupe as well.

Not when firefox is out of focus, when the Adobe tab is out of focus.  For example:
Tab 1 - ebay.com
Tab 2 - Adobe PDF
Tab 3 - mozilla.org
Now if I'm viewing tab 3, mozilla.org, and I click ctrl+t, I'll get a dialog
from adobe reader.  Firefox is in focus, but the tab running adobe is not. This
example was just for illustration...I have not found an exact pattern to the
number of tabs/position of tabs that causes this.  It doesn't always occur, but
does frequently enough to be very annoying.  Usually changing to a different tab
(also non-adobe) will allow me to ctrl+t.
Comment 5 Jon B 2005-03-11 09:26:45 PST
I also get this problem, and it annoys me to no end.  To reproduce:

1. Open a web pdf from somewhere
2. Open a few other sites in tabs
3. Do something in one of those non-PDF tabs to make sure Firefox's internal
focus is on them.
4. Go to another program on your computer that is not Firefox
5. Click in the non-pdf tab that you had opened once to return application focus
to Firefox
6. Press ctrl+T 

It will behave as if the pdf tab was focused within firefox and pop up an
acrobat dialog, even though you are looking at a regular tab.  You have to
select some text on the page you are looking at to return firefox's focus to
that tab.

I also notice a similar effect on wikipedia, when I try to use alt+s to save,
and I have switched to a new tab without highlighting any text in the new tab,
it behaves as if the alt+s was for the last tab I had opened.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > My complaint is almost the opposite;
> > > shortcut keys failing when the entire tab (and the application at fault) is
> > > *out* of focus.
> > 
> > So you mean that shortcut keys fail when Firefox has no focus? I must have
> > misunderstood you... To me this looks like a dupe as well.
> 
> Not when firefox is out of focus, when the Adobe tab is out of focus.  For
example:
> Tab 1 - ebay.com
> Tab 2 - Adobe PDF
> Tab 3 - mozilla.org
> Now if I'm viewing tab 3, mozilla.org, and I click ctrl+t, I'll get a dialog
> from adobe reader.  Firefox is in focus, but the tab running adobe is not. This
> example was just for illustration...I have not found an exact pattern to the
> number of tabs/position of tabs that causes this.  It doesn't always occur, but
> does frequently enough to be very annoying.  Usually changing to a different tab
> (also non-adobe) will allow me to ctrl+t.

Comment 6 Jon B 2005-03-11 09:28:02 PST
My example is in WinXP

(In reply to comment #5)
> I also get this problem, and it annoys me to no end.  To reproduce:
> 
> 1. Open a web pdf from somewhere
> 2. Open a few other sites in tabs
> 3. Do something in one of those non-PDF tabs to make sure Firefox's internal
> focus is on them.
> 4. Go to another program on your computer that is not Firefox
> 5. Click in the non-pdf tab that you had opened once to return application focus
> to Firefox
> 6. Press ctrl+T 
> 
> It will behave as if the pdf tab was focused within firefox and pop up an
> acrobat dialog, even though you are looking at a regular tab.  You have to
> select some text on the page you are looking at to return firefox's focus to
> that tab.
> 
> I also notice a similar effect on wikipedia, when I try to use alt+s to save,
> and I have switched to a new tab without highlighting any text in the new tab,
> it behaves as if the alt+s was for the last tab I had opened.
> 
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > My complaint is almost the opposite;
> > > > shortcut keys failing when the entire tab (and the application at fault) is
> > > > *out* of focus.
> > > 
> > > So you mean that shortcut keys fail when Firefox has no focus? I must have
> > > misunderstood you... To me this looks like a dupe as well.
> > 
> > Not when firefox is out of focus, when the Adobe tab is out of focus.  For
> example:
> > Tab 1 - ebay.com
> > Tab 2 - Adobe PDF
> > Tab 3 - mozilla.org
> > Now if I'm viewing tab 3, mozilla.org, and I click ctrl+t, I'll get a dialog
> > from adobe reader.  Firefox is in focus, but the tab running adobe is not. This
> > example was just for illustration...I have not found an exact pattern to the
> > number of tabs/position of tabs that causes this.  It doesn't always occur, but
> > does frequently enough to be very annoying.  Usually changing to a different tab
> > (also non-adobe) will allow me to ctrl+t.
> 
> 

Comment 7 José Jeria 2005-03-11 10:35:33 PST
(In reply to comment #6)
Please dont add the full text when replying, it makes it difficult to read the
bug, thanks
Comment 8 dw 2005-03-25 14:43:26 PST
OS: Windows XP
Mozilla: Firefox 1.0

I imagine this is another symptom of the same bug:

When I have a PDF file open with multiple other HTML tabs, if I ALT+TAB away to
another Windows application and then back again to Firefox, on typing CTRL+W or
any other Firefox accelerator key, I am presented with a response from Acrobat
despite its tab is not in focus.

For instance:

- Tab 1: any PDF.
- Tab 2 (active): joelonsoftware.com.
- Press ALT-TAB to eg. Notepad, then ALT-TAB back again.
- Press CTRL-W.
- Find yourself presented with an Acrobat error: "this command is not valid in
an external window."
- Acrobat is clearly getting the CTRL-W keypress.

Cheers.
Comment 9 José Jeria 2005-06-04 03:13:11 PDT
*** Bug 296594 has been marked as a duplicate of this bug. ***
Comment 10 José Jeria 2005-06-04 03:18:53 PDT
*** Bug 288002 has been marked as a duplicate of this bug. ***
Comment 11 José Jeria 2005-06-04 07:18:13 PDT
*** Bug 272849 has been marked as a duplicate of this bug. ***
Comment 12 José Jeria 2005-06-04 07:23:47 PDT
Created attachment 185340 [details]
Testcase

Steps to reproduce:

1. Load testcae
2. open new tab that has a input field or a textarea
3. Start typing, when testcase that refreshes every 10 seconds is reloaded,
focus on the new tab will be lost
Comment 13 José Jeria 2005-06-04 09:36:51 PDT
*** Bug 296594 has been marked as a duplicate of this bug. ***
Comment 14 Aaron Slunt 2005-06-04 10:09:40 PDT
Here's something I found in my js console while doing some testing to try to get
pages to steal information from applets:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 687"  data: no]

Gonna see what was causing that.
Comment 15 Jon B 2005-06-04 10:35:27 PDT
(In reply to comment #12)
> Created an attachment (id=185340) [edit]
> Testcase

Does the text input focus change to the testcase page?  Couldn't that be a
security issue?  

I think I've seen behavior like that; where scrolling or text meant for one tab
gets inputted to a different tab instead, but I can't say that with certainty.
Comment 16 Jon B 2005-06-04 16:15:00 PDT
> I think I've seen behavior like that; where scrolling or text meant for one tab
> gets inputted to a different tab instead, but I can't say that with certainty.

Now that I think of it, I have definitely seen accesskey shortcuts "redirected"
to another tab, apparently caused by the other tab loading while I have moved on
to another.
Comment 17 Stewart Gordon 2005-06-06 03:31:49 PDT
At first I thought this was a duplicate of bug 247140, but then realised the
difference that this is Firefox on Windows, and bug 247140 is regular Mozilla on
Mac.  OTOH, the bug doesn't occur in regular Mozilla on Windows.

However, is this related to bug 247140 comment 3?
Comment 18 Jerry Baker 2005-06-22 22:15:33 PDT
Not only do plugins steal shortcut keys, but they steal UI button presses too.
If you load up tabs as outlined in comment #4, put focus in an input field of
the PDF, switch tabs to the Ebay page and press the back button, the tab with
the PDF displaying goes back one page instead of the page displaying in the
current tab (Ebay).
Comment 19 Benjamin Smedberg [:bsmedberg] 2005-06-28 08:48:48 PDT
No fix in sight, not going to block on this.
Comment 20 Adam Guthrie 2005-10-16 22:08:33 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051016
Firefox/1.6a1 ID:2005101619

Works for me. Focus is not stolen from textareas or inputs. Anyone else want to
verify this?
Comment 21 Jon B 2006-01-02 13:22:48 PST
(In reply to comment #20)
> Works for me. Focus is not stolen from textareas or inputs. Anyone else want to
> verify this?

Unfocused tabs stealing accesskeys and textarea input is still a definite problem in FF 1.5.
Comment 22 Jens Martin Schlatter 2006-08-27 00:20:39 PDT
I find this behaviour also without active plugings. For example, right-click->"select all" sometimes selects the text in another tab.
Comment 23 djstealth 2006-09-13 16:12:33 PDT
Still an issue on 1.5.0.6 under Windows XP
(I'm using Acrobat Pro 6.0)

I have 3 tabs open.

Tab1: PDF file
Tab2: Web site
Tab3: Web site

From tab 3, I hit ctrl-t and I get the Acrobat dialog box "Summarize Options". 
If I hit cancel, and control-t again, the adobe dialog box will keep coming up.

Once I click on a web tab once, the problem dissappears.

**** TO REPRODUCE THIS BUG TRY THE FOLLOWING: ****

1) Have both a PDF tab and a web tab open with the web tab being active.
2) Click on another window (put something else as the active window, either another firefox window or another program)
3) Click back on the firefox window just once
4) Hit Control-T; you should now see the adobe "Summarize options" window
Comment 24 Jon B 2006-12-13 07:02:37 PST
For the record, this is still a problem in 2.0 Gecko/20061010.

I worry that this is a security problem.  I haven't thought it through completely, so I don't know if it would really work, but it seems like an evil website could pop-up a real website, like paypal, and then steal focus and grab your password with javascript as you type it into the wrong window.
Comment 25 Jon B 2007-08-31 17:19:06 PDT
Test case no longer works for me in Linux with Firefox 2.0.0.6, but accesskeys are still regularly stolen by unfocused tabs.
Comment 26 Jon B 2007-11-12 17:15:33 PST
This is still broken in 2.0.0.8.  Keep in mind that this is not just limited to plugins; it happens when regular web pages in background tabs finish loading while you are focused on another tab.

Is this a security problem?  See https://www.mozilla.org/security/announce/2005/mfsa2005-05.html for a similar bug that causes a security breach, which lists bug 262887, bug 265055, and bug 265456.
Comment 27 Aaron Slunt 2008-06-28 20:35:14 PDT
WFM Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062219 (Gentoo) Firefox/3.0

Can any windows users verify that this is no longer an issue?
Comment 28 Tobias (:Tobbi) Markus 2008-07-29 12:26:47 PDT
I'm a windows user and the issue appears only if I do the following:
1. Open the PDF file
2. open a settings page e.g. right click in PDF > Document settings
3. Try to open a new tab ---> fails. 

But I think, this bug is also related to Bug 78414

Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

latest Adobe Plugin
Comment 29 Josh H 2010-03-06 20:07:38 PST
I am Windows 7 Professional 64-bit and this bug still appears when opening a PDF in a new tab.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Comment 30 (mostly gone) XtC4UaLL [:xtc4uall] 2010-09-06 02:25:44 PDT
*** Bug 541368 has been marked as a duplicate of this bug. ***
Comment 31 mmortal03 2010-11-23 11:31:01 PST
*** Bug 564716 has been marked as a duplicate of this bug. ***
Comment 32 mmortal03 2010-11-23 11:32:41 PST
*** Bug 607848 has been marked as a duplicate of this bug. ***
Comment 33 (mostly gone) XtC4UaLL [:xtc4uall] 2010-12-09 03:40:17 PST
*** Bug 617758 has been marked as a duplicate of this bug. ***
Comment 34 (mostly gone) XtC4UaLL [:xtc4uall] 2010-12-14 09:27:54 PST
*** Bug 619032 has been marked as a duplicate of this bug. ***
Comment 35 wamsaya 2011-01-19 07:28:06 PST
This bug is still an issue with adobe reader X. Very, very annoying for thoe dealing with pdfs inside the browser!
Comment 36 Ben Lerner 2011-02-05 17:56:21 PST
Confirmed on win7x64, Fx4b10, with the Acrobat 10.0.0.396 plugin.  Any scrolling done while the web tab is open will actually scroll the pdf tab.
Comment 37 wamsaya 2011-02-22 04:16:26 PST
Is there any chance this bug ever gets fixed?
Comment 38 TaylorSwiftRunescape 2011-03-27 18:18:50 PDT
Win7x64, Fx4.0

In my case its the Java plugin. I was logging into Paypal, and the Java window got the keystrokes. Thankfully i was watching the screen, so i only got halfway through typing my email address in.

Clicking anywhere in the non-plugin tab does let you start typing without issues, but its only a matter of time before this issue causes someone major grief.
Comment 39 :aceman 2011-05-02 07:06:59 PDT
*** Bug 315513 has been marked as a duplicate of this bug. ***
Comment 40 :aceman 2011-05-02 07:08:53 PDT
*** Bug 627275 has been marked as a duplicate of this bug. ***
Comment 41 :aceman 2011-05-02 07:13:39 PDT
Can anybody watching this bug confirm that the focus stealing happens only after the PDF tab has finished loading, not before that? As refined in bug 627275.
Comment 42 eyal gruss (eyaler) 2011-05-02 07:40:30 PDT
*** Bug 601344 has been marked as a duplicate of this bug. ***
Comment 43 eyal gruss (eyaler) 2011-05-02 07:41:21 PDT
*** Bug 632889 has been marked as a duplicate of this bug. ***
Comment 44 eyal gruss (eyaler) 2011-05-02 07:41:42 PDT
*** Bug 652347 has been marked as a duplicate of this bug. ***
Comment 45 eyal gruss (eyaler) 2011-05-02 07:42:51 PDT
*** Bug 650510 has been marked as a duplicate of this bug. ***
Comment 46 eyal gruss (eyaler) 2011-05-02 07:44:05 PDT
*** Bug 643835 has been marked as a duplicate of this bug. ***
Comment 47 :aceman 2011-05-02 08:05:50 PDT
Updating summary to make it more discoverable (many dupes). This bug seems Windows only, the dupes range from Windows 2000 to 7. This probably means platform is x86 only.
Comment 48 eyal gruss (eyaler) 2011-05-02 15:10:27 PDT
*** Bug 648713 has been marked as a duplicate of this bug. ***
Comment 49 eyal gruss (eyaler) 2011-05-02 15:14:47 PDT
*** Bug 594398 has been marked as a duplicate of this bug. ***
Comment 50 eyal gruss (eyaler) 2011-05-02 15:15:22 PDT
*** Bug 638671 has been marked as a duplicate of this bug. ***
Comment 51 Tim (fmdeveloper) 2011-05-03 21:08:03 PDT
*** Bug 654584 has been marked as a duplicate of this bug. ***
Comment 52 eyal gruss (eyaler) 2011-05-13 06:53:36 PDT
*** Bug 655948 has been marked as a duplicate of this bug. ***
Comment 53 Paul Herron 2011-05-13 06:57:38 PDT
Any chance of this being fixed? It's one of my few problems with using Firefox.
Comment 54 eyal gruss (eyaler) 2011-05-16 23:37:21 PDT
*** Bug 626813 has been marked as a duplicate of this bug. ***
Comment 55 Worcester12345 2011-05-17 13:26:03 PDT
Isn't there a focus "meta" bug this should be linked to?
Comment 56 :aceman 2011-05-24 06:32:53 PDT
*** Bug 543027 has been marked as a duplicate of this bug. ***
Comment 57 :aceman 2011-05-24 06:40:31 PDT
*** Bug 594500 has been marked as a duplicate of this bug. ***
Comment 58 Ibrahim Jadoon 2011-05-24 13:10:53 PDT
Just to finalize:

543027 = 594500 = 626813

All the above bugs deal with scrolling with a PDF open.

273456 deals with keyboard events with a PDF open. I think these are two different issues!
Comment 59 :aceman 2011-05-24 13:42:19 PDT
This is not only about keyboard focus. See all those duped bugs. It is a general problem of all focus going to the plugin.
Comment 60 Ben Lerner 2011-05-25 10:32:50 PDT
Another focus issue, perhaps, that may be related to out-of-process plugins as well: in my setups (Win7x64, Fx4 or 5, Adobe Reader 9 or X),
* Open a PDF in a tab, and bring that tab to the foreground
* Click on a link within the PDF
* While Adobe Reader is contemplating whether or not to navigate to that link, which can take anywhere from instantly to nearly a minute, try to click on any other tab, or add a new tab, or click on the Firefox button, or in general do *anything* with Firefox.

You will not be able to interact with Firefox at all.  Pretty likely, the Windows titlebar will appear saying "Firefox (not responding)".  You can't even go to the taskbar and ask Windows to open a new Firefox window, because that too goes to the currently running Firefox process, which is utterly engrossed in waiting for Reader to come back to life...

Perhaps something in the interaction between the plugin and Firefox, over the OOPP channel, is causing this hijacking of focus?

If this isn't relevant here, I can file a separate bug, but if it helps to figure out a cause, then I'm glad I commented here :)
Comment 61 Alice0775 White 2011-06-02 09:05:59 PDT
*** Bug 661516 has been marked as a duplicate of this bug. ***
Comment 62 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2011-06-13 00:52:14 PDT
It seems that the mouse wheel problem depends on its driver.

On my touch pad of notebook sends WM_VSCROLL message to the parent of Adobe Reader's scrollbar window. However, my mouse of MS always sends WM_MOUSEWHEEL to focused window.

There is a strange thing. The plugin windows aren't hidden even when it's actually hidden. I'm not sure why we can receive native mouse events correctly. But I guess that some mouse drivers misunderstand this situation as:

1. The topmost window under cursor is plugin window.

Or

2. There is visible scrollbar window on the focused window.

If we hide or disable our plugin window (MozillaWindowClass or GeckoPluginWindow) when it goes to background tab, cannot we fix the mouse wheel issue? I don't know where I should change for confirming it.
Comment 63 Jerry Baker 2011-06-13 06:10:06 PDT
(In reply to comment #62)
> On my touch pad of notebook sends WM_VSCROLL message to the parent of Adobe
> Reader's scrollbar window. However, my mouse of MS always sends
> WM_MOUSEWHEEL to focused window.

My Microsoft mouse does not behave as you describe. Frequently a PDF loading in another tab steals the focus from the current page and the mousewheel and even button clicks no longer work until I switch to the PDF tab and then back.
Comment 64 Mardeg 2011-06-19 10:43:20 PDT
*** Bug 665363 has been marked as a duplicate of this bug. ***
Comment 65 Paul Herron 2011-06-19 10:46:50 PDT
(In reply to comment #63)
> (In reply to comment #62)
> > On my touch pad of notebook sends WM_VSCROLL message to the parent of Adobe
> > Reader's scrollbar window. However, my mouse of MS always sends
> > WM_MOUSEWHEEL to focused window.
> 
> My Microsoft mouse does not behave as you describe. Frequently a PDF loading
> in another tab steals the focus from the current page and the mousewheel and
> even button clicks no longer work until I switch to the PDF tab and then
> back.

Would I be right in saying that this only affects track pads? I don't think I've ever had the problem on a mouse. But it's happened many times on different systems with a trackpad.
Comment 66 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2011-06-19 18:32:33 PDT
(In reply to comment #65)
> (In reply to comment #63)
> > (In reply to comment #62)
> > > On my touch pad of notebook sends WM_VSCROLL message to the parent of Adobe
> > > Reader's scrollbar window. However, my mouse of MS always sends
> > > WM_MOUSEWHEEL to focused window.
> > 
> > My Microsoft mouse does not behave as you describe. Frequently a PDF loading
> > in another tab steals the focus from the current page and the mousewheel and
> > even button clicks no longer work until I switch to the PDF tab and then
> > back.
> 
> Would I be right in saying that this only affects track pads? I don't think
> I've ever had the problem on a mouse. But it's happened many times on
> different systems with a trackpad.

See the first line of my comment :-p
Comment 67 Jerry Baker 2011-06-19 19:14:49 PDT
(In reply to comment #65)
> Would I be right in saying that this only affects track pads? I don't think
> I've ever had the problem on a mouse. But it's happened many times on
> different systems with a trackpad.

I only use a Microsoft wheel mouse.
Comment 68 Luke Pacholski 2011-07-07 19:38:18 PDT
Also an issue here. XP, FF 5, and a track pad, although it has been an issue for quite a while now. Quite annoying.

Interesting that other windows aren't affected, only tabs in the same window as Adobe Reader.
Comment 69 Filip Zakrzewski 2011-07-12 06:21:43 PDT
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110711 Firefox/7.0a2

Reproduced.
I've opened pdf in new tab (middle mouse button).
All focus is gone. I had to use mouse on the page to get it back (scrolled)
Comment 70 Ibrahim Jadoon 2011-07-30 15:32:00 PDT
@ Masayuki and Luke:

This touchpad scrolling issue + PDF. I've been investigating it in a separate bug (bug 626813) for some time now. 

What OS are you testing on and what touchpad are you guys using? 

I have this problem on my Win7 64-bit Dell with a Synaptics Touchpad v7.2 on driver 15.0.24.0. I have narrowed the regression window down to the Nightly's in Firefox 4 Beta:

Last good nightly: 2010-08-27
First bad nightly: 2010-08-28

If anyone can confirm/deny this regression window, that would be great. I used mozregression (very easy tool to use). :)

More information to add to the PDF+touchpad scrolling problem: it does not depend on plugin (Adobe and Nitro exhibit the bug), it seems to only be an issue with individuals on Windows 7 64-bit using a Synaptics touchpad, and Firefox 6/7/8 all exhibit the problem as well.

I should note: I have NO keyboard focusing events whatsoever. This bug 273456 does not affect me; I am unable to reproduce the bug on my system. Thus, I think these may be two separate bugs (626813 and 273456).
Comment 71 Paul Herron 2011-07-30 15:37:48 PDT
It's happening to me with Win7 32-bit, HP with Synaptics Touchpad V6.3, 
driver 15.0.17.4. I seem to remember having this problem before Firefox 4. I can't be 100% sure on that though. Still having it on Firefox 8.
Comment 72 Luke Pacholski 2011-08-16 19:17:59 PDT
(In reply to Ibrahim Jadoon from comment #70)
> @ Masayuki and Luke:
> 
> This touchpad scrolling issue + PDF. I've been investigating it in a
> separate bug (bug 626813) for some time now. 
> 
> What OS are you testing on and what touchpad are you guys using? 

Win XP Media Center Edition Version 2002 SP 3.

Touchpad is showing up in the "Device Settings" tab of the mouse control panel as "Synaptics TouchPad V5.9". Device Manager simply says "Synaptics PS/2 Port TouchPad". Current driver is 10.1.8.0, but I believe I've had the issue regardless of driver.

> I should note: I have NO keyboard focusing events whatsoever. This bug
> 273456 does not affect me; I am unable to reproduce the bug on my system.

That does not appear to affect me either.
Comment 73 mike 2011-08-18 09:45:43 PDT
I've had this problem for over 2 yrs with FF3 up to FF5 (no beta).  When pdf open in a tab (hidden), other visible tabs don't scroll with touchpad. Just discovered that hidden pdf scrolls, though; after reading this thread. cntl-t cntl-w works properly. 

Synaptics PS/2 Port Pointing Device, driver 9.1.18.6 (up to date).
Vista 32 SP2, latest updates, antivirus deactivated.
Comment 74 Jim Mathies [:jimm] 2011-08-19 10:19:06 PDT
Created attachment 554459 [details]
wheel scroll test case
Comment 75 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-19 10:45:52 PDT
I'll start throwing debugger/sysinternals tools at this and see what I come up with
Comment 76 Birken Vogt 2011-08-22 17:20:13 PDT
I've had this problem for some time now but I can't remember if it existed on my old XP system with 3.0 or 3.5 but I think that it did.  It is now with me on Vista 64 and all versions up to now.  I have always used Katmouse as long as the bug has existed.

Steve Gibson referenced it here: https://www.grc.com/sn/sn-314.htm
Comment 77 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-24 10:24:31 PDT
There are a couple issues here that need to be dealt with.

*First issue*:
   When a plugin takes focus, `nsWindow::ProcessMessage` does not respond correctly to the WM_KILLFOCUS message that it receives.

   This is particularly salient if you do the following:
      1) Open a pdf document in the current tab
      2) Use "ctrl+f" to open Reader's (not Firefox's) "find" dialog
      3) Click in Firefox's URL bar a couple of times to get a blinking caret
      4) Click in Reader's "find" dialog
   At this point, you'll see a blinking caret in Reader's "find" dialog AND a blinking caret in Firefox's URL bar.  This is already bad, but it gets worse if you click again in Firefox's URL bar to try to enter some text: The caret moves to your click location, but any keys you enter show up in Reader's "find" dialog.

   When the plugin Window took focus, our main Window's `nsWindow::ProcessMessage` function received a WM_KILLFOCUS message.  The code in `nsWindow::ProcessMessage` assumes that it will only receive WM_KILLFOCUS when the Window is being lowered and thus in conjunction with a WM_ACTIVATE.  Since, in this case, no WM_ACTIVATE is received, `nsWindow::ProcessMessage` effectively ignores the WM_KILLFOCUS, so there is no indication that focus has changed (e.g. the caret continues to blink in the URL bar).

   In the case of loading a pdf in a background tab, the plugin takes focus after loading the pdf document, but nothing changes visually to inform the user that this has happened.  So if, for example, the user was entering text into an edit box in the current tab, it will appear as if the edit box has stopped responding to key presses.

*Second issue*:
   When in a background tab, plugins shouldn't be able to take focus.

   I can only think of malicious reasons for wanting to take focus while in a background tab, but maybe there's a use case for this?

   Ideally we can block plugins from taking focus if they are in background tabs (investigating this).  If that doesn't pan out, we'll have to be reactive: Determine if a plugin in a background tab has taken focus, then take focus back if appropriate.
Comment 78 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-24 15:18:21 PDT
Created attachment 555564 [details]
Pointing to a different pdf.

The PDF link in the previous test case broke.  Changing where the link points to
Comment 79 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-24 15:48:50 PDT
Created attachment 555574 [details] [diff] [review]
Proof of concept patch (Note: plugin cannot be activated)

I think we can block plugins in background tabs from taking focus by using the `WS_DISABLED` window style and the `EnableWindow` function.

`EnableWindow`: http://msdn.microsoft.com/en-us/library/ms646291%28v=VS.85%29.aspx
Window Styles: http://msdn.microsoft.com/en-us/library/ms632600%28VS.85%29.aspx

The idea is that, whenever a plugin's tab goes into the background, we will disable its window with a call to `EnableWindow` and whenever its tab becomes the current tab, we will enable its window.  When the window is disabled, it cannot take focus.

The attached (partial) patch shows that, if we create the plugin's window with the WS_DISABLED window style, it is unable to steal focus away from the current tab.  This is only a proof of concept; the plugin's window is never enabled with this patch applied, so you can't click in Reader and have anything happen.  I'll have to poke around in the focus manager code to determine where to hook up `EnableWindow`.

To test the attached partial patch:
   1) Load the test page
   2) Open the pdf "in a new tab"
   3) Note that you can still scroll the current tab

If anyone is aware of perils in this approach, please let me know.
Comment 80 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2011-08-24 17:22:15 PDT
According to the actual behavior, it seems that we should hide the window rather than disabling it. Why do you choose disabling way?
Comment 81 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-25 14:25:33 PDT
I agree; showing/hiding makes more sense for what we're trying to accomplish than enabling/disabling.  However, I haven't been able to produce a proof-of-concept patch that works using that approach.  It seems that existing code makes assumptions about (and explicitly sets in various places) the visibility of the plugin window.  My feeling so far is that using EnableWindow/WS_DISABLED will end in a cleaner patch, but I'll investigate both approaches.
Comment 82 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2011-08-25 17:57:25 PDT
> It seems that existing code makes assumptions about (and explicitly sets in various places) the visibility of the plugin window.

Really? I cannot break at nsWindow::Show() whose mWindowType is eWindowType_plugin. I think that it's not called for plugin window.
Comment 83 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-26 13:37:24 PDT
When we create the plugin window, we create it without the WS_VISIBLE style.  To verify, put a breakpoint in nsWindow::Create with the condition "aInitData->mWindowType == eWindowType_plugin" and then check the "style" parameter being passed to CreateWindowExW.  Based on that information, I had assumed that we were setting the visibility of the window at a later time.

Further investigation has revealed that we do later set the visibility of the window, but only once:
   The creation of the plugin window comes through this line of code in nsObjectFrame:
      (1) rv = mWidget->Create(parentWidget, nsnull, nsIntRect(0,0,0,0),
                     eventHandler, dx, nsnull, nsnull, &initData);
   In the same function, we show the plugin window:
      (2) mWidget->Show(PR_TRUE);

   (1) https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#470
   (2) https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#486

As you noted, we don't set the visibility of the plugin window after that initial call to `Show`, so if we skip that call, the tab with the plugin in it appears entirely black.  However, in my testing, skipping the `Show` call didn't prevent focus from being stolen away from the current tab.  This seems to indicate that hiding the plugin window when its tab is in the background won't be enough to keep that plugin from taking focus.
Comment 84 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-30 13:44:55 PDT
Created attachment 556979 [details] [diff] [review]
Patch v2 - Absolute minimal patch that fixes the issue.  Plugins now activate when their tabs are switched to

It seems that tab-switching code is mostly handled in JS, and that `nsWindow` gets involved only when its clip region is being set.

The attached patch creates plugin windows disabled, enables them when they become visible, and disables them when they are no longer visible. It fixes the attached test case and, in my limited testing, doesn't break other functionality. We can also modify this patch to call ::ShowWindow in addition to ::EnableWindow.

Any feedback appreciated! (Also any additional testing REALLY appreciated)

I'll spend a little more time testing then mark for review.
Comment 85 Jim Mathies [:jimm] 2011-08-30 13:51:54 PDT
I like the look of this. Make sure and comment the region code, and a run through try would be good too!
Comment 86 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-30 16:02:33 PDT
Running through try: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=76287a32b38e
Comment 87 Mozilla RelEng Bot 2011-08-30 17:50:53 PDT
Try run for 76287a32b38e is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=76287a32b38e
Results (out of 48 total builds):
    success: 44
    warnings: 4
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tabraldes@mozilla.com-76287a32b38e
Comment 88 singu.b+bugzilla 2011-08-31 03:13:43 PDT
(In reply to Tim Abraldes from comment #84)
> Created attachment 556979 [details] [diff] [review]
> Patch v2 - Absolute minimal patch that fixes the issue.  Plugins now
> activate when their tabs are switched to
> 
> 
> Any feedback appreciated! (Also any additional testing REALLY appreciated)
> 
I tested a bit the try build (firefox-9.0a1.en-US.win32.installer.exe)
First: Scrolling in all Tabs and all other scrollable components always possible, regardless of the amount of adobe pdf tabs.

But there are other issues remaining. The one Tim Abraldes points out in comment 77.

And also if the Adobe Plugin tab has focus it has Control over Strg + 1-9 and Strg + t, Strg + w. I think at least Strg + t should direct to the Firefox new tab function.

Important problem: Two adobe plugin tabs interference each other
If a second one is opened all keystrokes are send to the second one, not the one which has focus.

And i could produce situations in which Strg + 1-9 are not working after tab switch with mouse click. 
And also one time the mouse scroll on the tabbar does not work after switching out of a adobe tab. But i found no reliable way to reproduce this.
Comment 89 :aceman 2011-08-31 04:03:07 PDT
(In reply to singu.b+bugzilla from comment #88)
> And also if the Adobe Plugin tab has focus it has Control over Strg + 1-9
> and Strg + t, Strg + w. I think at least Strg + t should direct to the
> Firefox new tab function.

I think this is bug 78414 so it is not a regression from the patch.
Comment 90 Jim Mathies [:jimm] 2011-08-31 08:48:59 PDT
(In reply to Mozilla RelEng Bot from comment #87)
> Try run for 76287a32b38e is complete.
> Detailed breakdown of the results available here:
>     http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=76287a32b38e
> Results (out of 48 total builds):
>     success: 44
>     warnings: 4
> Builds available at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tabraldes@mozilla.
> com-76287a32b38e

Both of those test failures appear to be known.

We should continue to chip away at this and not hold up good fixes that address focus issues looking for other corner case problems. Tim, what's holding up seeking reviews on what you have?
Comment 91 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-31 09:09:09 PDT
Created attachment 557205 [details] [diff] [review]
Patch v3 - Comments added

I was going to follow up about the memory leak today (I'm not very good at processing TBPL output yet).  If that's not a concern then this is ready for review!
Comment 92 Jim Mathies [:jimm] 2011-08-31 09:21:05 PDT
(In reply to Tim Abraldes from comment #91)
> Created attachment 557205 [details] [diff] [review]
> Patch v3 - Comments added
> 
> I was going to follow up about the memory leak today (I'm not very good at
> processing TBPL output yet).  If that's not a concern then this is ready for
> review!

Per comment 77, which issues does this address? I'm asking so that I know what to test for.
Comment 93 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-31 09:34:47 PDT
The patch addresses the issue in this bug's title (issue 2 from Comment #77): When a plugin's tab is out of focus, it should not be able to steal keyboard focus or mousewheel events with this patch applied.

Issue 1 from Comment #77 is a separate bug (though the title and description need some updating): https://bugzilla.mozilla.org/show_bug.cgi?id=601889
Comment 94 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-31 09:55:53 PDT
(In reply to singu.b+bugzilla from comment #88)
> Important problem: Two adobe plugin tabs interference each other
> If a second one is opened all keystrokes are send to the second one, not the
> one which has focus.

I noticed this also.  It seems to be an existing issue since I was able to reproduce it on Aurora (8.02a), but I wasn't able to find a bug filed for it.  Since you mentioned it, you're free to file it (please double-check that it's not a duplicate, and post here with a link when you file).  I'll file it at end of week if you haven't.

> And i could produce situations in which Strg + 1-9 are not working after tab
> switch with mouse click. 
> And also one time the mouse scroll on the tabbar does not work after
> switching out of a adobe tab. But i found no reliable way to reproduce this.

If you're able to find repro steps for these, please post them here

Thanks for testing!
Comment 95 Jim Mathies [:jimm] 2011-08-31 11:20:14 PDT
Comment on attachment 557205 [details] [diff] [review]
Patch v3 - Comments added

Review of attachment 557205 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/src/windows/nsWindow.cpp
@@ +7315,5 @@
> +  // the region that the plugin is being clipped to is NULLREGION.  If it is,
> +  // the plugin window gets disabled.
> +  if(mWindowType == eWindowType_plugin) {
> +    int regionType = ::CombineRgn(dest, dest, dest, RGN_OR);
> +    if(NULLREGION == regionType) {

nit - I would just combine these two lines:

if (::CombineRgn(dest, dest, dest, RGN_OR) == NULLREGION) {
}
Comment 96 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-08-31 11:50:20 PDT
Created attachment 557266 [details] [diff] [review]
Patch v4 - Integrated review comments
Comment 98 Ed Morley [:emorley] 2011-09-01 01:54:06 PDT
http://hg.mozilla.org/mozilla-central/rev/b4193e7aa44c
Comment 99 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-09-02 17:44:39 PDT
(In reply to Tim Abraldes from comment #94)
> (In reply to singu.b+bugzilla from comment #88)
> > Important problem: Two adobe plugin tabs interference each other
> > If a second one is opened all keystrokes are send to the second one, not the
> > one which has focus.
> 
> I noticed this also.  It seems to be an existing issue since I was able to
> reproduce it on Aurora (8.02a), but I wasn't able to find a bug filed for
> it.  Since you mentioned it, you're free to file it (please double-check
> that it's not a duplicate, and post here with a link when you file).  I'll
> file it at end of week if you haven't.

Submitted: https://bugzilla.mozilla.org/show_bug.cgi?id=684416
Comment 100 Tim (fmdeveloper) 2011-09-24 10:24:29 PDT
*** Bug 687377 has been marked as a duplicate of this bug. ***
Comment 101 Alice0775 White 2011-10-09 08:49:40 PDT
*** Bug 693169 has been marked as a duplicate of this bug. ***
Comment 102 eyal gruss (eyaler) 2011-11-19 07:37:19 PST
*** Bug 641299 has been marked as a duplicate of this bug. ***
Comment 103 :aceman 2011-12-21 12:10:21 PST
So, can anybody confirm this is now fixed in just released Firefox 9?
Comment 104 Luke Pacholski 2011-12-21 15:03:18 PST
I just updated to 9.0 and continue to have the same issues. Using version 10.1.1.33 of the Acrobat plugin on Windows 7 Home Premium SP 1 (64 bit, but running the standard 32 bit version of Firefox).
Comment 105 Luke Pacholski 2011-12-21 15:07:23 PST
I also just tried creating a fresh profile to verify that was not the issue. The problem persists.
Comment 106 Tim Abraldes [:TimAbraldes] [:tabraldes] 2011-12-21 15:09:00 PST
(In reply to Luke Pacholski from comment #104)
> I just updated to 9.0 and continue to have the same issues. Using version
> 10.1.1.33 of the Acrobat plugin on Windows 7 Home Premium SP 1 (64 bit, but
> running the standard 32 bit version of Firefox).

Are you still using the hardware setup described in comment 72?  The issue with synaptics touchpads is being tracked in bug 626813.
Comment 107 Luke Pacholski 2011-12-21 15:26:56 PST
(In reply to Tim Abraldes from comment #106)
> Are you still using the hardware setup described in comment 72?  The issue
> with synaptics touchpads is being tracked in bug 626813.

I wasn't when I posted (new laptop), but I just tried on the old laptop and the issue remains. However, if the issue is Synaptics specific, I guess I'll follow that bug.
Comment 108 :aceman 2012-02-01 06:50:37 PST
Tim Abraldes, are you able to look at bug 626813 or do you not have the needed hardware?
Comment 109 Tim Abraldes [:TimAbraldes] [:tabraldes] 2012-02-01 13:15:52 PST
I'm not able to reproduce bug 626813 even though I appear to have the correct hardware:
  Win 7 x64
  Synaptics "ThinkPad UltraNav Pointing Device" 15.0.18.0
  Tried in FF9.0

I'll try a few more times throughout the day but it seems like scrolling is working properly using my laptop's touchpad.
Comment 110 Ben Lerner 2012-02-01 13:22:38 PST
FWIW, on a Dell Studio 1558, with "Dell touchpad" and Synaptics driver version 14.0.2.0, Win7x64, Fx 10, Adobe Reader 10.1.2.45, I can reproduce bug 626813 all the time, with just two tabs (one html, one pdf) in a window.  Scrolling always goes to the pdf.  Ditto if I clicked on a youtube flash video, then changed tabs to the html tab -- no mouse input goes to the html tab :(
Comment 111 Filip Zakrzewski 2012-02-01 13:52:03 PST
If you are talking about bug 626813, please use bug 626813 to send comments
this bug is about absolutely different issue :)

Note You need to log in before you can comment on or make changes to this bug.