In CoreGraphicsPixelData::createImage, image data was copied from a
BitmapData created from the Image passed into the function.
The BitmapData instance didn't keep track of the size of the buffer it
pointed to, so the buffer size was computed by multiplying the
BitmapData height by its line stride. However, if the BitmapData pointed
to a subsection of an image, the `data` pointer might be offset from
the allocated region, and `data + lineStride * height` would point past
the end of the allocated region. Trying to read/copy this range would
cause a heap buffer overflow at the end of the range.
This change adjusts BitmapData so that it keeps track of the size of the
allocated region. Taking a subsection of an image should subtract the
data pointer offset from the size of the allocated region.
Showing the tip will in turn call getDesktopScaleFactor(), accessing the
lastComponentUnderMouse. In some cases, it was possible for
lastComponentUnderMouse to point to a deleted component, resulting in
UB.
There are two changes in this PR:
- Using a SafePointer rather than a raw pointer ensures that calls to
getDesktopScaleFactor() will always be safe, regardless of when they
happen.
- Moving the assignment of lastComponentUnderMouse to before the call to
displayTipInternal() ensures that the returned scale factor is that of
the component that the mouse is currently hovering.
Narrator on Windows seems to call ExpandToEnclosingUnit to find the
character immediately following the current cursor position. When
expanding a degenerate range with position `input` (used to represent
the cursor position) to a single-character range, the returned range
should start at `input` and end at `input+1`. Previously,
findTextBoundary() would always return the position before
currentPosition when searching backwards by character, so the result of
ExpandToEnclosingUnit would be off-by-one when expanding to the closest
character.
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.
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.
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.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
The 'wrapper' accessibility handler is now ignored if a menu item has a
custom component, and has no submenu, and cannot be triggered
automatically. This avoids the case where a custom menu item may end up
with a wrapper accessibility handler that has no useful actions.
This patch also adds a 'label' argument to the addCustomItem functions,
which allows text for the screen reader to be supplied in the case where
a custom component is in use, but the menu item has accessibility
actions.
Effects of this change for windows with native titlebars:
- Resizable windows without maximise buttons will now only allow the
'zoom' behaviour from the rightmost titlebar button (i.e. this button
will not allow entering full-screen mode)
- Non-resizable windows will grey-out the rightmost titlebar button,
whether or not the maximise button is enabled
