XFCE window buttons are not clickable at the top of the screen

[Sean Davis]

This bug affects greybird-gtk-theme and xfce4-panel in Xubuntu Cosmic.

With Cosmic, it is not possible to click on the window buttons after moving the mouse cursor to the top of the screen. Unlike similar bugs, no amount of moving left or right triggers the hover event or the ability to click on the window button.

With Adwaita and Numix, we see the same issues we see elsewhere, where the buttons can sometimes be clicked, but also have issue with the topmost part of the screen.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: greybird-gtk-theme 3.22.9-0ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
CurrentDesktop: XFCE
Date: Sat Sep 29 09:05:24 2018
InstallationDate: Installed on 2018-09-29 (0 days ago)
InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Beta amd64 (20180929)
PackageArchitecture: all
SourcePackage: greybird-gtk-theme
UpgradeStatus: No upgrade log present (probably fresh install)

[Carlos Garnacho (carlosg)]

On gnome-shell, if I run xinput test-xi2, side-maximize it on the left by dragging the window to the left edge, the window will end up aligned to the left screen edge. However, moving the pointer towards that edge will sometimes issue events like:

EVENT type 6 (Motion)
    device: 2 (16)
    detail: 0
    flags:
    root: -0.86/139.21
    event: -0.86/75.21
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: -0.86
    windows: root 0xd6 event 0x4600001 child 0x0

As can be seen in https://bugzilla.gnome.org/show_bug.cgi?id=756463 , this negative coordinate fools GTK+ into thinking it should synthesize crossing events as those happen.

[Alquimista-ds (alquimista-ds)]

It has been reported that it affects windows placed to the left and top of the screen. I just want to add that it's affecting panels (maybe it's the same thing. Is it?) The wingpanel of elementary OS doesn't always recognize the pointer passing over and clicking, same with Budgie's top panel and MATE's. Unity works fine, and so does Cinnamon and Gnome.

I've tested on three absolutely different machines. All affected. Does it affect all users? Why isn't this getting the proper attention...

Most importantly right now, is there a workaround? Can I replace this version of Xinput?

[Alquimista-ds-e (alquimista-ds-e)]

This bug will die with Xorg. No activity. No reports elsewhere. No way to set a bounty on it. Wayland is not affected, it seems.

[Adam Purkrt (adam-purkrt-deactivatedaccount)]

Xfce4-panel 4.13 and higher - the new version relying on gtk3 - is hit by this too. Really annoying.

[Adam Purkrt (adam-purkrt-deactivatedaccount)]

Created attachment 136946
app with button in the top left corner

A simple application based on gtk3 with a button in the upper left corner. Move the mouse pointer along the screen edge near the top left corner of the screen and watch as the button gets selected and deselected, randomly (changes shade). It should always be selected, when the mouse is over it. This is not always the case.

Something really should done about this bug, it is a major annoyance.

[Adam Purkrt (adam-purkrt-deactivatedaccount)]

Created attachment 136974
effect of the bug on menu in MATE desktop

Video demonstrating the bug in MATE destkop. The item under mouse cursor is not always selected. Also, the blinking is the result of this bug.

[Egmont Koblinger (egmont-gmail)]

(In reply to Douglas from comment #1)

> Why isn't this getting the proper attention...

(In reply to Adam Purkrt from comment #4)

> it is a major annoyance.

I can totally feel your pain, guys. I love Linux and open source and stuff, but there are a couple of things I truly dislike, one of them being usability annoyances getting way lower attention than they'd deserve. I'm not talking about X.Org in particular, it's across all the pieces. If it was me, I'd say such bugs are release critical. Devs usually say these are minor.

(In reply to Douglas from comment #2)

> No way to set a bounty on it.

How many beers would you have paid? :-)

[Egmont Koblinger (egmont-gmail)]

Created attachment 136979
Fix

After 4 hours of debugging a totally unknown source, here's a fix that works for me. Could you guys please test it?

It's against 1.19.5 because I recompiled my distro's packages and that's the version my distro ships. I hope it still more or less applies against git master.

There are two things to the story, and I think either segment of my patch fixes the issue, but it's probably better to have both parts in place.

One is an ugly use of trunc() instead of floor(). trunc() rounds towards zero, and as such, with slightly negative (temporary??, before clamping??) mouse coordinates, root_x_frac becomes negative (e.g. a value of -0.6 is stored as root_x = 0, root_x_frac = -0.6, as opposed to root_x = -1, root_x_frac = 0.4 which would be the logical, following the pattern of the rest of the code with the FP1616 and FP3232 data types).

Another is that at certain places, root_x is set to a certain value, but root_x_frac remains unchanged, still containing the previous value. This is probably how the previous negative fraction can leak to places it shouldn't.

[Same for root_y and root_y_frac, of course.]

My patch (especially this latter part, resetting root_x_frac whenever root_x is set) may not be complete, and I have a slight feeling that my patch still doesn't address the real root cause. I'm not sure about it.

Meta:

I think I've done my fair share to fix this issue, I won't have any more time to work on it. Douglas, Adam, could you please nag the devs on mailing lists and such if they don't notice this patch here in a reasonable time? It should be a piece of cake for them to polish this up and commit based on my findings.

[Adam Purkrt (adam-purkrt-deactivatedaccount)]

Thank you very much Egmont for your time. Just testing the patch against 1.19.6 (it is also applicable to current git version). So far so good. I will try to post a short memo of this bug at xorg-devel, hopefully it will get some notice.

[Adam Purkrt (adam-purkrt-deactivatedaccount)]

Testing a bit more, I found it is not necessary to substitute trunc with floor; the patch works when only the part setting root_x_frac and root_y_frac to zero is left in.

[Jason Gerecke (killertofu)]

Gave this a quick test in the hopes that it might fix (or at least improve) bug 92186. Unfortunately, it looks like all this does is just result in the loss of fractional coordinate data, causing errors to increase slightly across the board. E.g., the first row of the table in the linked bug would now report a root coordinate of "164.00" making the delta from expected "-3.70" instead of "-3.00".

[Egmont Koblinger (egmont-gmail)]

Jason, I'm sorry to hear that my patch makes another bug a bit worse. My patch consists of two parts, either one is sufficient to fix this bug here. Could you please maybe try which of its two parts cause that regression?

Taking a quick look at that other bug, you seem to be much more familiar with this topic and the intended behavior than I am. Either you or some other X.Org developer should take a closer look, I'm afraid I'm unable to further help, it would require much more time than I can voluntarily devote to this issue.

Both parts of my patch fix a "code smell", where the code was just fishy, didn't fit in with the rest of the picture. As I already mentioned, I had a guts feeling that I did not address the core issue, I mean why does that number become negative in the first place?

There must be levels of architectural complexity that I'm totally unaware of... But just looking at the overall picture: Handling the motion of a value within a certain interval causes problems, really?? Just sounds totally ridiculous.

While my patch makes your bug even somewhat worse, it at least fixes one of the two bugs, so still it's not obvious whether it's more useful or more harmful to apply it on its own.

[Daniel Stone (daniels)]

A few suggestions.

Firstly, Xorg patches are reviewed on the mailing list (<email address hidden>), with patches sent through git send-email; you might want to try that to get some more attention.

Secondly, the changes to CheckVirtualMotion() seem like they would drop fractions on the floor in too many cases. Presumably we only want to do that when the co-ordinates actually hit the limits, rather than unconditionally drop the fractional component even when it's within bounds.

One way to do that would be an explicit check against the limits, and only set ev->root_* to the sprite co-ordinates if they're out of bounds. Alternatively, you could make the sprite's HotSpot struct actually carry the fractional parts as well. I would have a slight preference for the latter, but am not involved in Xorg or review anymore, so if anyone else suggests otherwise, you're probably better off listening to them. :)

I'm curious about the changing of rounding from trunc() to floor(). Previously, -0.86 would be expressed as (0, -0.86), and this changes it to (-1, 0.14). It's not necessarily a bad change, but it is a user-visible one and I'm curious why it's necessary or better.

You might also want to put some tests for negative co-ordinates in test/xi2/protocol-eventconvert.c or similar.

[Rafael Kitover (rafaelkitover)]

Any news about this?

I just hit this bug here:

https://bugs.launchpad.net/bugs/1757209

[Launchpad Janitor (janitor)]

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

[Simon Steinbeiß (ochosi)]

I guess you noticed this already but the problem only occurs at 0x0, so with a panel on the left or a panel on the top of the screen.
The behavior is fine with panel on the right or lower side of the screen.

That's why I would say it's not related to theming at all, potentially not even the panel...

[Simon Steinbeiß (ochosi)]

In fact if you debug the panel a bit you'll see that the enter-notify and leave-notify events are constantly firing with a panel at 0x0 and behaving correctly on the other screen edges.

[Simon Steinbeiß (ochosi)]

Ok, so a bit further down the debugging road I know that this issue is related to libxinput2.
I noticed that the enter/leave-notify events were firing because the panel's extents start at 0x0 but moving the pointer towards the top of the screen in combination with the sub-pixel handling of xinput2 produces negative coordinates, e.g. -0.6185, so a leave-notify event is fired, even though the panel should not have lost focus.

If you export "GDK_CORE_DEVICE_EVENTS=1" the problem goes away (this switches to the gtk2 style input instead of xinput2).

[Simon Steinbeiß (ochosi)]

So obviously this is a known bug and literally every panel-like application is affected. It also seems there is no good solution so far apart from the aforementioned workaround of switching away from xinput2 via the environment variable.

[Simon Steinbeiß (ochosi)]

I have written a patch that employs the only known/reasonable workaround so far for the issue within xorg: https://git.xfce.org/xfce/xfce4-panel/commit/?id=e56e8699e271cea209f5b283421952d9035ad2b5

This commit could be pulled into Ubuntu at very low risk.

[Daniel van Vugt (vanvugt)]

If there is still a Xorg bug here then please log it upstream here:

  https://gitlab.freedesktop.org/groups/xorg/-/issues

and tell us the new bug ID.

[Daniel van Vugt (vanvugt)]

Sorry, I see you already did that on bugs.freedesktop.org.

[Launchpad Janitor (janitor)]

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

[Ubuntu QA Website (ubuntuqa)]

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

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

[Simon Steinbeiß (ochosi)]

Not sure it's helpful to add all panel-like applications that are affected by this problem to the bugreport - unless of course you want to track which applications implemented the same workaround (which seems to be the only known workaround anyway - if you don't want to intercept X11's signals manually).

Let me formulate the bug more generally:
All windows with coordinates of 0x0 have issues with xorg believing the cursor leaves the window because the lower boundaries are not clamped to integers. Instead the subpixel rendering of xinput2 results in those negative coordinates I mentioned before. I'm convinced *all* applications have this problem and I've discussed about the topic with the Gtk+ developers as well. One of the upstream bugreports even contains a small reproducer that is not a panel at all.

[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/577.

[Sean Davis (bluesabre)]

The new upstream url for the Xorg bug is https://gitlab.freedesktop.org/xorg/xserver/issues/577

[Sean Davis (bluesabre)]

This issue is resolved with greybird 3.22.10-1 and xfce4-panel 4.13.4-1

[Iain Lane (laney)]

(Those tags just make the bug drop off our desktop team report, don't worry about it)

[Launchpad Janitor (janitor)]

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

[Douglas Silva (o-alquimista)]

This bug was fixed in Xubuntu 19.04, if I remember correctly. But on later releases it became reproducible again.

I'm currently running Xubuntu 20.04, and most of the widgets on the top panel are affected, with the exception of Whisker menu icon (sometimes), the task switcher and the Notes widget icon.

[pqwoerituytrueiwoq (pqwoerituytrueiwoq)]

Confirmed in 20.04 with screenshot, weather applets, and notification area applets
whiskers menu, clock, and show desktop are unaffected

[pqwoerituytrueiwoq (pqwoerituytrueiwoq)]

Reason for "Won't Fix"?

[Simon Steinbeiß (ochosi)]

It's "Won't fix" only for the component xorg, because it won't/can't be fixed in that component.

The fix has already landed in the relevant package (xfce4-panel).

[pqwoerituytrueiwoq (pqwoerituytrueiwoq)]

Awesome!
Any idea when it will land in the ubuntu groovy repos?
Just pulled it into my 20.04 install and it seems to not be there yet
$ xfce4-panel --version
xfce4-panel 4.14.4 (Xfce 4.14)

Copyright (c) 2004-2011
 The Xfce development team. All rights reserved.

Please report bugs to <http://bugzilla.xfce.org/>.

[Brian Murray (brian-murray)]

Ubuntu 18.10 (Cosmic Cuttlefish) has reached end of life, so this bug will not be fixed for that specific release.