Closed Bug 273456 Opened 20 years ago Closed 13 years ago

Plugins (mainly PDF/Java) steal shortcut keys/focus/mouse events when tab is out of focus (inactive).

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla9

People

(Reporter: bugzilla, Assigned: TimAbraldes)

References

Details

(Keywords: common-issue?, testcase)

Attachments

(2 files, 5 obsolete files)

Pointing to a different pdf.
1.40 KB, text/html
Details
Patch v4 - Integrated review comments
2.07 KB, patch
TimAbraldes
: review+
Details | Diff | Splinter Review 
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:

*** This bug has been marked as a duplicate of 78414 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(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.
(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.
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.


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


(In reply to comment #6)
Please dont add the full text when replying, it makes it difficult to read the
bug, thanks
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.
*** Bug 296594 has been marked as a duplicate of this bug. ***
Summary: Acrobat files steal Ctrl+T when tab is out of focus. → Plugins steal shortcut keys when tab is out of focus.
*** Bug 288002 has been marked as a duplicate of this bug. ***
Severity: normal → major
Flags: blocking-aviary1.1?
*** Bug 272849 has been marked as a duplicate of this bug. ***
Depends on: PluginShortcuts
Keywords: testcase
Attached file Testcase (obsolete) — 
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
*** Bug 296594 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.8b3?
(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.
> 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.
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?
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).
No fix in sight, not going to block on this.
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
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?
(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.
I find this behaviour also without active plugings. For example, right-click->"select all" sometimes selects the text in another tab.

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
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.
Assignee: bugs → nobody
Test case no longer works for me in Linux with Firefox 2.0.0.6, but accesskeys are still regularly stolen by unfocused tabs.
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.
Blocks: 315513
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?
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
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
Component: Tabbed Browser → Plug-ins
Product: Firefox → Core
QA Contact: tabbed.browser → plugins
This bug is still an issue with adobe reader X. Very, very annoying for thoe dealing with pdfs inside the browser!
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.
Is there any chance this bug ever gets fixed?
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.
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.
Keywords: common-issue?
Blocks: 641299
OS: Windows XP → Windows 7
Hardware: x86 → All
Version: unspecified → Trunk
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.
Hardware: All → x86
Summary: Plugins steal shortcut keys when tab is out of focus. → Plugins (mainly PDF/Java) steal shortcut keys/focus/mouse events when tab is out of focus (inactive).
Any chance of this being fixed? It's one of my few problems with using Firefox.
No longer blocks: 641299
Isn't there a focus "meta" bug this should be linked to?
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!
This is not only about keyboard focus. See all those duped bugs. It is a general problem of all focus going to the plugin.
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 :)
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.
(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.
(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.
(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
(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.
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.
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)
@ 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).
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.
(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.
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.
Attached file wheel scroll test case (obsolete) — 

        Attachment #185340 -
        Attachment is obsolete: true

    
    

    
  
I'll start throwing debugger/sysinternals tools at this and see what I come up with
Assignee: nobody → tabraldes
Status: NEW → ASSIGNED

    
    

    
  
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

    
    

    
  
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.

    
    

    
  


  
The PDF link in the previous test case broke.  Changing where the link points to

        Attachment #554459 -
        Attachment is obsolete: true

    
    

    
  


  
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.

    
    

    
  
According to the actual behavior, it seems that we should hide the window rather than disabling it. Why do you choose disabling way?

    
    

    
  
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.

    
  
Blocks: 594500

    
    

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

    
    

    
  
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.

    
    

    
  


  
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.

        Attachment #555574 -
        Attachment is obsolete: true

    
    

    
  
I like the look of this. Make sure and comment the region code, and a run through try would be good too!

    
    

    
  
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

    
    

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

    
    

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

    
    

    
  
(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?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v3 - Comments added (obsolete)
        — 
          — Splinter Review
      

    


  
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!

        Attachment #556979 -
        Attachment is obsolete: true

        Attachment #557205 -
        Flags: review?(jmathies)

    
    

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

    
    

    
  
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

    
    

    
  
(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 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) {
}

        Attachment #557205 -
        Flags: review?(jmathies) → review+

    
    

    
  


  

        Attachment #557205 -
        Attachment is obsolete: true

        Attachment #557266 -
        Flags: review+
Whiteboard: checkin-needed

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/b4193e7aa44c
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9

    
    

    
  
(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

    
    

    
  
So, can anybody confirm this is now fixed in just released Firefox 9?

    
    

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

    
    

    
  
I also just tried creating a fresh profile to verify that was not the issue. The problem persists.

    
    

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

    
    

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

    
  
Blocks: 709996

    
    

    
  
Tim Abraldes, are you able to look at bug 626813 or do you not have the needed hardware?

    
    

    
  
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.

    
    

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

    
    

    
  
If you are talking about bug 626813, please use bug 626813 to send comments
this bug is about absolutely different issue :)

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: