User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 This is new in FF4 beta 5. When a PDF is opened in a tab and that PDF is wheel-scrolled, then other tabs lose wheel functionality. If we then move the mouse up to the address or tabs bar or down to the status bar and do a wheel event there, wheel scroll works again in the page. If we switch to another window (alt-tab) and do wheel events in it, when switching back to FF, the page has lost scrolling again. Similar to Bug 564716, but new. Reproducible: Always Steps to Reproduce: 1. Open a PDF document in one tab, having other tabs with web pages around 2. Scroll the PDF with the wheel 2.1 Alternatively, switch to any other program window and move the wheel on it 3. Change to a page in another tab and move the wheel -> no scroll 4. Move the wheel on Firefox but out of the page rendering area (menu, tab bar, address bar...) -> scroll works again in the page
What version of Acrobat Reader was this using? (Or Foxit Reader?) Does this occur with the latest nightly?
I must say I recently found out the above behavior only happens when KatMouse is active. KatMouse is a Windows add-on that makes mouse wheel events go to the window just beneath the mouse pointer (as happens in several Linux desktops e.g.) and not to the window with the keyboard focus (as does Windows instead). I consider it a must-have, BTW :-) More info on the behavior: when we switch from a tab containing a PDF to an HTML page, and this page is not reacting to the wheel, it is because the events are being sent to the PDF tab!! Yes, the PDF document is being scrolled "in the background" when its tab is inactive. However, even if related to a third-party component, I think this behavior is a symptom of something that may otherwise go unnoticed in the way Firefox handles its windows when one of its tabs is rendered by a plugin. Something that changed in 4 beta5. [was OOPP first enabled in that beta??] I've used Spy++ to compare a version of Firefox 3.6.x and Firefox 4 beta 7 and their windows have indeed changed a bit. Firefox 3.6 has several "sibling" windows occupying the same whole client area. But only one of them is active and visible, the one in the active tab. When we switch from one tab to the other, the corresponding windows are disabled/enabled (hidden/shown), which is visible in Spy++ with different icons. Firefox 4 has only one window for the client area, which has a child window of class GeckoPluginWindow (same size). No matter what tab is active, The GeckoPluginWindow window is always active, so it can receive the wheel events even if not visible. Maybe that clears the situation a bit... I'll now try a nightly to see if it has changed.
Thanks for the explanation. If it does occur with the latest nightly, would you be able to try and find the regression range: https://wiki.mozilla.org/QA/Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows Thanks :-)
Bump for comment 3 - thanks !
I've found that middle-clicking a PDF link to open that PDF in a background tab also breaks mouse wheel scrolling. Switching tabs is required to fix it. This is using Adobe Reader X and Firefox 4.0.
The issue I described is present as early as the 2010-11-25 nightly. I can't test any earlier because there aren't any Win32.zip builds available prior to that - or perhaps I'm looking in the wrong place?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ should have older builds. Look at for example http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/
You could also try using the Mozregression tool (will be quicker since bisects, downloads, extracts and works out rev IDs automatically): http://harthur.github.com/mozregression/
OK, after some experimentation it turned out that Firefox 3.6.16 + clean profile + Adobe Reader X have the exact same problem on my system. I guess I should file a separate bug?
I wonder if the problem is in Adobe Reader and not in Fx.
This is fairly likely to be a reader bug, but we can't be sure without debugging a lot of focus (jimm is already looking into similar but more serious issues with keyboard focus).
I had no problems until I upgraded to Firefox 4. Now, when I have multiple HTML pages open and Katmouse active, mousewheel scrolling usually doesn't work. Note "usually" - every now and again it comes good. If I disable Katmouse then all works fine. If I drag a page away from a tabbed group then it scrolls fine, and if I re-dock it then it will continue to scroll correctly - for a while. Katmouse is such a useful add-on which works flawlessly with everything else it's a total PITA having it not work in Firefox.
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 184.108.40.206; 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.
Seem to be the same as bug 273456.
This is a regression in Firefox 4, so it can't be a duplicate of bug 273456.
How do you know it is a new regression? No regression range found so far. OK, then comment 5 and comment 9 is bug 273456 and not this bug. If we reduce this to the report and comment 2, this bug is about the interaction with the Katmouse program. Do we want to support this? Then the title should be updated to mention the program.
Information from my comment on 626813: 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. I would be willing to work to narrow the regression window once I have some time, but it will be a while before I have the time, so someone else can work on it.
I apologize for the double post, but I just read this description more carefully, and it seems to me that the original post for this bug is describing something similar to (not necessarily a dupe of) bug 273456, where focus is not maintained in the expected tab. Bug 626813 describes an issue where the touchpad scrolling doesn't work with pdf tabs open, and the mouse wheel does.
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!
@meberbs Wait! 273456 deals with the KEYBOARD only. 543027, 594500, and 626813 deal with the MOUSE scrolling ONLY. 626813 says no touchpad scrolling/no mouse wheel open. Two different issues. My keyboard is working great: I can open a new tab using ctrl+t whether a PDF is open or not.
@Ibrahim I think it may be 3 issues. I have no problems with keyboard or mouse WHEEL other than temporary focus issues fixed by switching tabs and then switching back. My TOUCHPAD scroll will never work with a pdf open in the same window but a separate tab. This occurs even when the mouse wheel works perfectly, so it is different issue from that. 626813 specifies that it is a touchpad problem and seems to manifest in a different way. I never intended that 594500 or 543027 was the same as 273456, only that they may be similar issues. Both seem to have workarounds that do not involve closing the pdf or opening it in a different window. To be clear, FF beta 4 includes the bug that if I ctrl-click on a link to open a pdf in a new tab, keyboard shortcuts, mouse wheel scroll, and touchpad scroll all do not work, and it then returns to normal upon clicking on the pdf tab, then back to the original tab. The regression window between beta 4 and beta 5 I found only applies to the bug involving the touchpad.
When a pdf link is middle-clicked to open it in a new background tab, the scroll wheel scrolls the hidden pdf rather than the visible html tab. (Ctrl-P also prints the hidden pdf, keyboard arrows scroll the pdf, etc. So it seems all events other than left/middle/right click affect the hidden pdf.) Proper functionality is restored if you switch tabs, or even if you middle-click an html link to open it in a third hidden tab. This has been the case for at least two years through automatic-updated releases of FF and Acrobat on Windows XP and 7 with a real (non-touchpad) mouse without KatMouse or anything additional. Some of the comments above claiming it's only a problem on recent versions above might only apply to the touchpad issue.
Clicking play on an embedded YouTube videos also prevents the scroll wheel from scrolling the page, but at least this is fixed by left-clicking anywhere on the page. After a pdf link is middle-clicked on to open it in a background tab, even clicking on the original page doesn't restore scroll-wheel focus.
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 Beta 4 was 2010-08-24 and Beta 5 was 2010-09-07, so this fits perfectly into the timeline you mentioned alvaro. @alvaro Is this scroll wheel on mouse or touchpad? My scroll wheel works great, but it's my touchpad that's the issue. I can not get scrolling back on any non-PDF page if a PDF is opened in another tab: not on the status bar or address bar. Thanks in advance...hopefully, we are getting closer! :D
IGNORE MY LAST COMMENT. Sorry. :( This bug is about the mouse wheel scroll not working. My mouse wheel scroll works fine, PDF open or not. Apologies.
(In reply to comment #27) > Sorry. :( This bug is about the mouse wheel scroll not working. My mouse > wheel scroll works fine, PDF open or not. Since bug 626813 has been duplicated to this one in comment 16, this one here is about touchpad as well. Unless you want to revert the duplication, as bug 626813 comment 12 argues. I can confirm yet another case where the mouse scroll wheel works, but the touchpad scrolling does not. (Synaptics Touchpad using driver version 220.127.116.11 on 64bit Windows 7)
This issue (scrolling is not posible with pdf open in a separate tab https://bugzilla.mozilla.org/show_bug.cgi?id=644226) has not yet been resolved in firefox 5.0. I am currently using Adobe reader 10. Scrolling starts to work as soon as the tab containing pdf is closed.
I think, per bug 626813 comment 12, we should revert the duplication. These may be related, but they are separate. All right, I'm moving my response to 626813, as I have more information to update.
Any way to remove the duplication tag from 626813 that links to this bug? I sincerely think they are two different bugs. Related? Probably. But not the same.
So you want to take back your comment 20? What exactly has changed?
Yes! :) I wish to take back/delete/revert/obliterate my comment, 20. It was an error on my part; I did not read the comments carefully enough under each bug. This bug, bug 594500, deals with the MOUSE WHEEL (a physical mouse with a scroll wheel) being unable to scroll other tabs while a PDF tab is open. However, for myself and other users, we can plug in a mouse into our laptops and the mouse wheel fixes the problem with our touchpads (meaning with a mouse wheel, we can scroll with a PDF tab open, thus WE do not experience bug 594500). Bug 626813 deals with the touchpad. Scrolling with a touchpad (whether two-finger drag or drag along the edge of the touchpad) does NOT function in Firefox if a PDF tab is open. Using a mouse wheel to scroll works perfectly. The touchpad does not. Thank you for your reply, aceman! :)
You do not even see bug 273456 with the mouse attached?
No, none of the listed "How to Reproduce" steps in the comments reproduced the problem on my system with my external mouse connected (with touchpad enabled or disabled; I tried both situations). However, from bug 273456 comment 62 to bug 273456 comment 68, I DO experience those problems: these are all about scrolling with the touchpad. The keyboard focus issues that are mentioned in bug 273456, on the other hand, I do not experience those at all. I can CTRL+T or CTRL+W at any time without any of those actions being sent to the PDF.
(In reply to comment #35) > No, none of the listed "How to Reproduce" steps in the comments reproduced > the problem on my system with my external mouse connected (with touchpad > enabled or disabled; I tried both situations). > > However, from bug 273456 comment 62 to bug 273456 comment 68, I DO > experience those problems: these are all about scrolling with the touchpad. > > The keyboard focus issues that are mentioned in bug 273456, on the other > hand, I do not experience those at all. I can CTRL+T or CTRL+W at any time > without any of those actions being sent to the PDF. Did you try opening the browser(having pdf in separate tab) after connecting the external mouse? or did you connect the mouse while the browser was open?
@Shaunak Last time, I plugged the mouse in while the browser was open. This time, I closed the browser, plugged in the mouse, and tried again. Even switching to external applications and back, I cannot get "Ctrl+T" to do anything but open a new tab and "Ctrl+W" to do anything but close the current tab. What else should I try? I'd love to help troubleshoot, as I know how annoying little bugs like this can be. This is with both Adobe and Nitro PDF on Windows 7 64-bit Dell laptop. The mouse is a Razer Copperhead using default Windows drivers and the touchpad is a Synaptics v7.2 on 18.104.22.168 drivers.
Well, what do you know! Foxit PDF Reader actually works! Nitro PDF and Adobe PDF failed me, but Foxit works for touchpad scrolling! What about with the mousewheel?
This should be fixed by bug 273456 in tomorrow's nightly based on testing with the test case available in that bug.
We'll see... This was already considered dupe of 273456 but the consensus so far is that that is not the case.
(In reply to aceman from comment #40) > We'll see... This was already considered dupe of 273456 but the consensus so > far is that that is not the case. The description of this bug certainly fits. If we want to morph this into something else that's fine, we just need to nail down specific STR for the problem this bug revolves around.
This bug says its fixed but i still have the same problem in FF7. Is there a workaround for it? other than installing different PDF software? How come no ones even working on this bug even after 4 major releases. Is this intentional to discourage adobe pdf usage or something? :)
(In reply to malithyapa from comment #42) > This bug says its fixed but i still have the same problem in FF7. Is there a > workaround for it? other than installing different PDF software? > > How come no ones even working on this bug even after 4 major releases. Is > this intentional to discourage adobe pdf usage or something? :) it should be fixed by bug 273456 which is landed on FF9
i see :) thanks..
This bug says its fixed but i still have the same problem in FF8. All works fine until you open up a pdf in a tab, and then wheel scrolling stops on other pages.
And others have complained, http://support.mozilla.com/en-US/questions/818325#answer-178536 but FF is still superior, and i thank God for it.
It is supposed to be fixed in Firefox 9 (now in beta). Please comment only if you see it in anything newer than that
I apologize for not keeping up with this bug; I unfortunately have not had time. Well, I just updated to Firefox 9 and remembered this was the version the bug was supposed to be fixed in. Right: I uninstalled Foxit, reinstalled Adobe, and launched Firefox. Bug is still present in Firefox 9.0 final. :(
Could you please try on Firefox 10 beta, it seems I do not see it there. But I only have a normal mouse with wheel (no touchpad).
AS i do not want to lose functionality due to extns not being FF10 ready, i will wait a a while before trying FF10. Thanks for your efforts to fix this.
You can try it temporarily just to test this and then revert back. Also, most extensions on addons.mozilla.org working with FF9 are already made compatible with 10. I am using Aurora 10 daily. We need enough testers that confirm this is not fixed in 9 or 10. Then we can revert comment 39, that just guessed this is fixed by bug 273456.
FF 9 solved the problem for me but I'm not using Adobe PDF plugin but SumatraPDF plugin (which also triggered the exact same problem until FF9).
I downloaded what was sppsd to be 10, but the file is http://pv-mirror02.mozilla.org/pub/mozilla.org/firefox/releases/9.0b6/win32/en-US/Firefox%20Setup%209.0b6.exe, and installs (i did a separate install) as 9.0, at least that is what Help>About says.
And testing for far shows that the issue is fixed. Good job,
The builds can be downloaded here: http://www.mozilla.org/firefox/channel/ . But I see you are right, they have probably not switched them yet. The page shows beta is 9.0.b6 and Aurora is 10.0a2. It probably needs some days. Anyway, if FF9 final (on the same page) works for you then you are set and don't need 10Beta. My comment was aimed at Ibrahim and others who may find FF9 does not fix it for them.
Right, I just saw that 10 is still in the Aurora channel. Downloading "firefox-10.0a2.en-US.win32.installer.exe" now.... :) Richard (comment 83 here: https://bugzilla.mozilla.org/show_bug.cgi?id=626813) has this problem on FF 9.0 as well.
Bug is still present on 10.0a2. :( Who confirmed that this fix worked? From my perusal of the comments, it was assumed by someone that this bug fell under 273456 (though no one confirmed that, at least no one actually with this problem). This bug is NOT fixed by the fix implemented for 273456. I think some people who had 273456 thought they had this bug automatically, but I think they are different. Do we need to go back a few steps? Here's the regression window from Firefox 4.... Last good nightly: 2010-08-27 First bad nightly: 2010-08-28 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124 The post I made in the 273456 about a regression window does NOT apply to that bug, but to this one. I confused the bugs myself, too. :( 626813 and 594500 = these seem to be duplicate bugs.
Exactly. It is only assumed (in comment 35) that this was fixed under bug 273456. There is no evidence. So I'd like people to test this and confirm this is NOT fixed. I have no problem to reopen this then.
But bug 626813 contains reports mostly about laptop touchpads on Win 7. This one is about mouse scroll wheel (on various Windows, even XP). It may be the same problem, but it is not proven so far.
Oh, gosh. Well, if I attach a mouse, the scroll wheel works perfectly (and it always has). See comment 35. My bug concern, then, is 626813: I have a touchpad on Windows 7! Unfortunately, then, my posting about it not working should be considered a false negative. For those of you with this problem, the bug fix may have worked.
Yes, there are some similar reports in these 3 bugs, but some even conflicting or unclear. I understand the confusion it may cause, it becomes a mess. So we need to stay calm and have clear reports after Firefox 9 was now released. There was already a positive comment 55.
Hi I find that the post says that the Bug is fixed but I am using Windows 7 and Firefox 10.0.2 and I still am facing the issue. How can this be fixed?
Sorry found the new bug 626813 https://bugzilla.mozilla.org/show_bug.cgi?id=626813#c121 which deals with my issue. Thank you.
Issue is resolved - clearing old keywords - qa-wanted clean-up