Component: Avoid sending mouse-drag events to a component whose mouse-down was consumed by a modal component

[emezeske]

When a modal component consumes a mouse-down but dismisses itself asynchronously, the component under the mouse never receives the mouse-down, but it can still receive the rest of the drag. internalMouseDrag only checks whether the target is blocked at the time each drag event arrives, so once the modal component finishes going away mid-gesture, the drags get delivered to a component that never saw the press.

Any component that captures state in mouseDown then runs its mouseDrag with stale state. Where I hit this: a resizable window with a bottom-right corner resizer, plus an open CallOutBox with setDismissalMouseClicksAreAlwaysConsumed (true), which dismisses itself via postCommandMessage, i.e. asynchronously. Pressing the corner resizer dismisses the callout, then the drag events arrive at the ResizableCornerComponent, whose originalBounds was never set, and the window instantly snaps to its minimum size.

Repro:

1. Make a window resizable with setResizable (true, true) and give it a constrainer with a minimum size
2. Open a CallOutBox with setDismissalMouseClicksAreAlwaysConsumed (true)
3. Click and drag the corner resizer
4. The window snaps to its minimum size instead of ignoring the drag

internalMouseUp already checks mouseDownWasBlocked before delivering, so this just applies the same check to mouseDrag: if the press that started the gesture was swallowed by a modal component, the drags shouldn't be delivered either.

[juce-push-bot]

This pull request has been mentioned on The JUCE Forum. There might be relevant details there:

https://forum.juce.com/t/pr-avoid-sending-mouse-drag-events-to-a-component-whose-mouse-down-was-consumed-by-a-modal-component/69143/1