Regression: Enabling typical bindings in "Desktop-based Viewport Switching" breaks scrollwheel scrolling in some windows with a usb mouse on a laptop

Bug #1200829 reported by Doug McMahon on 2013-07-13
178
This bug affects 37 people
Affects Status Importance Assigned to Milestone
Compiz
Medium
Christopher Townsend
GTK+
Fix Released
Medium
X.Org X server
Confirmed
Medium
compiz (Ubuntu)
Medium
Christopher Townsend
gtk+3.0 (Ubuntu)
Medium
Unassigned
xorg-server (Ubuntu)
Medium
Unassigned

Bug Description

Test Case:
On a laptop connect a usb mouse (using a logitech wireless "Anywhere mouse mx" here
Enable theses Desktop-based Viewport Switching binding's
Set prev & next to typical settings, (next = button 5, prev = button 4

Try to scroll in any of these windows using the mouse scroll-wheel -
nautilus
gedit
synaptic
dconf-editor
help (Ubuntu Desktop guide
Software-updater > details
'Open files' window
sidebar windows in RB & totem
preferences in audacious
There could be a few more

On the other hand many others work ok, short list -
Dash
Scroll on Desktop
gnome-terminal
libreoffice-writer
ccsm
all browsers
preferences & playlist in vlc

Note all of the no scroll apps work fine with touchpad scrolling
Have tried disabling the touchpad, ect. to no avail

Related to this bug, same workaround to alleviate
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1184159

Commit reverted packages for 13.10 are here
https://launchpad.net/~mc3man/+archive/test-scroll

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: compiz 1:0.9.9~daily13.04.18.1~13.04-0ubuntu1
ProcVersionSignature: Ubuntu 3.10.0-2.10-generic 3.10.0
Uname: Linux 3.10.0-2-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.10.2-0ubuntu4
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
Date: Fri Jul 12 23:46:16 2013
DistUpgraded: Fresh install
DistroCodename: saucy
DistroVariant: ubuntu
GraphicsCard:
 NVIDIA Corporation G86M [GeForce 8400M GS] [10de:0427] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Dell Device [1028:0209]
InstallationDate: Installed on 2013-06-23 (20 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130621)
MachineType: Dell Inc. XPS M1330
MarkForUpload: True
PackageArchitecture: all
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=c6ab7418-5252-48e1-b7ab-cc21291285f4 ro quiet splash
SourcePackage: compiz
UpgradeStatus: No upgrade log present (probably fresh install)
XorgConf:
 Section "Device"
         Identifier "My Graphics"
         Driver "nouveau"
         Option "GLXVBlank" "on"
 EndSection
dmi.bios.date: 12/26/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A15
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA15:bd12/26/2008:svnDellInc.:pnXPSM1330:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: XPS M1330
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.9~daily13.04.18.1~13.04-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.45-2ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.1.4-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.1.4-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.14.1-0ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.8-0ubuntu1.1

Related branches

Doug McMahon (mc3man) wrote :
Doug McMahon (mc3man) wrote :

As it turns out this 'bug' doesn't yet exist but will if the only currently proposed upstream patch to fix this current bug is applied -
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1184159

I'll note this in that bug as another reason not to consider it.

Doug McMahon (mc3man) wrote :

I'm going to take the above comment back to some extent though this bug & the above are interconnected.

The current gtk3 includes an upstream commit to fix this bug - (xi2: Reset scroll valuators on synthesized crossing events
https://bugzilla.gnome.org/show_bug.cgi?id=690275

That commit combined with the prev & next bindings being set in Desktop-based Viewport Switching as previously described causes this bug & also causes jerky scrolling as described in bug 1184159

I can confirm that here by installing the gtk3 packages from here which reverts the xi2: Reset scroll valuators on synthesized crossing events commit
https://launchpad.net/~mc3man/+archive/test-scroll/+packages

Doug McMahon (mc3man) on 2013-07-14
description: updated
summary: - Regression: Enabling "Desktop-based Viewport Switching" breaks
- scrollwheel scrolling in some windows with a usb mouse on a laptop
+ Regression: Enabling typical bindings in "Desktop-based Viewport
+ Switching" breaks scrollwheel scrolling in some windows with a usb mouse
+ on a laptop
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1200829

tags: added: package-qa-testing
The Minder (theminder) wrote :

Effects me too

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz (Ubuntu):
status: New → Confirmed
Doug McMahon (mc3man) on 2013-09-28
description: updated
Doug McMahon (mc3man) on 2013-09-29
Changed in compiz:
status: New → Confirmed
Doug McMahon (mc3man) wrote :

Well if you don't have the resources in compiz to fix & this will adversely affect a fair number of users then reverting the causative commit in gtk+ should be considered.

Changed in gtk:
importance: Unknown → Medium
status: Unknown → Confirmed
Christopher Townsend (townsend) wrote :

I'll take a look on the Compiz side about what can be done.

One thing that is interesting is that if you put the mouse pointer to the scrollbar and then use the scroll wheel, it will work. Perhaps we are just missing an event now...

Changed in compiz:
status: Confirmed → In Progress
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)
Doug McMahon (mc3man) wrote :

Please also note (if missed in prev. comments) that this bug is also related
 bug 1184159

Yep, I saw that, thanks!

After some debugging and looking over the vpswitch plugin code, I really fail to understand how this is the fault of the plugin. When the binding is in place, the code does some checking to make sure the mouse pointer is over the desktop window and if not, just return false. Nothing of significance has changed in this plugin for some time.

I tried your test-scroll PPA and it does indeed fix this issue, so that is even more evidence that this is a Gtk issue. It seems https://bugzilla.gnome.org/show_bug.cgi?id=703062 is the real root of this issue. The patch that fixed that has been merged upstream and we need to get it into Ubuntu as well.

Changed in gtk:
importance: Medium → Unknown
status: Confirmed → Unknown

Sorry for the misinformation in my last post. I got totally confused by the diff in your PPA and thought it was the padding that fixed this, but that is already in Ubuntu. I was just trying to figure out exactly what was reverted in your PPA that makes this work again.

I still do suspect it's a Gtk issue in that it doesn't like how Compiz does the scroll binding.

Doug McMahon (mc3man) wrote :

Chris -
for the ppa I'm simply just reverting the orig. gtk commit, the diff shown on ppa would also inc. changes to gtk from previous version
So attaching current patch here for info sake
(the orig. upstream bug that caused this is
https://bugzilla.gnome.org/show_bug.cgi?id=690275

The attachment "fix-scroll.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch

Thanks Doug. I'm trying some extra fixes to the reverted part of the patch with hope that this can be solved without reverting that whole code block.

Doug McMahon (mc3man) wrote :

Hopefully you find a solution.
If not then I think the orig. bug that caused this commit should be considered against the current state. Myself cannot dupe the behavior as described here -
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1046988

Doug,

I think I have a fix in Gtk. I seems to work locally. I'm building a package in ppa:townsend/gtk-testing.

Do you think you can try that package out (once built/published) and see if it works for you as well? If it works well for you, then I'll propose this, but since we are at final freeze, I'll see about this being a 0 day SRU.

Thanks!

Changed in gtk+ (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)

On 10/10/2013 02:42 PM, Christopher Townsend wrote:
> Doug,
>
> I think I have a fix in Gtk. I seems to work locally. I'm building a
> package in ppa:townsend/gtk-testing.
>
> Do you think you can try that package out (once built/published) and see
> if it works for you as well? If it works well for you, then I'll
> propose this, but since we are at final freeze, I'll see about this
> being a 0 day SRU.
>
> Thanks!
>
Works good here.
1. Wireless mouse scrolling works in all windows
2. Scrolling in large files, synaptic, ect. seems pretty good

Thanks for the attention & work

Doug,

Thanks for confirming.

Doug McMahon (mc3man) wrote :

So I believe this could also be considered a fix for the other bug (jerky scrolling..

Changed in compiz:
status: In Progress → Invalid
Changed in compiz (Ubuntu):
status: Confirmed → Invalid
Changed in gtk+ (Ubuntu):
status: Confirmed → In Progress
Changed in compiz:
assignee: Christopher Townsend (townsend) → nobody
affects: gtk+ (Ubuntu) → ubuntu
affects: ubuntu → gtk+3.0 (Ubuntu)
Matthieu Baerts (matttbe) wrote :

Hello Christopher,

Yes, I confirm that resetting scroll valuators for only 'slave' devices (GDK_DEVICE_TYPE_SLAVE) fixes the bug #1184159

Thank you for this patch :-)

I have submitted the patch upstream. If/when that gets accepted, I'll work with the Distro team on getting it into 13.10 as an SRU.

no longer affects: compiz (Ubuntu)
Changed in gtk:
importance: Unknown → Medium
status: Unknown → Confirmed

I chatted with a Gtk dev about my proposed upstream patch and he said what I basically did was cause the behavior to act like the previous behavior before his patch. I don't know enough about Gtk,, so I'll trust he knows what he's talking about. He also said he would try looking into this more, so we'll see what happens. If I don't hear anything soon-ish, then I'll ping Distro about what to do with the original commit that broke this.

Doug McMahon (mc3man) wrote :

Hopefully it works out somehow. Probably more important to get squared away for 14.04 which I gather may be the last of unity7 & compiz, so it would be nice to go out on a high note.

Just to mention if it comes down to revert the commit or not.
This commit was applied late in 13.04 dev & then reverted before release even though at that time the actual cause was not known
(eg. enabling the bindings..

So 13.04 does not include this commit in gtk & I've not noticed any new bugs or added to orig. bug report that lead to the commit in the first place.
And as mentioned I can't dupe the orig. bug no matter how hard I try. (I believe the orig. was on 12.04, even there I can't dupe.

kylea (kylea) wrote :

Thanks Doug - applied your ppa and it works fine

Thanks from me too Doug !

I am bitten by this subtle and rather annoying bug . Hoping yours or Chris Townsend (from Bug #1184159) patch will be included in an updated gtk package soon.

For the record I have a bluetooth Logitech M555b mouse.

b_b (brunobergot) wrote :

Hi and thanks for the patchs provided, unfortunately libgtk-3.0 3.8.6 is available in saucy proposed repo and this one doesn't include one the patch :\

Doug McMahon (mc3man) wrote :

On 11/02/2013 06:04 AM, b_b wrote:
> Hi and thanks for the patchs provided, unfortunately libgtk-3.0 3.8.6 is
> available in saucy proposed repo and this one doesn't include one the
> patch :\
>
normally I would not upload new package until moved from proposed to
updates. In this case have used the new gtk source for some time, both
in 13.10 & 14.04 so will go ahead.
give it a few hrs. to build & publish

description: updated
b_b (brunobergot) wrote :

Thanks a lot for the update @mc3man :)

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

Doug McMahon (mc3man) wrote :

well I guess leave as is & see how it plays out over the next 5 months. Hopefully a dual fix will arise.

While i don't think one can make any absolute judgement on users affected by a bug report, dupes, number affected, ppa use, ect., it does seem many more are affected by the current fix then orig bug. (and should increase in a lts release

Currently there are 3 Ubuntu releases where the orig. bug is still active, 12.04, 12.10, 13.04 & one release where it was fixed, 13.10
The orig. bug has no dupes & 11 affected
Two ppa's that revert the commit for 13.10 show 136 total as seen thru ppastats (not sure whether ppastats is cumulative or for current build, no matter really ..

Changed in gtk:
status: Confirmed → Fix Released
Sebastien Bacher (seb128) wrote :

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)

(@Doug: that current bug has 16 affected users and no duplicate, it's also happening in non standard configuration where the other bug was changing the scrolling position in an annoying way by default ... anyway let's try to fix the issue rather than discuss which bug is the less annoying to users)

Doug McMahon (mc3man) wrote :

On 11/18/2013 04:15 AM, Sebastien Bacher wrote:
> 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)
>
>
> (@Doug: that current bug has 16 affected users and no duplicate, it's also happening in non standard configuration where the other bug was changing the scrolling position in an annoying way by default ... anyway let's try to fix the issue rather than discuss which bug is the less annoying to users)
>
As I mentioned yesterday in the other bug report associated with this
the upstream commit does not fix either bug.
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1184159

As far as the debug code I don't know how to use it. I currently have a
new 14.04 install that has a patched gtk ( both commits) if there is
some advice as how to do so.

Bug #1240957 is also a fallout of the original fix. I provided upstream with debug output and hopefully they will continue working on this to get a proper fix for all conditions.

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.

I'm removing myself as the Gtk+ assignee since my proposed patch is no good and upstream is also actively working on this. Also moving this back to the triaged state.

Changed in gtk+3.0 (Ubuntu):
status: In Progress → Triaged
assignee: Christopher Townsend (townsend) → nobody
Sebastien Bacher (seb128) wrote :

upstream GTK seems to have a pretty good understanding of the issue and fixed the GTK side but it relies on an xserver fix as well

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.

Changed in gtk+3.0 (Ubuntu):
status: Triaged → Fix Released
Changed in xorg-server (Ubuntu):
status: New → Triaged
importance: Undecided → Medium

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!

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Doug McMahon (mc3man) wrote :

Can also confirm the 2 patches fix all 3 scrolling bug here, (applied to 1.14.3-5ubuntu1 source, trusty
(this bug, the jerky scrolling bug & scrolling in an unfocused window
Haven't noticed any unintended consequence as of yet

Doug McMahon (mc3man) wrote :

A small note concerning proposed xorg commits.
While they do fix all 3 bugs it seems to create one new very limited bug in 14.04 -
With a usb mouse nautilus will crash when opening folders on the desktop thru a double l. click.
(nautilus crashed with SIGABRT in g_assertion_message()

Doesn't occur from context menu or from d. tap on touchpad, just from mouse
Hopefully when/if there is an xorg fix it won't occur

b_b (brunobergot) wrote :

Thanks a lot @mc3man libgtk-3-0 3.8.6-0ubuntu3+mc3man1 0 from your ppa bring back my mouse wheel functional :)

Hop to see this patch coming soon in 13.10.

Sebastien Bacher (seb128) wrote :

@Doug: thanks for the comment, could you open a new bug report with a gdb stacktrace for that issue?

@Doug,

That's strange, I'm not seeing that behavior on my 14.04 system. I'm using a USB wheel mouse w/ patches applied and a fully updated system.

Could you describe the exact steps you are doing to reproduce this or if you created a new bug, point me there if you have steps in it?

Doug McMahon (mc3man) wrote :

Chris - I opened here newly described,
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1257004
(new updated install, defaults only for compiz
added a couple of folders to Desktop *prior* to replacing xserver-xorg-core/common

After upgrade/restart the existing folders open fine
Any newly created folder after upgrade causes crash using d. left click on either mouse

Are there any ppa builds of a patched xserver I can try just to discount any local error?
(I had to build locally as 2 attempts in a ppa always failed/hung on i386, amd64 was fine

If a gdb is needed let me know, I'll give it a try..

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.

Doug,

I'm still not seeing the Nautilus crash you are seeing even after creating a new folder on the Desktop and left double clicking it. I don't think anyone has a patched xserver in a PPA. I can try uploading it today to my PPA.

Have you tried downgrading your xserver packages and see if the crash still occurs?

Sebastien Bacher (seb128) wrote :

@Chris: see the new bug report he opened, it seems a valid stacktrace in the new codepath, I've upstream the issue

Doug McMahon (mc3man) wrote :

I may be mis-interpreting this, - if so sorry
While the xorg dev (Peter Hutterer) did comment, "both merged, thanks.", (http://lists.x.org/archives/xorg-devel/2013-November/039228.html), don't see that they were yet thru 1.14.5
In the upstream bug he seems to be asking for a test case of the type I can't provide, if someone can may be worthwhile to do so.

Sebastien Bacher (seb128) wrote :

Their "merge" seems to be weird, I've asked the Ubuntu xorg team about that, they said that Peter has a tree where he merges stuff then it land updates in the main tree later on, not sure if that landing is blocked on have a test case though

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

affects me too on ubuntu 13.10 with a usb logitech mouse with xfce desktop only *in some gnome applications*. firefox works, though...

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

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) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Changed in compiz:
status: Invalid → In Progress
assignee: nobody → Christopher Townsend (townsend)
milestone: none → 0.9.11.0
Changed in compiz (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)
Doug McMahon (mc3man) wrote :

Thanks Chris for sticking it out. 2babacea-bab0-11e3-9cee-002481e91f22 is working well here in a short term test & resolves this & the other open bug

b_b (brunobergot) wrote :

Thanks a lot Chris \o/ Hope this patch will be merged soon.

Changed in xorg-server (Ubuntu):
status: Triaged → Won't Fix
Doug McMahon (mc3man) wrote :

Seems to cause the inability to focus Desktop once any window is open.
Immediate affect is the inability to rename a file on the Desktop if a window is open

Doug Barton (dougb) wrote :

WindowMaker had the ability to scroll desktops with the mouse wheel 15 years ago. Xubuntu has it now.

It is completely unclear to me what is preventing this being fixed in compiz.

Changed in compiz (Ubuntu):
status: In Progress → Fix Released
Changed in compiz:
status: In Progress → Fix Committed

My apologies if the bug tracker is the wrong place to post this, but thank you x1000 for fixing this. I've got desktop-based switching and gtk scrolling both working without patches/ppas for the first time in a long time. Great work!

Stephen M. Webb (bregma) on 2014-11-06
Changed in compiz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.