menu buttons don't respond (open/close menu) consistently to clicks

[whitwuv]

Expected behaviour

If a menu is closed and I click it's menu button, that menu should always open; if a menu is open and I click it's menu button, that menu should always close.

Actual behaviour

When a menu is open and I click it's menu button, it doesn't always close the menu; when a menu is closed and I click it's menu button, it doesn't always open.

I encounter this issue several times per day, since upgrading from Fedora 24 to Fedora 26.

Steps to reproduce the behaviour

For the issue where, when the menu is open, if the menu button is clicked, the menu doesn't always close:
place your mouse over a menu button and start clicking as fast as you can; you should notice that the menu spends most of the time open and isn't closing on every 2nd click

try the same in Fedora 24, and you will notice the menu button responds immediately to every click, opening or closing the menu, respectively

when does this issue come up? when user opens a menu but changes their mind, so tries to dismiss the menu by clicking the menu button again.

For the issue where, when the menu is closed, if the menu button is clicked, the menu doesn't always open (sometimes i'll have to click several times before it will open):
press your mouse cursor up against the very top edge of the screen when clicking the menu button (this is usually where my mouse falls when I click (since mouse has to go up there to unhide the panel (although autohide doesn't have to be enabled to reproduce))); start at the left of one of the menu buttons and click ... if the menu opens, click again to close it, then move the cursor a tiny amount to the right, still pressed up against the top of the screen and click again ... repeat as necessary until you find one of the "dead zones" where clicking doesn't do anything. for me, for example (using TraditionalOk theme (although the issue affects e.g. BlueMenta as well) and Bluecurve-inverse mouse theme, with Appearance Preferences->Fonts set to use "Subpixel smoothing (LCDs)", for the "Places" menu, if I line the left edge of the mouse cursor arrow up with the left edge of the "l", then move the cursor one pixel to the right, there's a dead spot. there are several more that seem to remain in the same general areas.

I encounter this issue daily with normal use.

this issue didn't occur in Fedora 24.

MATE general version

1.18.0

Package version

1.18.4

Linux Distribution

Fedora 26

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lukefromdc]

I was unable to duplicate this with mate-panel 1.19.3 from an August 23 git pull on Debian Unstable with GTK 3.22.19 and glib 2.53.6 locally built.

[raveit65]

I can reproduce it with f26 + latest build from master + code from open PRs. It seems that there are really some dead areas.
Menu is at top panel left side in fedora.

[raveit65]

Does debian use libinput driver?
With f26 we use libinput driver.

[lukefromdc]

Not sure what Debian's actually using, but I do recall being able to test the libinput work in mate-control-center. Certainly libinput is installed, I have libinput-bin, libinput-dev, libinput10, and xserver-xorg-input-libinput installed.

[lukefromdc]

Dead areas on the desktop is something I have seen under rare conditions but can't reproduce at will. Issues between compiz and conky have caused dead spots in Caja in the past but not recently, for instance.

[raveit65]

Btw. i can reproduce it with ubuntu-17.10 alpha too, if running the ubuntu VM in fullscreen.

[raveit65]

And i can reproduce it with compiz-reloaded running.

[whitwuv]

this issue also affects the clock (just noticed now after testing) and the "show desktop" button (which i've noticed previously sometimes doesn't respond to my clicks).

it seems it doesn't have to be the top edge of the screen, as I'm able to reproduce on the left edge of the screen with the "show desktop" button.

i had an issue a couple times right after installing F26 where certain items appearing in the window list were apparently unclickable. i eventually noticed that small parts of those items were clickable. note that the area i was clicking wasn't up against an edge of the screen. i haven't seen this issue recently. i presume it's related.

[raveit65]

Indeed, those applets are affected too.
Well, i will build panel with in-process-applets, maybe we have a different.

[raveit65]

Hmm, same with panel build with in-process-applets
... time to fix deprecated gtk_menu_popup. I know that using gtk_menu_popup is a problem under wayland.
Who knows what is change in Xorg for x-wayland in fedora.....

[lukefromdc]

I just looked through my gnome-panel code and guess what I found? GNOME's panel-menu-button still uses gtk_menu_popup even though it is deprecated. The entire chain of functions to pop up the menu appears to be identical, in fact. Try installing gnome-panel for test purposes. Running the command "gnome-panel" will bring it up on top of mate-panel, then see if it also has this issue. If it does not, the problem is not caused by gtk_menu_popup

[raveit65]

Same problem with gnome-panel in flashback session.
Btw. the issue exists also with applets in na-tray, ie. volume or nm-applet.

@flexiondotorg
Can you please try to reproduce this with ubuntu on bare metal?
I want to be shure that it isn't a issue with my host system if i run ubuntu-17.10 VM in fullscreen mode.

[lukefromdc]

While we are at this, I am preparing a mate-panel branch with gtk_menu_popup ported to gtk_menu_popup_at_widget, which gnome-panel did only in one out of many instances.

[lukefromdc]

#654 is ready for testing, see if it has any effect on this.

[raveit65]

Sadly, replacing the deprecation functions didn't solves the problem.
Here a video with clock-applet and traditionalok theme. I am only moving the pointer at the edge.
If the applet is clickable than you see the hover state of the applet (bright bg) in opposite to normal state with a transparency panel (blue bg).
Normal state means the applet isn't activate and it ignore any click.
mate-clock-applet.ogv.zip

[whitwuv]

there are two issues alluded to in the original bug report -- the "dead zones" issue (which has gotten all the attention), and the issue where it's not possible to close a menu by clicking it again immediately after opening it (as was possible in the past).

I have additional details to report regarding the inability to close with a click immediately after opening a menu ...

• this issue is not specific to the menu in mate panel -- it affects the menu in all applications (e.g. Pluma)
• this issue doesn't only occur if you recently clicked on a menu, but also occurs immediately after an adjacent menu is opened by moving the mouse from one open menu to the menu button next to it (this is actually when I see this behavior most often, as it occurs when I'm scanning through the menus and then decide what i'm looking for isn't there and I wish to at that point close the menu)

with the above new information in mind, should this bug be split in two, and what mate component would general menu issues belong in?

[whitwuv]

for whatever it's worth, this issue has seemed to noticeably contribute to my symptoms with carpal tunnel since upgrading, due to the frequent need for me to reposition the mouse in a precise way and reclick (sometimes needing to repeat these steps more than once).

[genpfault]

Might have something to do with rounding the floating-point XInput2 mouse position reports + a high-DPI mouse (2500 DPI Logitech G100s for me) going through libinput? First noticed the issue in with Firefox in KDE with MOZ_USE_XINPUT2=1 and trying to middle-click autoscroll on the far left side of a maximized window: sometimes it would work, sometimes it wouldn't. Finessing the mouse sliiiightly right (but less than a pixel) would make it work.

Perhaps at the GTK3 layer: setting GDK_CORE_DEVICE_EVENTS to 1 and then startxing makes clicking the menu button very reliable when moving the mouse to the very top-left. At least positioning-wise: there's still a delay before I can click again to dismiss the menu.

(Debian Stretch + MATE 1.18 FWIW)

[smkent]

I believe I'm also having this same issue (with panel elements/launchers/buttons not being clickable at the far panel edge). Strangely, this only reproduces on my laptop (with a high DPI screen), but not my desktop (standard 96 DPI monitor).

Even more strangely, I can reproduce the issue on my laptop even if I leave the DPI in MATE set at 96 DPI (instead of the ~120 I usually keep it at). I have confirmed this issue reproduces regardless of the GTK theme or window manager in use (can reproduce with both compiz and marco).

I normally keep a single panel at the top of the screen. When I move my mouse back and forth over the top edge, the taskbar window icons flicker as though they're being intermittently hovered over. Clicking on these buttons is similarly unstable, sometimes the click event passes through to the panel and sometimes it doesn't. I read earlier about the issue reproducing on left-oriented panels, so I moved my panel to the left and this issue reproduces 100% of the time with the panel on the left. If I move my mouse in a single pixel, clicking on the panel works fine.

edit I should add this issue is currently occurring for me on Linux Mint 18.2 MATE (with MATE version 1.18.0).

[whitwuv]

i had a dead spot just now on my window list which has been giving me a headache for the past hour or so - i finally logged-out to get rid of the issue, and I noticed that, during logout, something was drawn about 3/4 of an inch wide and about the height of my panel at the bottom of the screen around where i had the dead spot (this wasn't visible until logout was occurring). it looked like a rectangular cutout of something that was probably drawn at some point somewhere on the screen - it looked like maybe it was part of a dropdown select box that would appear in a webpage or something.

just hoping that may offer a clue as to what's happening....

[jwlarocque]

Noticed this issue immediately upon installing Mate today (Ubuntu 18.10). "Double clicking" panel menus opens and does not then close them, and there's dead space above the panel.

[mdmayfield]

Still seeing this issue in Ubuntu MATE 19.10 Eoan daily build.

[mdmayfield]

This does seem to be possibly related to subpixel motion with a high-DPI mouse. Very slight motions (even less than a pixel) appear to affect this. Where in the stack does this happen?

[mdmayfield]

I just built the latest mate-panel from source, and while I held out some hope that this might have been fixed with some of the changes regarding "monitor size instead of screen size", this issue is still present.

[mdmayfield]

Apparently this is the source of the issue: https://bugs.freedesktop.org/show_bug.cgi?id=92681

Setting the environment variable GDK_CORE_DEVICE_EVENTS=1 works around this issue, but may have unknown other consequences.

It looks like xfce4-panel sets this within itself to work around the xserver issue: https://git.xfce.org/xfce/xfce4-panel/commit/?id=e56e8699e271cea209f5b283421952d9035ad2b5

Perhaps this could be included in mate-panel, or maybe distros could consider running the mate-panel executable with this env var set?