Closed Bug 626813 Opened 13 years ago Closed 12 years ago

laptop touchpad scrolling doesn't work on other pages/tabs while PDF file is open through browser plugin in any tab in the same window

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla13
Tracking Flags:
Tracking Status
firefox10 - ---

People

(Reporter: raajc, Assigned: heycam)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Hide plugins in background tabs to avoid trackpad drivers wanting to scroll them. (v1.1)
1.41 KB, patch
jimm
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

When a PDF is open via browser plugin and when using a laptop touchpad for scrolling, scrolling only works on the PDF and not other tabs. Scroll bar scrolling works though.

Reproducible: Always

Steps to Reproduce:
1.Open a PDF file
2.Open another website on another tab
3.Scroll using laptop touchpad
Actual Results:  
The scrolling does not work on the other tab.

Expected Results:  
The page on the other tab should scroll while using a laptop touchpad.

Bug occurs with default theme.
Version: unspecified → Trunk
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Same happens for me with 4b9 and 4b10. Scrolling with the scrollbar on the touchpad is affected. Scrolling with Touchpoint and its middle button works
Want to Subscribe this Bug! It is pretty much annoying, cause it makes my working harder.
Also same happens with my touchpad. Im using FF 4.0.1, adobe acrobat 10.0.1, windows 7 64bit. When document in pdf is opened in one tab i cannot scrolling in another tab.
I also get this bug, FF 4.0.1, and I agree that it is _super annoying_.

WORKAROUND: Open PDFs in a different _window_ and it won't happen, at least for me (Dell laptop, Windows 7, FF 4.0.1).
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
I can confirm that this bug was introduced between beta 4 and beta 5 for Firefox 4. 

Some additional information: mouse wheel scrolling works properly in all tabs even when pdfs are open. Touchpad scrolling works properly in pdf tabs even with multiple open (it may take an extra click to focus on the pdf first). When attempting to scroll in a web tab using the touchpad, the pdf file that was opened most recently scrolls instead. It does not matter which pdf tab last had focus.

Example:

1. open web tab 1
2. open pdf tab 1
3. open pdf tab 2
4. open web tab 2

Results:
The touchpad correctly scrolls the current pdf when either pdf is open.
Pdf tab 2 will scroll whenever the touchpad is used to attempt to scroll one of the web tabs. order of receiving focus does not change this.
If pdf tab 2 is closed, scrolling on a web tab will scroll pdf tab 1.
Whoever can mark duplicates:

Bugs 594500 (this one), 626813, and 543027 are ALL THE SAME.

Information:

A reinstall of the Synaptics Touchpad driver (occurs on 15.2.20 and 15.0.24.0; I assume all) did not help.

We know it worked in FF4 beta 4 and broke in FF4 beta 5. Do we need a regression window deeper than that, such as a nightly build? I can try and find one, if no one else has. 

I'm reposting this to both other bugs, in case someone checks those first.
Thanks, I duped the other ones (albeit to bug 273456).
However, this bug was deduped from bug 273456. Dao, could you explain the difference here?
Status: NEW → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE
I do not believe that this is a duplicate of bug 594500. This bug refers to touchpad scrolling, and that one refers to the mouse wheel. The circumstances also appear different, because it seems that the symptoms of the mouse wheel can be resolved at least partially without closing all pdf tabs in the window. The touchpad will not work outside of pdfs until all pdfs are closed.

For more details on the different pdf related bugs see the comments on Bug 594500.
You guys wanted a regression window? You got one...found using mozregression tool.

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

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124
This problem occurs in the normal Adobe PDF plugin and also the Nitro PDF plugin.  

The PDF also must be in the same window. If you open two Firefox windows (Window A and Window B), only the window with a PDF tab will have the broken scrolling.

Window A: Google tab, PDF tab, CNN tab
Window B: Microsoft tab, Apple Tab, Dell tab

(tab names are examples)

Any scroll event in Window A activated via the touchpad (two-finger scroll, scrolling at the edge of the touchpad) will be INTERCEPTED by the PDF tab, even if the PDF tab is not active.

Any scroll event activated via the touchpad inside Window B will respond normally: scroll events will respond to the active tab only.
Also, as per comment 12, may we revert the duplication? This is a separate bug. 

We have a regression window, per comment 13...how can we make this official, as one of the keywords still states "regressionwindow-wanted"? This should accelerate the debug time when a developer looks at, right? So, how do we get a developer to look at this?
(In reply to comment #14)
> This problem occurs in the normal Adobe PDF plugin and also the Nitro PDF
> plugin.  
> 
> The PDF also must be in the same window. If you open two Firefox windows
> (Window A and Window B), only the window with a PDF tab will have the broken
> scrolling.
> 
> Window A: Google tab, PDF tab, CNN tab
> Window B: Microsoft tab, Apple Tab, Dell tab
> 
> (tab names are examples)
> 
> Any scroll event in Window A activated via the touchpad (two-finger scroll,
> scrolling at the edge of the touchpad) will be INTERCEPTED by the PDF tab,
> even if the PDF tab is not active.
> 
> Any scroll event activated via the touchpad inside Window B will respond
> normally: scroll events will respond to the active tab only.

I have been facing the same issue(Bug 644226)
Also, as per comment 12, may we revert the duplication? This is a separate bug. 

We have a regression window, per comment 13...how can we make this official, as one of the keywords still states "regressionwindow-wanted"? 

Through my rudimentary technical skills, it seems bug 575440 (one bug fixed from 0827) may have something to do with it: https://bugzilla.mozilla.org/show_bug.cgi?id=575440.
Maybe so we can narrow this bug down a bit further, we can post our specifications. OS and touchpad should be enough, I think.

Windows 7 64-bit
Synaptics Touchpad v7.2 on driver 15.0.24.0
I am able to deduplicate, however we must find the differing facts.
So this bug basically says the touchpad scrolling does not work in web tabs while any other pdf tab is open in the FF window? No amount of clicking on other tabs and changing focus fixes this? Only closing all the pdf tabs fixes the scrolling agains? Is that correct?
Aceman -- yes
I could test that but touchpad on my Thinkpad R500 (called UltraNav) does not do any scrolling in FF. It works fine in other programs. Any idea why that is?
The analysis in comment 13 and comment 17 seems logical. CCing the author of the change in bug 575440.
While I could not reproduce on my machine yet (touchpad seems to not work in FF web tabs, it works only in pdf tabs), I will try on other laptops later in the day. Until then, can anybody confirm this is still seen in FF 7 or 8?
Keywords: regressionwindow-wanted
Thank you, Aceman! :) Yes, if you would like further detail to why bug 626813 and bug 594500 are different, see bug 594500 comment 33. Further evidence that these are two different bugs can be found at bug 626813 comment 12 and bug 594500 comment 28.

@ comment 19

Yes, you can click over 9000 times, you cannot "reset" the focus to the active tab. It is permanently focused on the PDF tab as long as the PDF tab is open (in the same window, of course, as stated in comment 14). I agree with Kyle.

@ comment 21

Hmm...weird. Is the UltraNav with Synaptics or the UltraNav with Alps? If Synaptics, check out this fix (slightly technical): 

http://forums.laptopvideo2go.com/topic/7103-scrolling-with-synaptics-touchpad/

If it's Alps, are the drivers updated? Have you tried generic/non-Toshiba Alps drivers? I think, like the Synaptics touchapds and most hardware products, you can use non-branded-OEM drivers just fine. Also, did you experience this issue in Firefox 3.6.xx? 

@ comment 22

Firefox 8? Are we on 8, yet? I only see links for Aurora (FF 7) and Beta (FF 6). I'm D/L'ing the latest Aurora build and checking it out; brb.
Can't comment on the UltraNav questions, I am not allowed to change the drivers, but I think they are about 2 years old, I can check that later. I don't know about FF 3.6 I only opened the lid on the laptop now and used the touchpad to test this bug in FF 5 :) I do not use it normally, have external mouse and keyboard.

However, I have found other older Thinkpad where the scrolling works in web tabs and it also works in pdf tabs. There I do not see this bug 626813.

Yes, Nightly FF is on 8 now.

So let's try to dedupe this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: laptop touchpad scrolling doesn't work on other pages if PDF file is open through browser plugin → laptop touchpad scrolling doesn't work on other pages/tabs while PDF file is open through browser plugin in any tab in the same window
Ah, forgot the main question :) I have only Win XP available. Has anybody seen this bug on anything outside of Win 7 64bit? That is what the platform field is set to.
Oh, haha, gotcha. Sounds good. :D

Ah, OK. I guess there is a difference from Aurora and the Nightly's, then? Aurora Firefox 7 (from 7-29-2011) still exhibits this bug. 

Let me go find Firefox 8! :D

Sorry for the delay; I still haven't gotten used to having two Firefox's installed on my computer (one for regular, one for testing) and I accidentally deleted my regular profile! :o All better now, but, whew...different profile folders this time, lol. :D
All right, typing this from Firefox 8.0a1 (2011-07-29). Bug still present in this latest nightly. :(
Yes, Nightly and Aurora are offset by 6 weeks and 1 version in the same way as Aurora and Beta are. Nightlies are where the real new work happens and bug are fixed :)

Do you have any non-Win 7 machines to test this?
Thank you for the reply again; sorry for the delay. Unfortunately, I have no laptops with Windows XP. :( I have 3 other laptops running Windows 7. 

HP Envy 14 (Windows 7, 64-bit, Synaptics): problem exists.
Gateway ZH7 (Windows 7, 64-bit, Synaptics): problem exists.
Toshiba Satellite C665 (Windows 7, 64-bit, Synaptics): problem exists.

I'm surprised more people haven't seen this problem, but no one in my house knows how to use a multitouch touchpad, haha. :)
Also, a bit of Google searching shows a few duplicated bugs. However, those duplicated bugs (bug 638671 and bug 632889) show it as a problem on Windows 7 x86!

Seems to be a Synaptics + Windows 7 issue.
Synaptics + Windows Vista 32-bit SP2 and I have the problem as well, currently with FF6.0 beta
Additional info:

With a PDF open, touchpad scrolling doesn't work.

If I disable the Adobe plugin the scrolling works.  The tab the PDF was in still exists but is blank.

Enable Adobe scrolling still works.

Open a pdf and scrolling quits.
Thanks, robb. :)

Yup, that's exactly it. Well, you're another Windows 7 x86 user, so I think we're safe to change this bug from only x64 to Windows 7 x86 AND x64.
Comment 32 seems to imply also Windows Vista.
Component: Plug-ins → Event Handling
QA Contact: plugins → events
Hardware: x86_64 → All
That's true. Vista and 7, then?

Oh, an update: Foxit PDF's plugin is able to scroll correctly (!). I don't know why or how, but it does. :)
Windowed vs non-windowed plugins?
(In reply to Cameron McCormack (:heycam) from comment #37)
> Windowed vs non-windowed plugins?

Possibly? I mean, the plugin is still within the tab?
Sorry, by windowed and non-windowed (windowless) I meant the mode of operation of the NPAPI plugin: https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics#Windowed%20and%20Windowless%20Plug-ins

Trackpad drivers are known to inspect the window hierarchy to determine where to send scrolling events.  With windowless plugins, there is no change to the window hierarchy.  My guess would be that the Foxit plugin is windowless while the Adobe reader one is windowed, and that that is why scrolling works with the former but not with the latter.
Ohhh, I see. That could very well be true. I'm emailing Foxit to see if they know anything about their plugin behavior.
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.
I can remember this bug only since FF4 and up to FF6...

G73jw; Synaptics Touchpad v7.4;
Synaptics Pointing Device - v15.2.20 31 Mar 2011

Windows 7 x64
Bug also exists on HP8710p (Synaptics Touchpad v6.2) Win7 x64 ....
There is no such bug on my PC. My sysreqs are:

ASUS N73JF : ELAN PS/2 Port Smart-Pad  
Firefox v5.0.1
Win 7 x64
(In reply to Cameron McCormack (:heycam) from comment #39)
> Sorry, by windowed and non-windowed (windowless) I meant the mode of
> operation of the NPAPI plugin:
> https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-
> in_Basics#Windowed%20and%20Windowless%20Plug-ins
> 
> Trackpad drivers are known to inspect the window hierarchy to determine
> where to send scrolling events.  With windowless plugins, there is no change
> to the window hierarchy.  My guess would be that the Foxit plugin is
> windowless while the Adobe reader one is windowed, and that that is why
> scrolling works with the former but not with the latter.

Well, Foxit's support team sent me a reply:

"Ours is a windowed' s OCX plugin."

Humph. :(

Thank you Igor, mike, and Dmitry for those details. It seems, so far, that this only occurs on Synaptics Touchpads, but we'll need a bit more data to make this concrete. 

I'm with Igor on the timing; I've only ever had this problem since FF4, but it's curious mike that you've had it even on FF3! The plot thickens...
Experiencing this bug as well.

HP 8530p notebook
Firefox v6.0.2
Win 7 x64 SP1
Synaptics PS/2 Port TouchPad 15.0.24.0
Adobe Acrobat 10.1.1.3 plugin
Now, a very similar bug 273456 has been fixed in Firefox 9, and also bug 594500 is marked fixed, can anybody of you try if the problem reported here isn't fixed too?
Uninstalled adobe and installed Foxit and srolling works everywhere.
(In reply to aceman from comment #47)
> Now, a very similar bug 273456 has been fixed in Firefox 9, and also bug
> 594500 is marked fixed, can anybody of you try if the problem reported here
> isn't fixed too?

Where can I download Firefox 9?

Eventhough scrolling works with Foxit Ctrl+Pg up and Ctrl+pg dn do not work once on the pdf tab. I downloaded Aurora but the same issue still exists.
Aurora is only at version 8. Try the nightly here: http://nightly.mozilla.org/ .
(In reply to aceman from comment #50)
> Aurora is only at version 8. Try the nightly here:
> http://nightly.mozilla.org/ .

Thanks! I installed the nightly. However it opens the pdf externally in adobe. Under Options Applications for Adobe Acrobat Document there is no option of 'Preview in Nightly' or 'Use Adobe Reader (in Firefox)'.
Check in Tools-> Addons->plugins if the Adobe PDF plugin is correctly enabled.
(In reply to aceman from comment #52)
> Check in Tools-> Addons->plugins if the Adobe PDF plugin is correctly
> enabled.

I don't see anything in plugins. It's empty. I installed adobe reader x after installing nightly. What should I do to get the plugin installed correctly? Thanks.
Don't know, it should kinda install automatically. Do you now have several firefox versions installed in parallel?
(In reply to aceman from comment #54)
> Don't know, it should kinda install automatically. Do you now have several
> firefox versions installed in parallel?

Removed everything except for Nightly. Neither Adobe nor Foxit recognize Nightly.
Maybe they are looking into the registry and searching for "Firefox" name, which you now don't have so they do not install the plugin. But if it worked on Aurora I don't know why it would fail on Nightly. What about installing Firefox, then Adobe reader, then Nightly?
(In reply to aceman from comment #47)
> Now, a very similar bug 273456 has been fixed in Firefox 9, and also bug
> 594500 is marked fixed, can anybody of you try if the problem reported here
> isn't fixed too?

Tried the nightly on win7 with acrobatX and it does the same as before. So the problem is not fixed.
I can confirm this bug on Mozilla/5.0 (Windows NT 6.1; rv:9.0a2) Gecko/20111006 Firefox/9.0a2. 

EEE PC Seashell 1215N
Synaptics PS/2 Port TouchPad 19.11.2009 14.0.16.0
Has anybody seen this with Adobe acrobat pdf plugin older than version X.0.0 (10)?
I've downloaded the current Synaptics driver 15.2.20 from http://www.synaptics.com/resources/drivers and the bug still occurs in any Firefox release I've tried (4, 5, 6, 7, 8 beta, 9 aurora, 10 nightly). :(
Same problem. Using Windows 7 SP1, Firefox 7, Adobe Reader X, and an HP ProBook 4530s with a Synaptics touchpad.  All are up-to-date.
I believe this bug should be confirmed and switch to the new status and seriously considered for tracking or blocking Firefox Nightly (10) at least since there is no workaround to solve this annoyance.
tracking-firefox10: --- → ?
There's no workaround... except for installing foxit, may be ;)
The bug is confirmed (REOPENED almost equals NEW).
Any answers to my question in comment 59?
I don't think you should use the tracking flag in this way...
I'm not sure, which versions are you talking about, but I've got Adobe Acrobat 10.1.1.33 plugin on FF7.0.1 and the bug is still there.
I am asking about Acrobat reader 9.x or lower.
This is a regression from bug 130078, related to bug 273456, and is not something that we'd track for a particular release because it is not a recent regression. It may also be a bug in the trackpad driver, not in the Mozilla code, because they were making assumptions about our window hierarchy that were changed in bug 130078. Tn/roc, wasn't there another bug already filed on the synaptic trackpad issue?
tracking-firefox10: ? → -
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #67)
> hierarchy that were changed in bug 130078. Tn/roc, wasn't there another bug
> already filed on the synaptic trackpad issue?

https://bugzilla.mozilla.org/show_bug.cgi?id=622410
?

Why Chrome is working fine here?
Because it hasn't redesigned the window hierarchy recently?
heycam, would you be able to try reproducing this?
Here's a similar issue that may help for troubleshooting: 
Scrolling also doesn't work in the same manner for the "Manage Search Engines" box, with or without a pdf tab open.  Not sure if there's a separate bug report for that, but functionally it's the same problem to me.
On this Thinkpad T60 with Windows 7 x64, a 32 bit Nightly, Adobe plugin 10.1.1.33 and UltraNav driver 15.2.14.0, I don't have any trouble using the trackpad to scroll in one tab if another background tab has a PDF in an <object>.  I'm using http://people.mozilla.org/~cmccormack/misc/pdf.html as the background tab's page.  I will try some earlier trackpad drivers.
Make sure you try giving the PDF plugin focus before making a background tab, that might be important.
Good idea.  Same result, though.  (I selected the non-PDF with the mouse after clicking in one of the text boxes in the PDF plugin's toolbar.)  The same configuration above but with driver 15.0.18.0 did not show the scrolling problem either.

I am wondering now whether this is a problem that only manifests on newer Synaptics hardware than the one in this T60 (which is not multi-touch).
I have the exact same problem. The problem also seems to happen if you have a PDF open in another tab group.

Synaptics PS/2 Port Touchpad (Driver 15.0.17.4)
Windows 7 Professional x64
Running Firefox 7.0.1 but bug has been occurring for a while now.

My friend has an Alps Pointing Device (Driver 7.106.2015.1201 (29/10/2010)) and the problem does not occur for him. He has the same version of Firefox and Windows as me.
Same problem, even when PDF is not open in another tab. Both scrolling by two fingers, and scrolling by touching the right side edge do not work on ff7, even when as it works on chrome, ie 9, and all other programs. It is maddening.

My configuration is Synaptics PS/2 Port Touchpad (driver 15.3.22.0) on Windows 7 Enterprise
Blocks: 130078
I have this problem on both my Windows XP 32-bit and Windows 7 64-bit machines with the latest Firefox, Adobe plugin, and Synaptics touchpad driver installed.  I cannot read pdf documents in Firefox while being about to scroll with the touchpad in other tabs.  Is there any hope of this being fixed?  I remember not having this problem on my Windows XP machine before I updated the Adobe plugin from version 9 to version 10.
Operating System: Windows 7 Home Premium Service Pack 1
Firefox Version: 8.0
Adobe Acrobat Plugin version: 10.1.1.33
Device: Synaptics TouchPad V7.4 Driver 15.2.6
I can confirm on both Windows 7 and XP here with Firefox 9.0:

XP Media Center Edition 2002 SP 3
Synaptics v10.1.8 06Dec07 (Synaptics TouchPad V5.9)
Adobe Acrobat 9.4.5.236

Windows 7 Home Premium SP 1 (64-bit)
Synaptics v15.2.11.1 03Feb11 (Synaptics TouchPad V7.2)
Adobe Acrobat 10.1.1.33
Please also specify Firefox version (or build date) in your posts.

Firefox 9 (www.getfirefox.com, autoupdate does not yet offer it) supposedly fixed bug 273456 (scrolling with PDF with other scrolling devices (mouse, keyboard)). So it may help some of you.
We need clear reports from touchpad configurations that are still broken even in Firefox 9.
Firefox 9.0 beta channel
Windows Vista Home Premium Service Pack 2 32-bit
Synaptics 15.2.20.0  3/31/2011
Adobe Acrobat 10.1.1.33

pdf scrolls in browser tab but other tabs do not
(In reply to :aceman from comment #80)
> Please also specify Firefox version (or build date) in your posts.

I'm not sure if this was directed at me or not, but to be clear I was using Firefox 9.0 on both machines in post 79.
Exactly the same as last time. The pdf scrolls but normal webpages do not and the pdf scrolls in the background while trying to scroll on a webpage.

Synaptics PS/2 Port Touchpad (Driver 15.0.17.4)
Windows 7 Professional x64
Firefox 9.0.1
Just going to hop in here to consolidate some information:

I also still have this bug in FF 9.0.1 and 10.0a2. 

Synaptics v7.2 touchpad (driver version: 15.0.24.0)
Windows 7 Ultimate x64
Firefox 9.0.1 and Firefox 10.0a2
Adobe PDF Reader 10.1.1.xx (unsure exactly which version; already uninstalled) and NitroPDF 2.1.1.3
And it's not limited to scrolling, actually. With Nitro PDF installed, pinch zoom and three finger flick do not work with a PDF open. 

So, all multitouch gestures do not work in the active tab if a nonactive tab is a PDF.
Just want to check in here...any new info or news on this? Still makes browsing a pain...
Blocks: 709996
Happens all the time here, on all of my versions of Firefox (stable 8.0.x-9.0.x Aurora, Nightly). Sony Vaio Z, Windows 7, latest version of the Adobe Reader X software and plugin.
(In reply to Cameron McCormack (:heycam) from comment #74)
> I am wondering now whether this is a problem that only manifests on newer
> Synaptics hardware than the one in this T60 (which is not multi-touch).

I can confirm that my Sony Vaio has multi-touch, so this hypothesis might be true.
I just installed Adobe Reader X on this Lenovo SL500 I have, and am able to reproduce the problem.  When trying to vertically scroll by using the right edge of the trackpad, the mouse cursor changes (to something that I assume means "scrolling", though it is different from other Synaptics scrolling cursors I've seen) but no scrolling occurs.  If I am on the tab with the PDF loaded, then the document does scroll.  Using the trackpoint to scroll works regardless.
Is QA help wanted in this bug? It's been in bugzilla for over a year and the steps to reproduce are clear. Just trying to figure out what we're stuck at and what the next step is in this bug. It seems like it's affecting lots of users.
I have the same comment as Mr. Tenser. For me, this bug has been present since *Firefox 4*. Yes, six versions ago! What do we need to do to move towards a resolution? And, again, ostensibly many users *are* affected.

And, the bug has a tracking flag of "tracking-firefox10." For those who do not know, bugs marked tracking-firefox# "are bugs that must be resolved one way or another before a particular release ships." I do not know how stringent this is because this was obviously not looked at before Firefox 10 was released. :( And "...bugs marked tracking-firefox# should have actionable next steps. Often, the next thing to do is to gather more information (from automated systems like crash-stats or the bug reporters themselves). If a bug has tracking-firefox# set it means release drivers will help shepherd those next steps until it becomes clear the bug will not impact a release (either via a fix or new information). At that point, release drivers will no longer track the bug."

All of this is copied from this Mozilla blog post (http://blog.mozilla.com/channels/2011/06/01/more-details-about-how-to-use-the-tracking-firefox-bugzilla-flag/). 

So apparently, at one time for one person (at least), this bug was worth fixing or else that flag would not have been approved. Again, a regression window has been provided in comment 13, which I will repeat here:

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

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124

And yes, these are nightlies for Firefox 4 (!).
I'd love to take this on but I'm not able to reproduce this bug on my system:
  Lenovo W520
  Windows 7 64-bit
  "Thinkpad UltraNav Pointing Device" 15.0.18.0
  Acrobat 10.1.2.245
So, can I propose something?

First of all, I know nothing about the ff code structure and I never had part in the development. But quickly going through the pushlog posted by Ibrahim, I think I can identify some changes that may be involved in the regression.

What about "undoing" them in the code and posting some test executable somewhere so that we can check if it's solved? (I know that this is easier said than done, and I know this may lead nowhere, but unless someone else comes up with a better idea to solve the bug...)

Starting from the most guilty change to the least guilty one:
https://bugzilla.mozilla.org/show_bug.cgi?id=575440 <- 60% probability
https://bugzilla.mozilla.org/show_bug.cgi?id=587944
https://bugzilla.mozilla.org/show_bug.cgi?id=577579
https://bugzilla.mozilla.org/show_bug.cgi?id=549799

Cheers.
Danilo
I have the same bug using:

Compaq CQ60
Windows 7 32-bit
Synaptics Pointing Device - v11.0.7 27Mar08
Acrobat 10.1.2.45

Before I found this work-around, I had to change to Chrome, but I'm back now, but it needs fixing!
Forgot to say, this is with FF10.0
Since I am able to reproduce now, I will look into it.
Assignee: nobody → cam
Status: REOPENED → ASSIGNED
As a first step, let's try hiding plugins when they are not visible.  That will get scrolling working if the plugin is on a background tab.  I'll need to look further into solving the problem more generally to handle plugins visible on the foreground tab.
Attachment #595231 - Flags: review?(jmathies)
The patch does this hiding regardless of whether we've got a Synaptics trackpad.  If you think it's a good idea to do this only if we do, I can do that.  (Although it will need to be a different condition from IsObsoleteSynapticsDriver(), since someone is reporting this problem with v15.3.x.y of the driver, whereas IsObsoleteSynapticsDriver() checks for <= 15.0.x.y.)
Whiteboard: [autoland]
Whiteboard: [autoland] → [autoland-in-queue]
Autoland Patchset:
	Patches: 595231
	Branch: mozilla-central => try
Error applying patch 595231 to mozilla-central.
unable to find 'widget/src/windows/nsWindow.cpp' for patching
1 out of 1 hunks FAILED -- saving rejects to file widget/src/windows/nsWindow.cpp.rej
abort: patch failed to apply

Could not apply and push patchset:
Whiteboard: [autoland-in-queue]
rebase over recent widget/ directory changes
Attachment #595249 - Flags: review?(jmathies)
Attachment #595231 - Attachment is obsolete: true
Attachment #595231 - Flags: review?(jmathies)
Whiteboard: [autoland]
Whiteboard: [autoland] → [autoland-in-queue]
Autoland Patchset:
	Patches: 595249
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/rev/c098b7df0f00
Try run started, revision c098b7df0f00. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=c098b7df0f00
Comment on attachment 595249 [details] [diff] [review]
Hide plugins in background tabs to avoid trackpad drivers wanting to scroll them. (v1.1)

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

::: widget/windows/nsWindow.cpp
@@ +7305,4 @@
>        ::EnableWindow(mWnd, FALSE);
>      } else {
>        ::EnableWindow(mWnd, TRUE);
> +      ::ShowWindow(mWnd, WS_SHOW);

Should this be SW_SHOWNOACTIVATE? Activation implies taking focus. 

Also, any anomalies with this patch with plugins? I wonder what windowing events this generates that ultimately end up as plugin event.
I'm not finding that SW_SHOWNOACTIVATE is giving the plugin focus.  (I kind of assumed that SW_SHOWNOACTIVATE was more for top-level windows, but maybe not?)

I did some brief testing with the Adobe Reader X plugin, but nothing extensive, nor with other plugins.  If you can give me a list of top N plugins I should test with, I can do that.

Switching back and forth between the tab with the Reader plugin and another tab, I only see painting related messages being sent to the plugin's windows.
(In reply to Cameron McCormack (:heycam) from comment #103)
> I'm not finding that SW_SHOWNOACTIVATE is giving the plugin focus.  (I kind
> of assumed that SW_SHOWNOACTIVATE was more for top-level windows, but maybe
> not?)
> 

Entirely possible it doesn't do anything different on children, but it's good we checked.
Attachment #595249 - Flags: review?(jmathies) → review+
Try run for c098b7df0f00 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=c098b7df0f00
Results (out of 83 total builds):
    exception: 6
    success: 28
    failure: 49
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-c098b7df0f00
Whiteboard: [autoland-in-queue]
Excellent! The patch v1.1 fixed this bug on my environment (Synaptics TouchPad V7.4).

Note that the consts are SW_*, not WS_*.
Great!  Thanks for testing, Masayuki.  When you have a page like http://people.mozilla.org/~cmccormack/misc/pdf.html in the foreground tab, with the plugin visible, and you try to scroll, it will scroll the plugin regardless of what has focus, right?

Got a new try build with the correct const names up now.
(In reply to Cameron McCormack (:heycam) from comment #107)
> When you have a page like
> http://people.mozilla.org/~cmccormack/misc/pdf.html in the foreground tab,
> with the plugin visible, and you try to scroll, it will scroll the plugin
> regardless of what has focus, right?

Unfortunately, yes. So, I cannot scroll tab bar too.

If we're hooking all messages of all windows on plugins, we can make the wheel messages pass our window procedure first. I'm not sure whether we're doing it.
I don't think we are hooking the messages for plugin windows at the moment.  Seems kind of drastic. :)  I'll see if I can trick the trackpad driver into sending our top-level window the scroll messages instead of the plugin window, first.
Okay, when you change nsWindow's mouse wheel handling code or pointing device driver related code, please cc me to the bug. I'm working on mouse wheel handling code refactoring in bug 672175. On my local tree, I almost finished the work excepting making testing framework.
(In reply to Cameron McCormack (:heycam) from comment #109)
> I don't think we are hooking the messages for plugin windows at the moment. 
> Seems kind of drastic. :)

We are. We're subclassing the plugin window actually. See PluginInstanceChild::PluginWindowProcInternal.
Let's land patch v1.1 soon anyway.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #112)
> Let's land patch v1.1 soon anyway.

Yeah, new bug should be filed for the remaining issue.
Try run for 43132a6c8985 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=43132a6c8985
Results (out of 47 total builds):
    success: 46
    warnings: 1
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/cmccormack@mozilla.com-43132a6c8985
 Timed out after 06 hours without completing.
Component: Event Handling → Widget: Win32
QA Contact: events → win32
I filed bug 725475 for working on a more complete fix.
https://hg.mozilla.org/mozilla-central/rev/606a6ab0d0a6
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Updated to 10.0.2 ... still not fixed. Synaptics touchpad still won't scroll when PDF open in another tab. To clarify: the PDF tabs will scroll fine, but not any other tab when Reader active in browser. Peripheral non-synaptics mouse unaffected by this bug when using same computer. NOT FIXED.
If you look above, you'll see that it says that the target milestone for this is Firefox 13.  In order to get this fix, you'll have to wait another few release cycles, or switch to a more experimental version.
A link would be nice ... cause you see, I can't scroll up ;)
Since there are a number of people cc'ed to this bug, I thought it might be helpful with a few pointers on how to get more involved with beta testing Firefox.

If you want to test the fix of this bug today, you can do that in the latest nightly build: http://nightly.mozilla.org/

If you want to wait until this lands in a slightly more stable (yet still beta testing) branch, you can download Firefox Aurora, where the fix should appear on March 13: http://aurora.mozilla.org/

For an overview of the release schedule, see https://wiki.mozilla.org/Releases
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: