It seems like there’s a behaviour change where Component::mouseDrag is now being called on mouse down. Currently I’ve only tested this on OSX 10.11.5.
Looking through the call stack it seems that the mouseDown callback in juce_mac_NSViewComponentPeer.mm internally results in a mouseDrag event being triggered.
Is this an intentional change?
I’ve never considered that a drag event could be called on mouse down event before and only noticed because it resulted in a bug. Should I expect this behaviour from now on?
Interesting that when I step through the code, I can’t reproduce the same behaviour.
From juce_MouseInputSource.cpp::273
if (isDragging())
{
registerMouseDrag (newScreenPos);
sendMouseDrag (*current, newScreenPos + unboundedMouseOffset, time);
if (isUnboundedMouseModeOn)
handleUnboundedDrag (*current);
}
Could it be that while this check is being done that the mouse button to trigger to the click is still held down. Which would suggest why I couldn’t reproduce it when I stepped through.
It should be impossible for the MouseInputSource to dispatch a drag without having sent a mouse-down event… If you can find a code-path that lets that happen, let us know!
[user removes three-finger touch from track pad, for < about 1 second]
[user replaces three-finger touch]
mouseDrag
mouseUp
So, three-finger touch events that are not “physically” continuous may be regarded as “logically” continuous by JUCE (or the OS). I’m sure this is intended behavior, but perhaps good to know about.