Quick left click then right click in Tracker acts like double left click.

[jstressman]

Left clicking then right clicking in quick succession on an icon in Tracker (on the desktop or in a window) acts like you've double left clicked.

So left then right click on an image both opens the image in ShowImage and shows the right click context menu. The right click is acting both as a right click and as the second click of a double left click.

[Disreali]

On which revision(s) is this experienced?

[aldeck]

This must be a regression of my asynchronous mouse tracking rewrite a while ago. I've noticed something similar recently. I'll have a look shortly.

[jstressman]

It's been there for awhile at least. Verified on hrev44300 (gcc2h) and hrev44304 (gcc2h and gcc4h)... and I just verified it all the way back on hrev43643 (gcc2h) as well.

[aldeck]

Yes my changes are between hrev41892 and hrev42447. This is quite annoying, this has to be fixed for the next release, marking the ticket as to not forget.

[haxworx]

/add-ons/kernel/drivers/input/usb_hid/MouseProtocolHandler.cpp fClickSpeed(250000)

~/haiku/src/preferences/mouse/MouseSettings.cpp kDefaultClickSpeed 500000

./MouseConstants.h:const uint32 kMsgDoubleClickSpeed = 'SLdc';

I think the problem is that due to mouse speed settings both requirements for the menu and a Tracker window are met and therefore you have the annoying double function mouse combination bogosity.

Changing single and double click speeds seems to fix this.

WIndows double click: 500ms GNOME double click: 400ms

Does this help?

[jstressman]

I just noticed more weirdness...

In the Backgrounds dialog for opening an image, if you left click on a large image and quickly click on a different image (while the first large image is loading its preview), the large image will be selected after a second and show the right click menu even though you never right clicked anything, and the second image you clicked is never selected.

[leavengood]

It seems to me the problem here is that WasDoubleClick() in PoseView.cpp does not check whether the same button was clicked again, it just checks for any click. So either the button can be passed in to WasDoubleClick, or probably the better solution is that WasDoubleClick should not be called if the click was not with the primary mouse button. See:

​http://cgit.haiku-os.org/haiku/tree/src/kits/tracker/PoseView.cpp#n6898

I'm pretty sure we don't want to handle a double-click not with the primary mouse button (or we should at least ignore a double right click and of course the problem in this bug.)

Though in all this I wonder why the double click handling isn't in BView...isn't there some sort of double-click handling there?

[leavengood]

Wow I managed to crash Tracker while trying to reproduce this, due to a crash in BMenu::_Track, which is the horrible and disgusting mess which handles everything related to menu tracking. But that is another issue and the main point was I did reproduce this and will attempt to fix it with my above suggestion.

Edit: Actually I take that back, this menu crash was due to some in-progress code I have, which obviously has some issues. Though the menu tracking is still nasty.

[leavengood]

Fixed more or less as I described in hrev44424. I should have just fixed it instead of posting the long comment above ;)

[augiedoggie]

I can still reproduce this if I don't release left button when clicking with the right. Perhaps it would be better to use an 'and' test instead of an 'equals' test in ​http://cgit.haiku-os.org/haiku/tree/src/kits/tracker/PoseView.cpp#n6916

[leavengood]

I haven't check it yet myself but it makes sense thinking about the code. I just don't know what side affects there might be if the check for a right click masked out other buttons. I suppose not that much. I think with the exception of a right-drag we always want to a show a context menu on right-click regardless of what other buttons are down.

Re-opening this ticket.

[stpere]

Should be fixed in hrev44555. Thanks

[jstressman]

The Backgrounds image opening dialog click handling bug I referenced in the comments has its own ticket at #8788

It's still present as of hrev45308