This bug took us a while to reproduce!
If you call either evaluateJavascript or emitEventIfBrowserIsVisible before the very first page was loaded on the WebView, this would freeze the UI when loading a project in a DAW with multiple instances loaded.
To reproduce:
Windows only (does not happen on Mac).
Build attached plugin
Load an FL Studio or Cubase project that has multiple instances loaded with their window open (attaching projects for both).
The UI of any instance after the first along with the DAW would freeze.
A repo to test and reproduce issues with the JUCE8 WebUI
The offending code is just:
struct WebEditor : WebBrowserComponent
{
WebEditor()
: WebBrowserComponent(getOptions())
{
evaluateJavascript("console.log('hello');");
emitEventIfBrowserIsVisible("hey", "hello");
goToURL(getResourceProviderRoot());
}
};
If I move those evaluate and emit calls to be after pageFinishedLoading, that resolves the freeze.
FreezingProjects.zip (62.0 KB)
1 Like
attila
January 23, 2025, 2:09pm
2
Thank you for reporting this, and for doing it in such a wonderfully detailed and easy to reproduce way. A fix is now out on develop
committed 03:29PM - 17 Jan 25 UTC
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().
1 Like