This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1295072 - Right-clicking causes an immediate left-click
Right-clicking causes an immediate left-click
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gtk3 (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-01 14:09 EST by Kadir
Modified: 2016-12-20 12:32 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 12:32:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
excerpts from libinput-debug-events and evemu-record (4.51 KB, text/plain)
2016-01-04 01:48 EST, Kadir
no flags Details
Screencast (553.68 KB, application/octet-stream)
2016-01-04 01:57 EST, Kadir
no flags Details

  None (edit)
Description Kadir 2016-01-01 14:09:50 EST
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.
Comment 1 Kadir 2016-01-01 14:56:32 EST
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.
Comment 2 Peter Hutterer 2016-01-03 22:14:03 EST
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
Comment 3 Kadir 2016-01-04 01:48 EST
Created attachment 1111341 [details]
excerpts from libinput-debug-events and evemu-record
Comment 4 Kadir 2016-01-04 01:50:33 EST
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.
Comment 5 Kadir 2016-01-04 01:57 EST
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.
Comment 6 Peter Hutterer 2016-01-05 01:05:00 EST
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?
Comment 7 Kadir 2016-01-05 09:48:40 EST
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
Comment 8 Peter Hutterer 2016-01-05 21:48:47 EST
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?
Comment 9 Kadir 2016-01-06 02:14:33 EST
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.
Comment 10 Peter Hutterer 2016-01-10 23:39:51 EST
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.
Comment 11 Fedora End Of Life 2016-11-24 09:38:43 EST
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.
Comment 12 Fedora End Of Life 2016-12-20 12:32:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.