user input -- mouse queuing flaw

[Jordan Brinkman]

I have noticed that Ubuntu does not queue user input commands as precisely as Windows. In earlier versions of Ubuntu, I would have to press Shift well before typing the letter I wanted uppercase. However, this appears to have been fixed.

The problem I still see is that when the user wants to drag a UI element, for example a file or to drag a window via it's titlebar, the "click" part of the click-and-drag operation is not always registered before the "move" (drag) part of the operation (when performed rapidly). The result is that the mouse-click will be registered by the OS somewhere along the drag operation, with sometimes unexpected results. The behavior seems worse when there is a load on the machine. (In Windows, for example, user input commands seem to be precisely queued and sent to the OS in the order they were received, regardless of load)

[David Siegel (djsiegel-deactivatedaccount)]

Can you please list steps to reproduce this behavior?

[daniel (bocardo+u)]

Have had this happen to me as well. It's quite simple to reproduce. Just start dragging as soon as you can when you click.
Unfortunately, most people get used to this and unconsciously delay the dragging a moment to avoid it. It's most visible if your window border is thin (like a one pixel border). Happens on every system I've tried, both desktop and notebook, with USB and PS2 mice.

[daniel (bocardo+u)]

By the way, I've seen this documented somewhere else on the web (unfortunately I can't remember where, but the language (queue) was the same "mouse input queue" or something similar). I believe it even happens on other distrubutions.

[Vish (vish)]

This seems to be a genuine bug.Thank you for bringing this bug to our attention.

Also , from the last comment , it seems there is no easy fix for this., Hence until someone can say there is a easy/quick fix , this is incomplete.

A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

Don't worry though, This bug has been marked as "incomplete" ONLY in the papercuts project.

For resolution of the bug, kindly identify the projects affected and assign the bug to that project, otherwise the devs of the concerned project might not be notified of this problem. For more about finding the right package> https://wiki.ubuntu.com/Bugs/FindRightPackage.

[Jordan Brinkman (jordanbrinkman)]

I understand that because it is not an easy fix, it is not valid for the papercuts project. Thank you for taking a look at this one. And sorry for the repeated comparisons to Windows, that was not my intention.

[daniel (bocardo+u)]

This bug appears to only happen on X. Unfortunately I still can't find the article where I first read about this.

[KennoVO (kenno-xs4all)]

Ever since I switched to Ubuntu, this flaw has been annoying the daylight out of me. I'm a very fast mouse user, and I trigger the bug tens of times each day while dragging small targets such as window borders (ie. resizing windows) and bookmarks in Firefox. This has already lead to annoying accidents, such as: trying to enlarge a window but instead picking up a file from the desktop and dropping it into some folder on the desktop, or in Firefox, trying to create a bookmark by dragging the icon left of the URL into a bookmark folder, but instead moving a bookmark folder into another bookmark folder. If there's anything that would make me abandon Linux, this would be it.

As for assgining the bug to a project, the problem is, it's not easy for an end-user to discern whether this is a Gnome bug or an X bug or perhaps even something deeper in the operating system. X seems the most likely culprit. Is anyone on this thread using KDE or XFCE or any other window manager than Gnome? If yes, the bug probably should be assigned to the X project.

[daniel (bocardo+u)]

As I mentioned before, I'm pretty sure it was described as a bug in X´s mouse input handling code. Unfortunately, since English is not my native language, I can't remember more than I already wrote here.

[daniel (bocardo+u)]

And to KennoVo's question, this has happened to me both with KDE and XFCE but don't use them as often as Gnome, so it could be just miss-clicking on my part.

[huug (dsjarw)]

This pesky bug is still present in Karmic.
For workaround see:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/54191
It seems to be related to 3 mouse button emulation

[KennoVO (kenno-xs4all)]

Thanks huug for posting the workaround. What a relief!

Looking at the workaround, fixing this seems trivial (ubuntu's install scripts should no longer add "Emulate3Buttons" to xorg.conf unless a a 2-button mouse is detected). Thus, it qualifies as a "papercut". Changing status back to "confirmed".

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
Is this bug reproducible with the latest Lucid packages ?
Tanks in advance.

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

[Fabio Marconi (fabiomarconi)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[daniel (bocardo+u)]

While I don't have the expertise to pinpoint which package is the one affected by this bug, I can at least deduce from it happening both on other distros and Ubuntu derivatives as well as KDE and XFCE too, that it is a bug in X. The workaround posted would support this conclusion, but I can't be certain and don't know how to verify it. If there is some kind of procedure I could follow to find out, please post it here and I'll try to follow it. At the moment all I have access to is a Linux Mint installation on my girlfriends laptop because I recently replaced my old laptop and the new one doesn't work well enough to even have as a secondary OS. I could try a live USB or the livecd on a virtual machine (vmware player)

[daniel (bocardo+u)]

As a favor, could someone tell me how fluent in English I appear to be based on my posts?
Thanks

[KennoVO (kenno-xs4all)]

@Fabio Marconi: I finally succeeded in installing Lucid (had some technical problems doing so and not a lot of time to experiment). The bug is now present when freshly starting X, but disappears as soon as the user presses the middle mouse button. You could have known this by looking at the Xorg bug of which this one is a duplicate
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/54191
(see post #10; just to make this 100% clear for other people, I'll try to mark this bug as a duplicate).
I personally use the middle mouse button so frequently (for pasting) that after installing Lucid, I didn't even notice the bug was still there, but there may be other users who don't use their middle mouse button so much and still have problems.

@daniel: judging by what you wrote, your written English is probably better than a significant percentage of native English speakers (at least here in the USA). I would classify your fluency as "advanced" to "near-native". Don't reply to this to thank me; this is a site for reporting bugs and there's no place for off-topic stuff.