This issue could be observed when loading the WebViewPluginDemo in the
AudioPluginHost, opening its editor, and then attempting to close the
editor window using the titlebar button. Tested on Fedora 42 with
libwebkit2gtk-4.1.
Unloading the webkit library with dlclose seems to cause the webview
process to crash, even if gtk_main() has already exited at that point.
Maybe this points to a need to manually clean up the webview somehow
before calling gtk_main_quit, but I can't see any obvious candidate
functions in the docs (gtk_widget_destroy doesn't seem to help).
The workaround presented here just opens the webkit library with
RTLD_NODELETE, which isn't ideal but might be necessary if this library
hasn't been designed with dynamic load/unload in mind.
If the browser process happened to segfault, the old WIFEXITED check
would never succeed and the loop would never break.
The issue is resolved by additionally checking for other statuses that
also indicate that the child process is no longer alive.
The issue could be triggered by opening the plugin in FL Studio, and
then using the TAB button to switch between FL Studio UI elements, until
the plugin became invisible and then it became visible again. This would
cause the WebBrowserComponent to navigate to about:blank permanently.
This was caused by the component becoming invisible and visible again in
rapid succession. This triggered a navigation to about:blank. To
understand the root cause of this, some undocumented behaviour of
WkWebView had to be uncovered. To understand this, see the following
test code, where the test1, test2 and test3 functions are called with
ample time in between one after the other.
void test1()
{
goToURL ("A");
}
void test2()
{
goToURL ("B");
goToURL ("C");
// B, C ignored completely, only D inserted into back-forward navigation queue
goToURL ("D");
}
void test3()
{
goToURL ("E");
goToURL ("F");
// E, F ignored completely, back navigation executed from D to A
goBack();
}
This commit reverts 8e6aeab799.
The WebBrowserComponent subprocess calls tryNextRead() in an infinite
loop. Prior to the reverted change this allowed it to handle the
transfer of larger files, which would span multiple calls to the
function. The transfer state would be remembered in the receivingLength
and pos class members.
The simplification in 8e6aeab799 mainly
comes from moving these class members into function locals, but this
means, that the transfer state is lost whenever the break statements are
hit. This would cause bad access during the transfer of larger files.
Prior to this commit it was possible for the WebBrowserComponent
implementation on Windows to end up in an infinite loop if multiple
WebBrowserComponent objects were being created at the same time.
When an instance was already being created, the createWebView() call for
the second would place it in a queue and return without initiating its
creation. When the first WebView finishes creation, it calls the
handleAsyncUpdate() function of the second. However handleAsyncUdpate()
would see that the webViewBeingCreated helper variable was already true
and not call createWebView(), hence the second WebView would never be
created.
If, in the meantime, the scriptsWaitingForExecution variable wasn't
empty, handleAsyncUpdate() would endlessly call triggerAsyncUpdate().
There were a few "ambiguous operator new/delete" errors that were due to
inheriting from a private base class that used the leak detector. These
errors are resolved by adding the leak detector to the derived classes.
JUCE_API was missing from a few useful types, notably the ARA hosting
types.
