Closed Bug 1359226 Opened 8 years ago Closed 8 years ago

Mousewheel action over Firefox doesn't work if Firefox window is not active

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
53 Branch
Platform:
Unspecified
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1182700

People

(Reporter: lobugs, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170414000000 Steps to reproduce: After a while, but not following any patterns, Firefox does not respond to mouse wheel scrolling. This started with Version 53. Prior to that there were no problems. If I Alt-Tab to another window and back to Ffx again, scrolling works - at least for a while. There are no steps to reproduce it - it happens intermittently. You scroll your mouse wheel, and nothing happens. OS: openSUSE 42.2 KDE, Firefox 53.0-2.1 (x86_64 form the Mozilla repo, but I have seen it on Windows 7 64bit once or twice as well. Additionally, but I do not know if this problem is related, the latest Versions of both Firefox (V 53) and Thunderbird (Version 52.0.1-2.1 x84_64, from the OBS Mozilla repo) have stopped responding to mouse wheel scrolling if they are not the active window. All versions prior to that responded to mouse wheel scrolled if the mouse pointer hovered over the Ffx or TB window regardless of whether Ffx/TB was the active window - as is common on Linux. I do not know if that is related: Actual results: 1) Intermittently, you scroll your mouse wheel, and nothing happens, even if Ffx is the active window. 2) Ffx no longer responds to mouse scrolls if it is not the active window, even if the mouse cursor hovers above the Ffx (or TB) content pane. Expected results: 1) You expect the mouse wheel to scroll the page. 2) In Linux, you expect the mouse wheel to scroll content even in a window that is not active if the mouse cursor hovers over the content.
Component: Untriaged → Panning and Zooming
Product: Firefox → Core
How long does it take before this problem starts appearing? i.e. does it happen soon after you open the browser, or does it happen only after you've been browsing for a while?
Flags: needinfo?(gustav.ostner)
Usually starts after a while, and alt-tabbing to another window and back - even another ffx window - repairs it. It never starts immediately after starting up the browser.
Flags: needinfo?(gustav.ostner)
I would ask you to run mozregression to narrow down when this started happening, but if it takes a while to reproduce and is intermittent then that won't produce very reliable results (and will take a long time). I think the next step here would be to make a build with extra diagnostics information and have you run that for a while. Would you be willing to try that? If so I can make the build.
Flags: needinfo?(gustav.ostner)
yes, why not, as long as it installs in /opt
Flags: needinfo?(gustav.ostner)
After my mouse started acting up, I replaced it, and that seems to have repaired all my problems in Firefox and Thunderbird as well. Firefox and TB just seem to be more susceptible to a bad mouse than the rest of my programs and the DE (KDE). When I first had problems in Ffx and TB, I had no problems in any of my other programs.
Scrolling in Ffx no longer stops working intermittently, scrolling in TB windows that are NOT the active window also works again. What does NOT WORK is that Ffx windows that are not the active window do not scroll when a mouse cursor hovers over the window and I scroll the wheel. All my other programs do that.
Ok, in that case let's morph this bug to cover the second issue. What window manager are you using?
OS: Unspecified → Linux
Summary: Firefox intermittently stops scrolling with mousewheel → Mousewheel action over Firefox doesn't work if Firefox window is not active
My window manager is kwin5, version 5.8.6-7.1 from the main openSUSE update repo.
Component: Panning and Zooming → Widget: Gtk
The main Ffx scrolling problem is back, but I've only had it twice in ~ 2.5 hours. Both times it seemed to be triggered by restoring the minimised Firefox window by clicking on the Ffx button in the Plasma window list at the bottom of the screen, but even so, it does not happen every time you restore Firefox. Sorry to be coming back like this.
No worries. I made the build with logging to try and help diagnose the problem. Please do the following: 1. Go to https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b574ba23933216107194a2fa4787f4112d88bf4 2. Click on the green "B" for either the 32-bit ("Linux opt") or 64-bit ("Linux x64 opt") build. 3. In the Job Details pane that appears, there should be a line that says "artifact uploaded: target.tar.bz2". Click on the target.tar.bz2 link to download the build. 4. Unpack the target.tar.bz file, it should expand to a firefox folder which contains the build. 5. While you can run the build directly by running the firefox binary inside the folder. I suggest that you create a new profile for testing this build, so as to not interfere with any existing Firefox settings you may have. You can do this by: 5a. Run the firefox binary with the -P flag to get the profile manager window, click on the button to create a profile, and follow the steps. 5b. After creating the profile, hit "Exit" on the Profile Manager window 6. Then, run the firefox (with the new profile, if desired), while redirecting the output to a file: ./firefox -P <profile-name> 2>&1 | tee firefox-output.log 7. Use the build until you see the problem, and then note the current date/time (a UNIX timestamp, such as obtained by `date +%s` would be best). This will help me identify where in the log file to look. 8. Terminate firefox and attach the firefox-output.log file to this bug, along with the timestamp. Thanks!
I'll do that tomorrow after work.
I've tested the Ffx 55a nightly for an hour or so, and so far no problems. This seems to have fixed both problems: 1) intermittent mouse wheel scroll fail in Firefox content pane. 2) Mouse wheel scroll fail if Firefox is nit the active window. Concerning 1) this needs some more testing. Since I replaced the mouse, the problem has become much less frequent, so it may be too early to say it's completely gone. Concerning 2) - I am very pleased. The question remains - has 55 fixed a bug in 53 or is the GTK runtime that came with your build so different from the one in openSUSE 42.2 that the openSUSE one affects Firefox - but only from version 53? Anyway - thanks for the all the work and a great browser! Is there anything else I can do except using the nightly build for a while longer to see how everything works out?
If you use mozregression with the "active window" problem, it should be fairly easy to find the change that fixed this. We might be able to uplift it to beta and get the fix out faster.
How do I do that?
See http://mozilla.github.io/mozregression/ You will want to use that tool to test builds. Since the issue is fixed in Nightly, you want a reverse regression range (aka a fix range), so mark builds which have the inactive window scrolling issue as "good" and the builds which have the issue fixed as "bad". Start with something like 2017-02-01 as the start of the range, that should be somewhere in the 53 nightly timeframe.
mark builds which have the inactive window scrolling issue as "good" the builds which have the issue fixed as "bad" Do I understand this correctly - the (good=fixed) one as "bad", the (bad=not yet fixed ones) as "good"? Something like mozregression --good 2017-02-01 and then mozregression --good 2017-02-02 etc, until it is fixed? and finally mozregression --good 2017-xx-yy --bad 2017-aa-bb where 2017-xx-yy is the last one with the problem, and 2017-aa-bb the first fixed one?
No, if you run "mozregression --good 2017-02-01" (just once) it will start running builds and prompt you whether they were good or bad. Test the builds and respond to the prompts as I described in comment 16.
OK
What did I do wrong? mozregression --good 2017-02-01 0:00.30 INFO: No 'bad' option specified, using 2017-05-03 0:04.54 INFO: Testing good and bad builds to ensure that they are really good and bad... 0:04.54 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2017/02/2017-02-01-11-00-31-mozilla-central/firefox-54.0a1.en-US.linux-x86_64.tar.bz2 ===== Downloaded 100% ===== 1:12.02 INFO: Running mozilla-central build for 2017-02-01 1:21.49 INFO: Launching /tmp/tmpPnEpLl/firefox/firefox 1:21.49 INFO: Application command: /tmp/tmpPnEpLl/firefox/firefox -profile /tmp/tmpqqwktP.mozrunner 1:21.50 INFO: application_buildid: 20170201110031 1:21.50 INFO: application_changeset: 1d025ac534a6333a8170a59a95a8a3673d4028ee 1:21.50 INFO: application_name: Firefox 1:21.50 INFO: application_repository: https://hg.mozilla.org/mozilla-central 1:21.50 INFO: application_version: 54.0a1 Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): bad 5:59.39 ERROR: Build was expected to be good! The initial good/bad range seems incorrect.
The above build (54a) did not have the problem, so this was supposed to have been "bad", no?
(In reply to GO from comment #21) > The above build (54a) did not have the problem, so this was supposed to have > been "bad", no? Correct. So this means one of two things: either (a) we didn't go back far enough (i.e. try 2017-01-01 instead of 2017-02-01), or (b) the problem never manifested on Nightly, but only showed up after 53 left Nightly. If that's the case it would probably be good to check a recent aurora build and beta build to see if they have the problem. It could be that we have some different configuration on nightly builds that are suppressing the problem there. You can download the latest aurora build from [1] and the latest beta build from [2]. [1] http://archive.mozilla.org/pub/firefox/nightly/2017/05/2017-05-03-07-47-55-mozilla-aurora/ [2] http://archive.mozilla.org/pub/firefox/releases/54.0b4/ - use the "linux-i686" folder for 32-bit builds, or "linux-x86_64" for 64-bit builds, and then pick the locale you want
Both 54.0a2 and 54.0b4 are OK - no scrolling problem.
Thanks! That likely means it was option (a) - we didn't go back far enough. However, it also means that Firefox 54 release should be OK, so there's no point in doing anything further here. Even if we did find a fix it would be purely to satisfy curiosity - the fix is already in 54 so there's nothing we can uplift or speed along.
Yep - I think I can live with that bug for another 3 to 4 weeks :-) Thanks for your work.
The not-scrolling-without-Alt-Tabbing bug is back with Firefox 53, but it has only happened once since THU because I use "Developer Edition 54.0a2 (2017-05-03) (64-bit)" mostly now, which continues to be fine.
Considering that the 54 and up are fine, I'm going to close this bug as worksforme. If you run into the issue on 54 or newer versions, please comment here and/or reopen the bug. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Original reporter back: The bug is NOT present in the Firefox 54 and 53 from the Mozilla website, nor in the 52.2 from the openSUSE main repo. It is, however, present in both the 53 and 55 versions from the openSUSE Mozilla repo. So the bug must be caused by some changes (code, buildflags, ...) where the openSUSE team do not use the same settings and/or code as the Mozilla team. Unfortunately, I do not know how to file a bug against an oS repo that is not part of the main distribution.
If the issue is only present in the openSUSE distribution of Firefox but not the mozilla-produced Firefox builds, then you need to file a bug against the openSUSE port. We don't maintain or support third-party rebuilds.
I see the similar behaviour (bug 1390184) on openSUSE with firefox 55. Was this reported downstream?
Downstream added: export MOZ_USE_XINPUT2=1 to the start script. If I comment it out, it works again. So it this a GTK, plasma or Firefox issue?
(In reply to jiri slaby from comment #33) > Downstream added: > export MOZ_USE_XINPUT2=1 > to the start script. If I comment it out, it works again. So it this a GTK, > plasma or Firefox issue? We explicitly keep MOZ_USE_XINPUT2 off by default because behaviour is buggy when it is turned on. The code is at http://searchfox.org/mozilla-central/rev/13148faaa91a1c823a7d68563d9995480e714979/toolkit/xre/nsAppRunner.cpp#3850 and references a couple of bugs. From the discussion in those bugs it's still not clear to me whether this needs to be fixed in Firefox or elsewhere. Some of the comments seem to imply it affects other apps as well, not just Firefox, which would make it a GTK issue most likely. But I'm not sure.
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.