BTW, another apparent related effect is that if I right click anywhere on the screen to call up the menu, it sometimes just appears briefly and then goes away. Again, if I hold the mouse very still, this does not happen. Or just keep the right button depressed until I make a menu selection.
I think it is clearly a different issue, related to the movement of your hand not to the mouse or the soft. Look at very precisely what happens:
when you Right click on the pinboard, the cursor is at the extreme left top
corner of the menu, a very small area, like the point of a needle. When you relax the Right button nothing happens because the cursor is always on the menu, but, if in the same time than you relax, you move just a tiny bit toward the pinboard (out of the menu =
you are now on the pinboard) the pinboard is activated by the relax and you loose the menu. The "problem" is what I have said in a previous post, that the programmer of the mouse routine in X has not desactivated the relax of the button after the first Right clich which opens the menu or whatsoever.
Edit: it is above the median line of the screen that we find the cursor at this spot. The problem is less sensible along the vertical edge of the menu when the cursor is in the low area of the screen.
I was convinced it was a bounce problem, but now not so sure.
You are right, doubt is a very good "fuel". We must investigate further.
I addition, Gyle, I don't think processing time is any longer a major consideration in "debouncing" a mouse. I know I have had systems that do so. Further, many systems let you input a double click to calibrate the mouse driver. This is an indication it can't take much time.
Yes, a debouncing routine is just a loop to count, a timer. The complexity is where to bind this routine, when to trigger it, by what means (e.g.interruption ?), how long time the ticket in a round robin, priority, etc...
Cheers