In order to display a WebKit based webview a plugin will deploy a
temporary standalone executable on the system and host the WebKit
instance inside that.
Until this commit it was possible that the message thread got stuck
waiting for the WebBrowserComponent's thread to finish, while the thread
was waiting for the message thread to handle a posted message.
Android devices won't necessarily be able to load MP3 files, so that
option has been removed from the file chooser. FLAC files should be
supported, but were missing from the MIME table.
The demo no longer tries to load files into the thumbnail view if they
previously failed to load into the transport.
The biggest new feature in this commit is the addition of
NativeMessageBox::scopedAsync and AlertWindow::scopedAsync, both of
which return an instance of ScopedMessageBox that will hide the message
box in its destructor.
The code for displaying modal dialogs on Windows has also been updated.
Now, the dialog itself is run from a new thread with its own message
loop. This means that when the dialog is dismissed, the background
thread can be joined safely. In plugins, this means that there's no
danger of the plugin view being destroyed from within the message box
runloop, for example.
On Windows, broughtToFront may be called during the destructor of
VSTPluginHost, adding the window back into activeVSTWindows, leading to
a heap-use-after-free in vstHookWndProc.
This change means that broughtToFront will only reorder
activeVSTWindows; it will never add a window that's not already in the
list.
The OpenGL renderer uses ColourGradient::createLookupTable to generate
gradient textures. However, the tweening method used was different to
the tweening used by CoreGraphics gradients, and by the software
renderer.
Gradient tweening is now computed using non-premultiplied colours, to
ensure consistency between gradients rendered using OpenGL, and with
other renderers.
AUv2 plugins on Arm that are hosted out-of-process (e.g. in Logic 10.7)
can sometimes crash due to endlessly recursing through becomeKeyWindow.
This tends to happen when displaying a secondary window in a plugin,
e.g. an AlertWindow, then clicking on a secondary app, then clicking
back on the AlertWindow.
To avoid this case, we check that the peer isn't already key before
calling makeKeyWindow.
Unfortunately, we can't use isKeyWindow to avoid the recursion because
this may not return true until after becomeKeyWindow has returned.
The previous method for finding the dialog's owner was ineffective, and
it was still possible for other windows to obscure the file picker in
many cases. Using GetActiveWindow seems to produce the expected
behaviour.