Description of problem: Right clicking cause an immediate left click. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Go to for example youtube.com right click 2. the right click opens the menu and immediately selects an option based on the location of the pointer 3. Actual results: the right click menu doesn't stay open, right clicking triggers and immediate click Expected results: The right-click menu should stay open Additional info: It looks like right clicking causes an additional immediate left click. It is very irritating. It happens more often when the menu is large like with firefox (when hovering above a link) or with VLC. In that case I have to hold the right mouse button and move the mouse while holding the right mouse button and release it when I am hovering above the wanted menu option. It could have to do with the combination of a low resolution (1366 x 768) and a large menu. So when a menu is large and the desktop has low resolution the menu has "nowhere" to go and the menu pops up with the mouse pointe in the middle. Bottomline is that a right-click has an additional immediate click action. That shouldn't be the case. Btw the mouse is a wireless Logitech M185. I'm using it with my laptop Dell e6320. It also happens when using the trackpad.
I did some more inspecting and I just noticed that the right-click behavior is very inconsistent. There are 3 scenarios: 1. In gnome-shell right clicking on the desktop opens the menu. Holding the right mouse button however does nothing. You have to release it before the menu pops up. 2. On the top bar right-clicking acts like a left click. So you can right click and open a menu. But right clicking and holding and releasing when hovering above an option does nothing. 3. In GTK applications (Nautilus, Evolution and Firefox) right clicking opens the menu and causes and immediate left-click. Right-clicking and holding the right mouse button and releasing it above an hovering causes a left-click and thus selecting an option. In this scenario you can right click and if you move the mousepointer very fast downwards (the place where the menu usually pops up), it causes a left-click. This is very confusing. This bug-report is about scenario 3. This behavior becomes very noticeable when you have an application running full screen on a "low" resolution (for example 1366 x 768, my laptop has this resolution) and your right-clicking to open a menu close to the edge of the screen. In that case the menu has "nowhere" to go and if the menu is large (like when your hovering above a link) right clicking causes a left click and thus selecting a menu option. In that case you have to right-click and hold and release when you want to left-click.
run sudo libinput-debug-events and check the input events coming out of that. do you see a left click there too? If so, please attach the output from sudo evemu-record from such a click. Otherwise, please attach your Xorg.log
Created attachment 1111341 [details] excerpts from libinput-debug-events and evemu-record
I have attached parts of libinput-debug-events and evemu-record. The relevant parts are: libinput-debug-events: event14 POINTER_BUTTON +34.05s 273 pressed, seat count: 1 event14 POINTER_BUTTON +34.21s 273 released, seat count: 0 evemu-record: ################################ # Waiting for events # ################################ E: 0.000001 0004 0004 589826 # EV_MSC / MSC_SCAN 589826 E: 0.000001 0001 0111 0001 # EV_KEY / BTN_RIGHT 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.102000 0004 0004 589826 # EV_MSC / MSC_SCAN 589826 E: 0.102000 0001 0111 0000 # EV_KEY / BTN_RIGHT 0 E: 0.102000 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +102ms So there is no left-click but a click when the right button is released. I hope this helps.
Created attachment 1111355 [details] Screencast To make things more clear, I have also attached a screencast of when it happens. I am right-clicking there without doing anything else.
273 is BTN_RIGHT, so at least libinput doesn't generate that left click. What happens if you click into an xev window? do you see a left click there?
I get the following output with a right-click: ButtonPress event, serial 36, synthetic NO, window 0x1800001, root 0xc4, subw 0x1800002, time 25442231, (41,40), root:(123,186), state 0x10, button 3, same_screen YES EnterNotify event, serial 36, synthetic NO, window 0x1800001, root 0xc4, subw 0x0, time 25442231, (41,40), root:(123,186), mode NotifyGrab, detail NotifyInferior, same_screen YES, focus YES, state 1040 KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 4294967236 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonRelease event, serial 36, synthetic NO, window 0x1800001, root 0xc4, subw 0x1800002, time 25442449, (41,40), root:(123,186), state 0x410, button 3, same_screen YES LeaveNotify event, serial 36, synthetic NO, window 0x1800001, root 0xc4, subw 0x0, time 25442449, (41,40), root:(123,186), mode NotifyUngrab, detail NotifyInferior, same_screen YES, focus YES, state 16
button 3 in X terms is the right button. so xev only shows right button events too which means that at this point I'm stumped - I don't know what's going on here. it's not a HW problem, otherwise libinput would show it up. It's not a libinput problem, otherwise xev would show it. sorry, I don't know where to go from here. Do you have anything running that may interfere with mouse events otherwise?
I have, as far as I know, nothing running in the background that may interfere. I think the problem maybe a side effect from intended behavior. As I said, in GTK apps, when the user right-clicks and holds the right-button, the menu pops up and the user can select an option while hovering above the menu and release the right button to select it. So it takes less clicks to open a menu option. Usually, the right-click menu opens up right below the mouse pointer. Or sometimes above the mouse pointer when your mouse pointer is at lower portion of the desktop. The problem arises when due to "low" desktop resolution (in my case a laptop with a resolution of 1366x768) and/or location of the mouse pointer (for example when the mouse pointer is at the corners of the desktop screen) or the right-click menu is big (with lots of options), in those cases the right-click menu can't go below or above the mouse pointer. So in the above cases the right-click menu can not pop up below or above the mouse pointer. In that case the menu pops up with the mouse pointer hovering above it. So in the above mentioned scenario, the "feature" that intends to produce a click when releasing the right-mouse button, produces a unintended side effect. Mere clicking the right-mouse button does not only produce a right-click but also a click because the menu pops up with the mouse pointer hovering above it. So, the bottom line is that it seems that in GTK apps clicking and releasing the right-mouse button produces two clicks in sequence (one when pressing and one when releasing). In some cases where the mouse pointer is hovering above the right-click menu when it pops up, the two clicks happen so fast that: A, you can hardly see the right-click menu and B an option is clicked without the user wanting it. This behavior is very irritating, it happens to me a couple times a day. After which I realize that I first have to hold the right-button and then hover above the wanted option and then release the right-mouse button to select it. I hope this makes it more clear to you.
I suspect the culprit here is some movement while right-clicking, I can reproduce this when I right-click while moving so I actually land on a menu item. Either way, this is definitely on the client side, I'm reassigning this to GTK.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.