The bug was triggered on Monterey where a pressure of 1 is reported
while a mouse button is being held down. This caused an extra drag
event being triggered between mouse down and up events, even if no
movement occurred.
Previously it was possible to inadvertently activate a menu item by
clicking on a submenu item that was drawn on top of the parent menu.
The root cause was that hide() initiates an asynchronous mechanism
through exitModalState() that eventually destroys the MenuWindow, but
the MouseSourceState timer callbacks and event handlers sometimes still
had a chance to do a state update. Since the submenus have just been
destroyed the update could mistakenly conclude to activate one of the
items of the now lone parent.
Some Windows 11 devices have both touch screens and mouse inputs, and
these can be used simultaneously.
The Viewport (and ListBox) now check the input source of each mouse
down. If the source is not a mouse, the viewport will always enter
drag-to-scroll mode, regardless of the result of isScrollOnDragEnabled.
Previously, lifetime management of CTFontRefs was not implemented
correctly. For zero-length ranges, the font may not be retained when
applying it to a CFAttributedString, meaning that the reference stored
in the fontMap sometimes became invalid before
createCFAttributedString() returned.
We now retain font refs when adding them to the font map, and release
them when the map is destroyed, ensuring that the font references remain
valid throughout the lifetime of the map.
This change is intended to resolve an issue where iOS apps failed
automated review due to use of non-public selectors. Explicitly adopting
the relevant protocols allowed an app to pass automated review during
testing.
When plugins change their 'parameter info' this often means that their
previous parameter text is no longer valid, so we should fetch new text
to represent the parameter value.
This change was primarily tested with Kontakt.
Note that hosts using the AUv2 API (e.g. JUCE hosts) to host JUCE AUv3
plugins may not receive begin/end gesture events, depending on the OS
version, and potentially the host architecture. I suspect this is
because older versions of the OS-provided AUv2/AUv3 translation layer
don't handle these events.
In testing, an Intel host on Catalina did not receive begin/end events,
but an Arm host on Monterey did receive these events.
This issue affected windows with JUCE titlebars. When dragging the
window back and forth between two displays with different DPI settings,
the window could sometimes end up with the wrong size.
It looks like setting new window bounds inside the WM_WINDOWPOSCHANGED
message was occasionally causing the system to lose track of the correct
scale for the window.
As a byproduct of this change, JUCE should no longer receive reentrant
calls to handleDPIChanging.