linuxmint / linuxmint/cinnamon

Inconsistent behaviour of secondary click functionality

Open
#5,408 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

BUG
Dominant language
JavaScript
Stars
5.6k
Forks
915
Avg merge
5d 22h
Merged PRs (30d)
3

Description

Tested in LM18 beta. Have not tested in 17.3.

Turn on the simulated secondary click in the accessibility, mouse settings

Mouse and touchpad behaviour:

Nemo - works perfectly. When you press and hold then the cursor fills in to show progress, and when it is full then if you release then the context menu is shown, just as if you had pressed a right mouse button. Similarly works just fine on my two laptops with a trackpad with separate buttons, or a trackpad which has inbuilt button capability

Applets - In most cases press and hold fires off the left mouse action when the press happens, and then the right mouse action replaces it when the release occurs - so the power applet, for example shows the normal power status popup, which is replaced by the about/configure/remove popup when the mouse button is released. [this 'launch on click' behaviour rather than 'launch on release' is not carried forward into the menu item behaviours, they appear to work on 'launch on release'. It may be that applets are optimised for initial launch speed at the expense of long click or multiple click behaviour]

A couple of exceptions to this general behaviour :

  • In the window list the single click action is carried out, and then the context menu shows on release.
  • In the menu the left mouse action is triggered, but when the button is released then the right click actions do not happen, so there is no way to get at the 'add to panel/desktop/favourites/uninstall' menu.

Touchscreen behaviour:

Nemo - works as per mouse. However there is the practical problem that you can't see the cursor filling to know when to lift your finger, as it is hidden under the contact patch. More significantly it only triggers very occasionally, less than one time in twenty or so. Perhaps it is sensitive to being able to keep a steady finger ? Works much better with a press, release, long press, release sequence - perhaps one time in two, so I would not be surprised if that was the designed sequence and the inherent wobbliness of the touch screen interaction meant that I was doing this occasionally when I thought I was doing a simple long press and release.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing simulated secondary click from the accessibility mouse settings in Nemo, applets, the window list, and the menu, then compare the mouse, trackpad, and touchscreen behavior described. Trace how press, hold, and release events are handled in each area. Done means secondary click consistently exposes the expected context actions without triggering conflicting primary actions.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
accessibility, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.