Scrolling behaviour and window focus has changed and is inconsistent

[Lem]

I wasn't sure which package to file this bug against, but seeing as it's a general desktop usability/consistency bug, the top level desktop environment seemed like a good target.

On Ubuntu 13.10, AMD64, everything default (Unity 7 on X.org etc), except for installing nvidia-319-updates, all current packages as of now (2013-10-17; unity 7.1.2+13.10.20131014.1-0ubuntu1), I now have this behaviour which is different from Ubuntu versions up to 13.04, and, is also inconsistent within itself. Here's what I've found:

The scrolling behaviour has changed, and seems to be different per application in Ubuntu 13.10.

The old behaviour (up to 13.04): mouse pointer above window would allow scrolling, regardless of focus
Apps that use the old behaviour: libreoffice, firefox, gnome-terminal

The new behaviour (13.10): window must be focused, and pointer hovered above to allow scrolling
Apps that use the new behaviour: nautilus, gedit, ubuntu-bug, software-updater

STEPS TO REPRODUCE

1. Open gEdit, press enter until the window is scrollable.
2. Open Firefox, go to a webpage that's scrollable.
3. Place gEdit above Firefox but off to the right side so gEdit's scrollbar is still visible, have gEdit focused.
4. Position mouse pointer above gEdit, observe scrollwheel causes gEdit window to scroll.
5. Move mouse pointer above Firefox but do not focus Firefox, observe scrollwheel causes Firefox window to scroll.
6. Focus Firefox, leave pointer above Firefox, observe scrollwheel causes Firefox window to scroll
7. Move mouse pointer above gEdit but do not focus gEdit, observe scrollwheel FAILS to cause gEdit window to scroll.

This behaviour is the same with any combination of the above apps (libreoffice, firefox, gnome-terminal all scrollable as long as pointer is above them; nautilus, gedit, software-updater, ubunut-bug will not scroll unless focused *and* have pointer above them)

What *SHOULD* happen, is that any window will scroll as long as the pointer is above it. That's how it's always been in Ubuntu.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: unity 7.1.2+13.10.20131014.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Thu Oct 17 22:12:18 2013
InstallationDate: Installed on 2013-09-30 (17 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Beta amd64 (20130925.1)
MarkForUpload: True
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

[Christopher Townsend (townsend)]

Hi Lem,

Thanks for reporting this bug. I believe this is due to some changes in scrolling behavior in Gtk+3.0. I've been trying to work with the Gtk+3 upstream to fix some mouse wheel issues, but it's slow going.

[Christopher Townsend (townsend)]

BTW, I'm not a Gtk dev (I'm actually a Unity/Compiz dev), but these mouse scrolling issues are affecting some functionality in Compiz, hence my interest in this.

Also, if you're feeling adventurous, you could try a test package in my PPA that might fix this issue. It's ppa:townsend/gtk-testing.

[Lem (lem-jjr)]

Hi Chris, I added your PPA, did an apt-get upgrade, rebooted, and the issue as described above is fixed. Nice work :)

For the record, I had to reboot for everything to work correctly. I tried logging out/in before rebooting, which did fix the scrolling issue, but I noticed I'd lost the time/date indicator, and the logout option didn't seem to work. Shutdown did though. I'm guessing some conflicting libraries in memory or something, which the reboot fixed.

[Christopher Townsend (townsend)]

Hi Lem,

Thanks for confirming that my Gtk test package fixed this.

As far as the time/date indicator, that is a known crash that is being worked on by a different team. Fortunately for me, that is an unrelated issue:)

[Jan Rathmann (kaiserclaudius)]

@Christopher
I just reported a duplicate of this bug ( #1242451 ) and I have tested your PPA, it indeed fixes the scrolling behaviour for me, much thanks for your effort!
I filled the duplicate errornously against Compiz, because it first seems I couldn't reproduce with other WMs, but after seeing that this is considered to be GTK3 issue, I tried more window managers and found out that IceWm is also affected - so it really seems to be not related only to Compiz.

[Žygimantas Beručka (zygis)]

I had this issue to, but the package in your ppa fixed it. Thanks!

By the way, wouldn't it be reasonably to push your patched version into the official repos so that other folks would get the fix without having to swim trough google or launchpad first?

[Christopher Townsend (townsend)]

I don't have the power to push my change to the repos. That said, I have a patch proposed to upstream Gtk, but those maintainers did not immediately accept my patch. Supposedly, they were going to do some more debugging, but I have not seen anything. Since upstream does not seem very motivated to fix this, something needs to be done in Ubuntu and I will try to convince someone of this:)

[Lem (lem-jjr)]

Chris, you're a gentleman. Next time I see someone whinge/troll about "Canonical never helps upstream", I'll think of you.

[Christopher Townsend (townsend)]

Are people affected by this bug using any special mouse wheel bindings such as switching workspaces using the Viewport Switcher plugin in Compiz? I'm trying to understand what could be triggering this for different users.

Thanks!

[Hồng Quân (ng-hong-quan)]

Yes. I configured to use scroll wheel to switch workspaces.

[Žygimantas Beručka (zygis)]

Christopher, nothing fancy in my case, it's basically a default Unity configuration with just the workspace switcher turn back on.

[Jan Rathmann (kaiserclaudius)]

Christopher, I can't remember that I use any special mouse bindings. I
can reproduce this bug also within a clean guest session, so this seems
not be a problem with special/custom settings. The chosen graphics
driver (Nouveau vs. Nvidia propritary) also doesn't matter on my system.

Am 22.10.2013 15:58, schrieb Christopher Townsend:
> Are people affected by this bug using any special mouse wheel bindings
> such as switching workspaces using the Viewport Switcher plugin in
> Compiz? I'm trying to understand what could be triggering this for
> different users.
>
> Thanks!
>

[sanmiguel9 (againsttcpa84)]

@Christopher: this bug even appears in a LiveUSB-session with Ubuntu 13.10. That's about as vanilla as it can be ;-)

[Doug McMahon (mc3man)]

Just want to add that with bindings set to 'scroll on Desktop' & the known issue with a certain gtk commit reverted that this is not an issue, scrolling on any unfocused window works correctly
(maybe another reason to revert or subvert that commit

[Žygimantas Beručka (zygis)]

Chris, a recent GTK3 update (3.8.6-0ubuntu2) from the saucy-proposed overrides your version and pinning the right version is quite a hassle since it requires downgrading of quite a number of packages. Would you be so kind to build a newer version with your patch included?

It's a pity upstream doesn't pay any attention to this bug even though you have a working patch. Wouldn't it be wise to include the patch into the official Ubuntu packages then?

[Hồng Quân (ng-hong-quan)]

Chris,

With your patch, I cn scrool with mouse wheel but I cannot scroll with touchpad anymore.

[Vassili Platonov (vassilip)]

@Christopher: be so kind please, keep your ppa up to date, at least to 3.8.6.
I don't use any special mouse wheel bindings such as switching workspaces using the Viewport Switcher plugin in Compiz. Just default, moreover, this bug was revealling after clean install of trusty. I can't scroll on inactive nautilus or gedit windows.
But it seems that gtk+3.0 in trusty is the same in saucy though.

[Christopher Townsend (townsend)]

Update: My patch was essentially rejected in that it pretty much accomplishes reverting the fix for bug #1046988. I chatted with an Ubuntu dev about this issue and he was of the opinion that a fix is needed that doesn't revert the original fix and also fixes this issue. I don't disagree, but it doesn't seem upstream Gtk+ is motivated to fix it and I'm not sure how to fix it, so it looks like we are stuck for now:(

I'm not going to keep up my test PPA, but Doug McMahon has one for Saucy that reverts the original fix and can be found here: ppa:mc3man/test-scroll

[Lem (lem-jjr)]

I actually found an annoying use case for this bug last night: clicking on LP bug links in changelogs in the Software Updater. I had the Updater pinned above Firefox, but of course every click on an LP bug link caused Firefox to become focused, so I had to click on Software Updater again to make it scrollable, almost defeating the purpose of having it pinned above Firefox anyway (I like to open a bunch of links as I browse the changelogs, then read them later).

[Francesco Tarantini (fraxav88)]

I have the same problem with Evince in 13.10. I also noticed that this doesn't happen when I use my laptop's touchpad (I have side scrolling enabled via Unity Tweak Tool). No special binding assigned to the scrollwheel (just a "bring window to bottom" for middle button click on titlebar).

[Sebastien Bacher (seb128)]

Upstream commited what they think is a fix for the issue:
https://git.gnome.org/browse/gtk+/commit/?id=4168c3cab9cb17bb4c75bd2f60c13c149afbf29c

It would be nice if somebody having the issue could try if that really fixes it for them (I've never been able to reproduce/notice the said bumpy scrolling here so I can't really test)

If you do that, backporting https://git.gnome.org/browse/gtk+/commit/?id=962415aeb7e9e47f61c006a5d817a15d181c5055 as well would be useful (it gives extra debug infos, which might be useful if somebody still get the issue)

[Christopher Townsend (townsend)]

I tested the patch and it does not fix this issue. I provided upstream with debug output and will help them any way I can to solve this.

[Jan Rathmann (kaiserclaudius)]

For me this patch also also doesn't fix the problem regarding the inability to scroll in inactive windows with mouse-wheel. The only thing that helped so far in this case are the patched packages from Christopher's PPA, as mentioned in comment #3.

Kind regards,
Jan

[Carlos Garnacho (carlosg)]

If a client (normally a reparenting WM) sets a passive button grab and it is triggered when the pointer is above another client's window (eg. a WM-managed window), crossing events will be rightfully generated, however XI2 crossing events in the second client don't contain the expected mode, XINotifyPassiveGrab/Ungrab would be appropriate here, but XINotifyGrab/Ungrab are used instead.

[Carlos Garnacho (carlosg)]

2 Patches are now on xorg-devel,
http://lists.x.org/archives/xorg-devel/2013-November/039220.html

[Christopher Townsend (townsend)]

Adding xorg-server since that is the missing piece. There are some patches proposed for upstream xorg-server that does fix this issue in my testing. Hopefully they will be accepted soon and then we can get them into Ubuntu.

[Christopher Townsend (townsend)]

Hi Carlos,

I tried these patches. Coupled with the Gtk+ fix, this does indeed fix the various scrolling issues! Hopefully the patches will be reviewed/accepted soon.

Thanks a million for addressing this!

[Peter Hutterer (peter-hutterer)]

Do you have a test case for this? I knocked up a simple one with two XI2 clients, one creating a window with enter/leave on a window, one with enter/leave on the button grab on the root window. Neither client gets an event and a printf in the server shows nothing is written onto the wire either (only the button event to activate the grab).

If I change to an active grab + ungrab, I get the events correctly.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+3.0 - 3.10.6-0ubuntu2

---------------
gtk+3.0 (3.10.6-0ubuntu2) trusty; urgency=low

  * debian/tests/build: update to not use gtkstock which is deprecated,
    the warning is making the autopkgtest unhappy
 -- Sebastien Bacher <email address hidden> Wed, 11 Dec 2013 10:52:41 +0100

[Vassili Platonov (vassilip)]

Can't see any changes in mouse-wheel's behavior in trusty. However, edge scrolling with touchpad works as required.

~$ egrep -i 'mouse|synap' /proc/bus/input/devices
N: Name="Logitech USB-PS/2 Optical Mouse"
H: Handlers=mouse0 event4
N: Name="SynPS/2 Synaptics TouchPad"
H: Handlers=mouse1 event11

xserver-xorg - 1:7.7+1ubuntu6
xserver-xorg-input-mouse - 1:1.9.0-1
xserver-xorg-input-synaptics - 1.7.1-0ubuntu1
gir1.2-gtk-3.0 - 3.10.6-0ubuntu2

[Christopher Townsend (townsend)]

Hi Vassili,

This still requires a fix to xorg-server for the whole fix to be complete and the patch is still waiting to be ack'd upstream.

[Christopher Townsend (townsend)]

Is there an ETA on when the patches are going to be merged into master?

[Peter Hutterer (peter-hutterer)]

Please see the follow-up post here:
http://lists.x.org/archives/xorg-devel/2013-December/039346.html

[Christopher Townsend (townsend)]

Since the proposed patches to X have been rejected, what can be done here to fix this properly?

[Rocko (rockorequin)]

IMHO, this is quite an annoying regression.

Just in case it's not obvious what the effect is, there are steps to reproduce it at https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1240957: you just have to run two apps like gnome-terminal and nautilus and try using the mouse wheel to scroll them. nautilus no longer scrolls with the mouse wheel unless it has focus, whereas gnome-terminal always scrolls. Scrolling without requiring focus has always been one of the nice things about X desktops, and now it's inconsistent and broken.

[Walter Ribeiro (wribeirojr)]

The problem is still present in 14.04.

[mamunabms (mamunabms)]

I wonder when we'll get rid of this annoying bug.
:(

[Walter Ribeiro (wribeirojr)]

It's hard to believe a LTS version is about to be released without a solution to this bug.

[Sebastien Bacher (seb128)]

> It's hard to believe a LTS version is about to be released without a solution to this bug.

The bug doesn't impact the default configuration, the solution/workaround is easy "don't bind scroll events to workspaces changes"...

[Rocko (rockorequin)]

> The bug doesn't impact the default configuration, the solution/workaround is easy "don't bind scroll events to workspaces changes"...

Sorry, but I don't understand what you mean by that: do you mean there is an easy solution/workaround that a user can apply? Or that because the solution is easy it won't be released for the LTS?

[Givrix (geoffrey-mosini)]

I disagree with Sebastien Bacher, the bug is present by default even on the live cd and in my config no scroll event is bound at all.

[Sebastien Bacher (seb128)]

@Givrix: then maybe that report mixes different issues :/

[Lem (lem-jjr)]

Thanks for responding Sebastien. This bug isn't about switching workspaces with scroll events, it's about being able to scroll windows with a mouse that aren't in focus. Basically, it works with a touchpad (all windows are able to scroll without focus), but not with a mouse scrollwheel.

The default X desktop behaviour since forever has been to be able to scroll any scrollable window that the pointer is hovering above, regardless of whether it's in focus or not.

For the record, I've been affected by this bug even today, where I wanted to have two gEdit windows open side by side, and had to keep focusing the windows to scroll them, whereas normally I'd just hover over one window and scroll it while editing the other with the keyboard.

This bug is also a regression from Ubuntu 12.04.. so might be more important if you have a bunch of 12.04 LTS users upgrading next month.

[Sebastien Bacher (seb128)]

> This bug isn't about switching workspaces with scroll events

Well, it used to happen only with that configuration, it seems like things changed. It might be because unity grabs those events to use them when you scroll over launcher icons

> This bug is also a regression from Ubuntu 12.04.. so might be more important if you have a bunch of 12.04 LTS users upgrading next month.

It's already important, but if you read the upstream comment it's not an easy to fix one...

[Kuangting Liu (168-l)]

This bug has made me to switch from Unity to Gnome desktop. It works perfectly fine with Gnome. Hopefully it will get fixed soon.

[Lem (lem-jjr)]

Just did some testing (with two gEdit windows) this morning, Ubuntu 14.04 updated to the latest packages as of today (2014-04-01). I apt-get installed ubuntu-gnome-desktop and kubuntu-desktop on a regular Ubuntu 14.04 install.

GNOME desktop (gnome-shell): Both gEdit windows can be scrolled with the pointer hovering over the window, regardless of focus.
GNOME desktop classic (I guess still gnome shell?): Same as GNOME desktop, scrolling works while hovering, regardless of focus.
KDE plasma desktop: gEdit window needs to be focused to be scrolled
Ubuntu Unity desktop: gEdit window needs to be focused to be scrolled

And on Ubuntu 14.04 (around beta 1 packages) on a netbook with a touchpad and mouse connected: Nautilus windows can be scrolled with the touchpad while hovering, regardless of focus, but NOT with the mouse.

So, what makes the gnome-shell desktop different to Unity and KDE? The X server, GTK etc are all the same.

[Sebastien Bacher (seb128)]

> So, what makes the gnome-shell desktop different to Unity and KDE? The X server, GTK etc are all the same.

The difference is in technical details of the window manager. The issue also only happens if you are grabbing the scroll events to do something with those, it might be that gnome-shell doesn't do that (while unity uses scrolling over the launcher to cycle through applications for example)

[Lem (lem-jjr)]

A bit more testing (all on Ubuntu 14.04 as of 2014-04-01).

XFCE4 (apt-get install xubuntu-desktop): Windows get focused on scroll events, so this bug could not be tested there. Couldn't easily find a setting to turn that off (I assume it's buried somewhere though). Nautilus, gEdit, mousepad all scroll normally, but of course they all are focused and brought to the top of the window stack on the first scroll event. FWIW, mousepad installed on Ubuntu 13.10 under the regular Unity 7 desktop scrolls without focus just fine. I noticed it's a GTK2 app.

KDE: Kate scrolls without focus, but gEdit does not. (just had to check whether KDE native apps had a similar issue).

So it's basically GTK3 apps when not running under Gnome-Shell, and only with a mouse scrollwheel but not a touchpad, that have this issue with unfocused scrolling.

[VPablo (villumar)]

On Ubuntu 13.10 with Mate-Desktop (1.6) also gedit does not scroll if pointer is not over the scroll bar but pluma scrolls normally. Mate is on 14.04's repositories (but 1.6, not 1.8).

[Lem (lem-jjr)]

Chris, your PPA you mentioned in https://bugs.launchpad.net/compiz/+bug/1192028 for testing the compiz nVidia 50Hz refresh bug also seems to have fixed this scrolling issue. Great work!

For those not subscribed to the other bug, Chris' PPA is https://launchpad.net/~townsend/+archive/compiz-test .. I suspect it wont be around for long though, since these fixes should make it into the mainstream distro packages.

[Jan Rathmann (kaiserclaudius)]

@Christopher
The Compiz update for Trusty fixes the bug for me, thanks!

[Lem (lem-jjr)]

For the record Chris, the scrolling issue with GTK3 apps (only tested gEdit) is still present under KDE/KWin (makes sense since you fixed this from within Compiz, so I guess more a workaround?). Perhaps it would be nice to give the KWin guys a heads up on how you fixed this with Compiz so maybe they could do the same with KWin?

[Doug McMahon (mc3man)]

re-broken in 14.10 with compiz 1:0.9.11+14.10.20140606-0ubuntu1, at least on a laptop with usb mouse -
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1330198

[VPablo (villumar)]

In 14.04 still works, it might be a regression.

[Michael Marley (mamarley)]

This is still happening on Kubuntu 14.10. GTK3 applications like Synaptic won't scroll unless they are focused.

[Stephan Sokolow (ssokolow)]

Still affecting KDE users on 14.04 LTS.

Here's a workaround I found on the KDE bug tracker:

cat > ~/.kde/env/fix_gtk3.sh << EOF
#!/bin/sh
export GDK_CORE_DEVICE_EVENTS=1
EOF
chmod +x ~/.kde/env/fix_gtk3.sh

Source: https://bugs.kde.org/show_bug.cgi?id=348270#c26

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/566.