Webview Doesn't Work on Compiled Plugin in Windows

[Straticah]

@bendurso hm the browser example works on my end for both win and mac.

development build from yesterday.

Red part is Webview

Make sure you have:

wv.set("enableCache", true);
wv.set("enablePersistence", true);

[bendurso]

@Straticah Yep, I have these settings enabled. Another setting of the plugin that may be related?

[Straticah]

@bendurso Not that i am aware of i guess you have vst3 support enabled already.

[bendurso]

@Straticah I noticed that the ‘PlayCanvas’ example had caching disabled. I changed it to enabled, and it works now in the compiled version.

In my project, I had caching and persistence enabled, so there must be another reason why it doesn’t work. But at least now I know it’s supposed to work. Thanks :)

[Christoph Hart]

@bendurso if you‘re loading an external website you should not use any of those flags, there‘s nothing to cache or be persistent.

[bendurso]

@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.

[bendurso]

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?

[d.healey]

@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.

[bendurso]

@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]

@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.

[bendurso]

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 :)

[Christoph Hart]

@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:

1. 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.
2. 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.