In Ubuntu 12.04, my mouse clicks when I release the button.

What happens (bad): I right click (mousedown), the context menu appears, when I release the mouse button (mouseup), the item under the cursor is clicked.

What should happen (good): I right click (mousedown), the context menu appears, nothing happens when I release the button. To click an item in the context menu, I click it normally with the right mouse button.

I have experienced this behavior in Chrome, the file browser, and in gnome terminal. The mouse is a Razer DeathAdder (but I'm just running whatever drivers Ubuntu picked automatically), and if it matters, I'm using the AMD/ATI graphics drivers.

  • 2
    i have the same behavior here on chromium
    – josinalvo
    Aug 21, 2012 at 4:24
  • 2
    This is so unbelievably annoying. Any luck getting it disabled?
    – Max
    Nov 9, 2012 at 19:17
  • 1
    I have the same problem, and it hacks me off too. I am considering as a workaround trying to get my right-click menus to have thick borders so that even if I'm moving my mouse slightly when I right-click, I'll just hit the border and not an actual menu option. The version of Fedora I use at home has these borders, and as a result I never accidentally hit items in right-click menus in the way I do in Ubuntu, even though Fedora has the same select-option-on-release behavior. I don't know much about Linux desktop management stuff, but if I get the workaround to work, I'll post an answer.
    – Mark Amery
    Mar 2, 2013 at 10:57

3 Answers 3


If you do not move your mouse in the meanwhile, there should not be any "menu item under cursor". The context menu opens such that its left upper corner is at the cursor, and there is a margin below to the next menu item.

However, if on mouse-button-release there is a menu item under the cursor, the desired behavior is to launch that menu item. This his how you (or at least many people) normally proceed: mouse-button-down, move the cursor to the desired menu item, mouse-button-release to activate that item.

If there is no menu-item under cursor after mouse-button-down, then the behavior is as you described: mouse-button-release does not destroy the context menu.

So maybe your mouse is very sensitive, and a button-down event is accompanied by a cursor move?

  • 1
    You are right that if there is nothing under the menu, nothing happens, which I knew, but this behavior is not desired to me. I just played around with my OS X laptop, and it seems that it distinguishes between a right-click and drag to the menu item versus simply right-clicking and releasing immediately. In Ubuntu, it is very sensitive. I have already lost work once accidentally this way when I was editing something in my browser. Aug 21, 2012 at 6:12
  • 1
    The problem is that if you're moving your mouse even very very slightly down and right at the moment that you right click, you are guaranteed to hit the top button of the menu. How often this happens to a given user probably depends upon their mouse-using habits. If you're in the habit of pointing at something and then clicking it in one fluid motion without ensuring your cursor is perfectly stationary, then you'll hit this issue regularly. Friendlier behavior would be to have, say, a 0.1s delay after mousedown before mouseup would count as selecting a menu option.
    – Mark Amery
    Mar 2, 2013 at 10:50
  • 1
    This is not necessarily true. For very big context menus, like Thunderbird's, if one right click's to the left of the screen, then the context menu appears while the cursor is inside it. So just right-clicking in this situation triggers unwanted operations.
    – zazke
    Dec 5, 2020 at 9:53

Here is my fix:

First, you need to compile and install sxhkd, from here:


which is a really cool program.

Then, in your ~/.config/sxhkd/sxhkdrc add this recipe:

  for id in `xinput list | grep 'slave  pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 0; done; \  
  xte 'mouseup 3' 'mousermove 0 -1'; \ 
  sleep 0.3; \
  for id in `xinput list | grep 'slave  pointer' | grep -v XTEST | sed -e 's/.*id=\([0-9]\+\).*/\1/'`; do xinput set-prop $id "Device Enabled" 1; done

How this works, sxhkd captures the right click event with its xcb listener, and replays it back, this is what the tilde is for. After this, we turn off the touchpad, move the mouse cursor one pixel up so that the first entry is not highlighted, sleep for 300ms to ignore any finger dragging after the click that throws off the position, and reenable the pointer devices.

This works perfectly on the chromebook I am setting up.

UPDATE: I changed the sxhkd recipe to work with all pointer input devices, not just touchpads.


This is the default behavior. You will experience the same thing even in Nautilus, which is the default manager. Actually, you will experience it everywhere. If you right click somewhere and you see a context menu, and, without releasing your right click, you hover above an action of the context menu and then release it, the corresponding action will be launched.

I can confirm this in all the programs I tried it into, thus, this is the default behavior under Ubuntu (and I find it handy, rather than having to manually left click to an action of the context menu)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.