Views get B_MOUSE_DOWN events when they shouldn't

[jackburton]

Looks like if a view subscribed to mouse events with SetMouseEventMask() in MouseDown(), it will get B_MOUSE_DOWN events that fall within the same window but outside the view itself, while the mask should be resetted as soon as the mouse button is released.

[axeld]

Do you have a particular application/test case where this is visible?

[jackburton]

Not out of the box, but I added a printf() in BTextView::MouseDown(), started FileTypes, selected a file type so that a textcontrol (any) becomes editable, clicked on it, then clicked outside of it (even clicking the window tab causes a mousedown event to be sent to the textcontrol/textview).

[jackburton]

Oh by the way, I forgot to say I had focus follows mouse enabled.

[axeld]

I tested under Qemu with this exact scenario, but I can't reproduce this problem. I selected application/ZIP Archive, selected the text, released the mouse button outside of the view, and pressed the mouse again.

If you still have this problem, try to rebuild the app_server and see if that helps; our static libraries sometimes make problems, and I've seen the weirdest problems due to that with regards to the app_server.

[jackburton]

Ok, in case it still happens I'll try to come up with a test app.

[jackburton]

I just tried your suggestion, the problem is still there, I found a way to reproduce it 100% with focus follows mouse.

1. Start Filetypes
2. click on application's little arrow to expand the application item
3. click on "Be Application"
4. move the mouse outside of the window so that it loses focus
5. move the mouse inside the window so that it gets focus again
6. click on any textcontrol.
7. click again on the same textcontrol
8. click anywhere else on the window.

[axeld]

So it only happens when you have FFM activated?

[axeld]

Okay, I can now reproduce it - I couldn't do it before, because I moved the mouse having the mouse pressed before, and it only happens if you click once. I'll look into it.

[axeld]

Fixed in hrev18483. Turns out the bug could only be reproduced if you pressed the button for a very short time; if you'd hold it a bit longer, the problem went away.