Webview Doesn't Work on Compiled Plugin in Windows
-
@bendurso if you‘re loading an external website you should not use any of those flags, there‘s nothing to cache or be persistent.
-
@Christoph-Hart Thanks, I tried with and without cache/persistence, but it still doesn’t work.
But.. I tested the same script along with the same HTML file in a new project, and it works. There must be something in my project that’s preventing the page from rendering. I used the same project settings.
It actually doesnt even load the html in the original project, because I have a spinner while the page is loading. And I don't even see the spinner.
-
Yeah I found the issue.. for some reason in the compiled plugin it doesn't find the html file. I checked it with File.isFile() and only founds it on Hise.
I have the setting "Embed Images Files" enabled. I tried also disabling this and putting the ImageResources.dat into the appdata folder, but same issue.
This is how I'm getting the file:
const var webroot = FileSystem.getFolder(FileSystem.AudioFiles).getParentDirectory().getChildFile("Images/news"); WebView1.setIndexFile(webroot.getChildFile("file.html"));
The weird thing is that.. in a new project it works. But on my existing project it doesn't. Any ideas on what else could be blocking the file?
-
@bendurso said in Webview Doesn't Work on Compiled Plugin in Windows:
const var webroot = FileSystem.getFolder(FileSystem.AudioFiles).getParentDirectory()
This will return the app data folder in the compiled plugin.
-
@d-healey yeah I know. If I embed the Image Files will be into the plugin itself. But the issue is not here because I'm being able to make it work in a new small project with the same script and html (in the compiled plugin).
-
@bendurso After a lot of testing, I figured out why the index.html file wasn’t loading. Once I deleted all the UI components (panels, sliders, etc.), it finally worked.
One thing I noticed is that the standalone app now opens way faster—went from 5 seconds to almost instant. Makes sense since there are fewer elements to load, but it always loads fast on Mac.
So maybe the HTML file isn’t loading because of too many UI elements? The weird part is I only see this issue on Windows, not Mac. A couple commits ago it was fine, but I can’t roll back since I’m using the new AHDSR Flex now.
-
I found that commit ffc821ed0dcbde87c3b29dac9023b4b11eaeaf0e (enabled compilation of HISE with IPP by default) works fine. So the issue must be in a newer commit.
The plugin loads much faster, and the html file loads too. @Christoph-Hart maybe this info helps :)
-
@bendurso No idea what could have caused this and it might be a secondary bug which is caused by the webview not being initialized in time because something else took too long.
Can you pinpoint this to a specific commit within that timeframe?
Try a binary search algorithm and focus on the commits that have a checkmark in the commit historty as they will compile sucessfully:
- you know that the HISE commit from July 4th works, but the one from September 15th doesn't. Take a commit from the middle point (eg. August 4th). Compile that one. If it doesn't work, you know the error is introduced between July 4th and August 4th, otherwise the the issue was introduced between August 4th and September 15th.
- Take a commit from the mid point between July 4th and August 4th (eg. July 18th). If the error...
If you repeat this until you can pinpoint it to 1-2 commits, then I can take a look what could have gone wrong there.
Otherwise if you can create a test project that demonstrates the issue reliably with the latest commit I can debug that too - try creating a project where you create hundreds of dummy UI elements to see if that really causes the problem.
-
@Christoph-Hart Thanks for your reply and details to debug it :)
It turns out I was mistaken—the commit I mentioned doesn’t work either.
I created a test project with a lot of sliders, labels, buttons, and comboboxes (using the latest commit), and exported it as a standalone app.
In HISE, the WebView works (the btnNews button shows and hides it), although the interface loads slowly. However, in the exported standalone app, it takes a long time to launch, and the WebView’s HTML doesn’t load.
If I remove the WebView, the interface loads much faster in both HISE and the standalone app.
This issue only occurs on Windows; everything works fine on Mac.
-
@bendurso good catch, I could reproduce it here.
The issue was a timeout in the Windows browser initialisation routine (about 6 seconds), and in the compiled plugin this occurs simultaneously to building up the UI component tree which is why you run into the issue there - in HISE the component tree is built up when you load a project which is just shortly before the webview is initialised which apparently gave it enough breathing time to go through.
I've moved the initialisation of the webview at the end of the component tree build step, so that there should be no clogging of the webview initialisation any more.
The other solution would be increasing the timeout, but this looks cleaner, so unless there are follow up issues we go this route.
-
@Christoph-Hart Nice, thanks. I rebuilt HISE with the latest commit and re-exported the plugin, but nothing changed for me.
What I find strange is that on Mac, the exported app (or plugin) opens instantly without any delay, while on Windows it takes about 5 seconds to load. My Mac is a bit more powerful than my Windows PC, but not five times more powerful.