[BUG] 6.1.6 changes mouse events behavior?

AFAICT this commit changes the behavior of mouse events in a way that the commit doesn’t document. At least on macOS Monterey, with a regular (although Magic :magic_wand:) mouse.

Before: a mouse down event triggered both mouseDown and mouseDrag, before any mouse movement.
After: a mouse down event triggers only mouseDown; mouseDrag is called upon actual movement while the button is held.

This seems to me like quite a big, observable change that might need more documentation if that’s what was intended. But here is at least one place in JUCE where it entails a regression:

I have a LassoComponent with associated SelectedItemSet, and I use it as per the documentation:

  • in my mouseDown I call lasso.beginLasso()
  • in my mouseDrag I call lasso.dragLasso()
  • in my mouseUp I call lasso.endLasso()

Before the patch, a single click would clear my selection (as expected I guess, since all lasso selection systems behave like this); after the patch I need to drag the mouse cursor 1px to clear the selection.

Could maybe @attila comment on this?

I’m still using Juce 6.1.0 (I have it a bit hacked so I only update when it’s justified), and the mouse always worked as you described in you After behavior. It doesn’t send a mouseDrag until you actually drag the mouse, which seems the right thing for me.

Maybe was it an OSX bug recently fixed?

The behavior change is directly linked to JUCE’s change, not to an OS update: I’ve bisected it down to the commit linked above.

Interesting that you get the after behavior; I’ve been using Juce “only” for a year, but in the several JUCE/macOS combination I’ve tried I think I always saw the before one. I agree with you that after feels more right; I don’t know which is the “official” one from JUCE.

I’m sorry, I forgot to state I’m using Windows! But it should be consistent between platforms anyway

Also, for your problem, I suggest you use in your mouseDown, if After behavior is the right one, both calls, the lasso.beginLasso() and lasso.dragLasso(). In the mouseDrag(), the lasso.dragLasso() as usual. I never used that component so I’m not sure, but it should work.

Yes, that’s how I fixed the problem right away. I’m just mentioning it here for JUCE’s devs because LassoComponent (and probably others) is not synced with its doc anymore; they might want to know that a recent commit introduced this regression.

Thanks for bringing this to our attention! I’ll take a closer look at LassoComponent and see if the documentation could be improved.

Before the change we had a bug report that the behaviour in Monterey, which you described in Before, is breaking existing code. On Windows and even on MacOS up until Monterey, the regular behaviour was what you described in After and the change was aiming to restore this.

For reference, the (spurious) call to mouseDrag() immediately after mouseDown() (i.e. the Before behaviour) affected the macOS implementation since 2016.

At the time, the introduction of that behavior felt like a bug to many (me included): while it’s true that a mouseDrag() event after a mouseDown() must be supported by the application, still the fact that a mouseDrag() could be triggered even in the case of absolutely no movement (for example, clicking while the mouse is lifted from the desk) seemed a little counterintuitive.

In addition to that, AFAIK the Windows implementation always behaved in the After fashion, meaning that a sublte inconsistency existed between the two platforms since then.

If the macOS implementation is finally being reconciled with the Windows implementation, hooray!
I hope the users that wrote in those in topics to report the issue, are still around to see it finally fixed :raised_hands:


Thanks for clarifying.

It seems there has been a subtle inconsistency for a long time. What I believe Monterey changed is it started reporting changing pressure for non pressure sensitive devices.

So if you’ve been using a trackpad or magic mouse you were subject to this inconsistency even before Monterey, and if you used a generic mouse you came across it only then.

1 Like

Thanks @attila and @yfede for the explanations, it makes a bit more sense now.