Wingpanel items not always open/close when clicking the corner or edge of the screen

[malpaw]

The Wingpanel is supposed to obey Fitts's law. For instance, the Application menu should open not only when the user clicked directly the "Application" label, but also when clicked the screen corner or edge next to the label. This behavior works in ~50% of the cases, i.e. sometimes clicking the screen corner or edge does not cause any effect. Clicking again couple of times, even without moving the mouse, would finally trigger the desired action (open/close Application menu, open/close date and time widget etc.)

Also, compare https://bugs.launchpad.net/wingpanel/+bug/1380366

Installed packages (up-to-date Loki):

libwingpanel-2.0-0:amd64                       2.0.3~r184-0+pkg33~ubuntu0.4.1.1
wingpanel                                      2.0.3~r184-0+pkg33~ubuntu0.4.1.1
wingpanel-indicator-ayatana                    2.0.3+r27+pkg17~ubuntu0.4.1.1
wingpanel-indicator-bluetooth                  2.0.2+r89+pkg18~ubuntu0.4.1.1
wingpanel-indicator-datetime                   2.0.1+r166+pkg10~ubuntu0.4.1
wingpanel-indicator-keyboard                   2.0.2+r87+pkg20~ubuntu0.4.1
wingpanel-indicator-network                    2.0.2+r212+pkg12~ubuntu0.4.1
wingpanel-indicator-notifications              2.0.1+r156+pkg13~ubuntu0.4.1.1
wingpanel-indicator-power                      2.1.1+r218+pkg12~ubuntu0.4.1
wingpanel-indicator-session                    2.0.1+r105+pkg9~ubuntu16.04.1
wingpanel-indicator-sound                      2.0.5+r163+pkg11~ubuntu0.4.1

[peteruithoven]

I can't reproduce this issue anymore. If this still happens please report which indicator this happens with and include a screen recording.

[jlnr]

This keeps happening to me on a fresh install of the 2023-08-29 Daily ISO. In the video below, I keep moving my mouse and clicking. At some pixel positions, the clicks just don't do anything.

Screen record from 2023-08-30 13.28.17.webm

I'm not sure if it matters, but this is on an Nvidia system. It happens in the application menu, the date/time button in the middle, and on individual indicators.

I have added some debug logs and the mouse button events don't arrive on the Wingpanel.PanelWindow. I thought that maybe some coordinates are broken, but that's also not it. Moving the mouse around and clicking other places "unblocks" some coordinates that were previously blocked. I suspected that some leftovers of the previous popover might swallow my events, but even after a fresh start of Wingpanel, the very first click fails sometimes.

[jlnr]

When I run xwininfo from a terminal and then click somewhere at y=0, sometimes the next click works as expected, sometimes it doesn't. The output is always the same, though. So it doesn't seem that any other app is blocking my clicks.

jlnr@Workstation:~$ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x2600003 "io.elementary.wingpanel"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 3840
  Height: 30
  Depth: 32
  Visual: 0x82
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x2600002 (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-1570  +0-1570
  -geometry 3840x30+0+0

[jlnr]

Running Wingpanel with GDK_DEBUG=all also shows that the mouse clicks arrive in Wingpanel. It is the same window ID no matter if the click works or not.

I am new to fractional mouse coordinates, but I notice that GDK_DEBUG sometimes prints -0.98 as my Y coordinate. Shouldn't the minimum be 0.0?

Indeed, it looks like all clicks with x<-0.5 or y<-0.5 fail, presumably because they get rounded to -1.

[jlnr]

I am not sure how the mouse x/y integers from the X11 ButtonPress event end up being fractional values in the corresponding GTK event. Maybe someone else knows? Is it worth digging into this with Wayland on the horizon? :thinking:

Edit: Seems to be an X11 thing, xinput test-xi2 --root also shows fractional negative coordinates when things don't work.

[danirabbit]

Either way this sounds like an upstream issue. I don't think there's anything we can do about mouse click coordinates being reported as being off screen...

[jlnr]

As a workaround, I was thinking that maybe the Wingpanel window could be extended one pixel to the left/top/right when there is no adjacent screen, so that it starts at (-1, -1). I'm not even sure how many people are affected by this, though. Might not be worth it.

I have a pretty standard Logitech mouse and a single-screen setup. I thought that maybe it was somehow caused by the 125% font size (since it's a non-standard setting), but I could also reproduce it at 100%.

I did find this Budgie issue from someone (using Nvidia drivers too) which could be related...or maybe not. https://github.com/solus-project/budgie-desktop/issues/1925

[danirabbit]

Ah yeah, Nvidia drivers have been known in the past to have some really ridiculous issues like this :grimacing:

[jlnr]

One recent comment in https://github.com/elementary/applications-menu/issues/390 stated that it can also happen with Intel drivers.

The issue goes away when I set the pointer acceleration to "None", so it could be related to whatever drives this preference.

[danirabbit]

Might be LibInput then?

[jlnr]

Further up I was confused why the logged X11 events have fractional mouse coordinates when the X11 struct XButtonPressedEvent uses ints. Turns out that xinput test-xi2 command logs XIDeviceEvent coordinates, which are fractional.

I think libinput only sends events for relative mouse motion (LIBINPUT_EVENT_POINTER_MOTION) when not using a touchscreen or some other device that uses absolute coordinates. If it's something on the X.org side of things, it is probably not realistic to fix the root issue.

[jlnr]

From some quick testing, it looks the workaround I suggested above would work. Placing wingpanel at (x, y) = (-1, -1) makes it react to mouse events at x = -0.62, y = -0.99 etc.

~This must only happen when there is no screen (directly) above/to the left of the current one, otherwise the extra pixel will be visible there. (I cannot reproduce this issue on the right edge of the screen.)~

~Is this extra complexity something that would be accepted in wingpanel, considering that not a whole lot of people have complained about this issue so far? update_struts already has code to check for adjacent monitors, but it would have to be moved around.~

Never mind, placing wingpanel at negative Y coordinates just stopped working for me (not visible at all).

[jlnr]

The one thing about libinput that I don't yet understand is why disabling mouse acceleration makes the issue go away. If it is something in libinput after all, then it would be more worthwhile sending a patch than for X11.

[jlnr]

The negative coordinates also show up in xinput test-xi2 in an AMD/KDE environment (Steam Deck), but it looks like KDE (Qt?) reacts to clicks at y<0.5 when there is a panel at the top of the screen.