In cases where internalClickCallback() modified the state of the button this was not being updated until the next call to updateState(). Calling it a second time after the click callback will make sure the state is up to date.
X11 cannot maximise windows that have their maximum size set. When not
using the native titlebar we now revert to setting the window bounds
without involving the X11 maximise function.
Some plugins (Izotope Relay, some older DPF plugins) use NSTrackingAreas
to handle mouse events, but unprocessed events seemingly get passed up
to outer views. Processing these events was causing unexpected
behaviour. For example, if the cursor entered a plugin view while
dragging a JUCE window border, a mouseEnter event was be generated,
interrupting the drag.
We now check whether mouse events were generated by an NSTrackingArea
which does not belong to the JUCE view, and ignore the event in this
case.
When rendering with OpenGL, the paint function is called from a
background thread. If we call `isMouseOver` from the paint function, we
may end up calling native functions via the ComponentPeer, which causes
threading warnings on macOS.
This commit also removes the subview from its superview's subview array before re-ordering as the macOS docs don't make any guarantees about what happens when adding a subview that is already contained in the array.
This prevents components from taking focus when they are blocked by another modal component by excluding them from the list of child handlers returned by AccessibilityHandler::getChildren() and fixes an issue with modal components being dismissed by handlers.
When bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).
Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.
This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.
