Unable to use with the latest webviewer_flutter package due to outdated on unity webview in this package

[Jacqueline94-Koo]

Hi, I do have an issue about the flutter-unity-widget cannot be use together with the latest webview_flutter package which will have conflict for these 2 packages. Maybe can update the webview on flutter-unity-widget?

error message:
Because webviewx 0.2.1 depends on webview_flutter ^2.0.13 and no versions of webviewx match >0.2.1 <0.3.0, webviewx ^0.2.1 requires webview_flutter ^2.0.13.
And because flutter_unity_widget >=2022.1.0 depends on webviewx ^0.2.1, flutter_unity_widget >=2022.1.0 requires webview_flutter ^2.0.13.
So, because odaring_unity depends on both flutter_unity_widget ^2022.1.7+1 and webview_flutter ^4.0.1, version solving failed.
pub get failed (1; So, because project_unity depends on both flutter_unity_widget ^2022.1.7+1 and webview_flutter ^4.0.1, version solving failed.)

[ifjorissen]

I'm running into similar issues with the webviewx plugin. Is it possible to remove webviewx and use webview_flutter_web directly for the web platform (which seems to be the only place where webviewx is used)?

[timbotimbo]

Workaround

If you don't use the web platform, you can use dependency overrides.

Add this to your pubspec:

dependency_overrides:
  webview_flutter: [VERSION_YOU_NEED]

Forcing this override will break webviewx, but that won't matter if you don't use the web platform.

Upgrading the webview

I can find pull requests on webviewx and the webviewx_plus package that get us to 3.0.4, which would have fixed things up until 21 days ago. But it seems like webview 4.x has quite some breaking changes, which makes those outdated too.

I don't think webview_flutter_web will work either.

It is currently severely limited and doesn't implement most of the available functionality.

It is probaby easier to get a package like webviewx_plus to update than to maintain a new fork.

Related issues

#622 #615

[ifjorissen]

Thanks for the workaround @timbotimbo.

out of curiosity, do you know what's missing in webview_flutter_web that we would need to use that instead of webviewx? Or is there another plugin that seems suitable as a replacement for webviewx?

[stuartmorgan]

I don't think webview_flutter_web will work either.

It is currently severely limited and doesn't implement most of the available functionality.

Many of the limitations are fundamental to the web platform, and aren't going to work in any other package either. E.g., webview_flutter provides the ability to run arbitrary JS in the context of any webpage that's loaded in it, which is impossible with an iframe.

Is this the only thing webviewx is used for? Loading a single web page and never programmatically interacting with it any way should work fine in webview_flutter_web.

[timbotimbo]

@stuartmorgan
I was not involved in creating the WebGL target so I'm not exactly sure why webviewx was chosen.
webview_flutter_web might work, that quote honestly just scared me away while quickly giving a response with the workaround.

Looking more into it:
There is javascript communication between Flutter and Unity inside the webview, but it all appears to be using the js window.

The plugin adds some global functions and events from within the unity index.html.

var mainUnityInstance; //assigned on unity initialization

// 2 functions called from within unity webgl
window['handleUnityMessage'] = function (params) {...};
window['handleUnitySceneLoaded'] = function (name, buildIndex, isLoaded, isValid) {...};


//2 events triggered by flutter
window.parent.addEventListener('unityFlutterBiding', function (args) {
	mainUnityInstance.SendMessage(...);
});
window.parent.addEventListener('unityFlutterBidingFnCal', function (args) {
	mainUnityInstance.SendMessage(...);
});

From inside Unity the handleUnity functions are called.
Flutter uses html.window.dispatchEvent to trigger the unityFlutterBiding events.

If those 2 interactions are possible it should be possible.

[Offtopic]
I've seen your name on a lot of platformview stuff in the main Flutter repo.
This plugin has some issues on android like AndroidView occasionally turning transparent, and a black flash when the widget is loaded.
Is it more useful to make new issues in the Flutter repo or tag you in issues in this repo?
(Reproducing issues might be hard in the Flutter repo as you will likely need unity installed etc.)

[stuartmorgan]

This plugin has some issues on android like AndroidView occasionally turning transparent, and a black flash when the widget is loaded.
Is it more useful to make new issues in the Flutter repo or tag you in issues in this repo?

If the issues are with the platform view system, they should be filed in the Flutter repository.

[timbotimbo]

@ifjorissen
I just tried 2 plugins to update the webview:

webviewx_plus

This was a drop-in replacement and works instantly. But thats webview 3.04 instead of 4.

webview_flutter_web

I could not get this one to work for now.

This shows a plain html page without any sign of unity.
There are cross-origin errors in the console about using window.parent in the iframe.
I'm also seeing warnings like Height of Platform View type: [webView0] may not be set. Defaulting to height: 100%.

Removing the javascript code that triggers cross-origin fixed the errors in the console, but it is still a white page.

I noticed some sandbox difference so I edited the webview source to see if adding something like sandbox="allow-downloads allow-scripts allow-same-origin" would help, but that did not seem to help.

<!--iframe format from  flutter_webview_web -->
<iframe id="" width="100%" height="100%" src="data:text/html;..." style="border: none; height: 100%; width: 100%;"></iframe>

<!-- iframe format from webviewx-->
<iframe id="" name="" allowfullscreen sandbox="allow-downloads allow-forms allow-modals allow-orientation-lock allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-presentation allow-same-origin allow-scripts" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture" style="border: none; width: 100%; height: 100%;">
...
</iframe>

The other difference i'm seeing is that one adds the index.html contents to the src tag, while the other places it in the iframe element itself.

I've spent enough time looking into this for now, maybe i'll try again at another date.

[ditman]

... src="data:text/html;..." ...

Wow, that looks odd; I'd expect the src to be the actual URL of where the unity HTML file is located.

That weird src attribute probably explains the cross-origin errors, your test web app is being served from https://localhost:xyz, it'll consider data:text/html;...blah a different origin (in fact, every data URL is a different origin altogether):

Note
Data URLs are treated as unique opaque origins by modern browsers, rather than inheriting the origin of the settings object responsible for the navigation.

MDN > Data URLs

I wonder what is setting that value (if it's our implementation of the webview, or the flutter-unity-view-widget through some magic; I've seen Uri.base.origin being used, and it seems to be Not Working As Intended :))

[stuartmorgan]

I wonder what is setting that value (if it's our implementation of the webview

It's us. I'd forgotten about this; we're doing the request manually so that we can handle POST and headers.

We should probably make two paths in that method, one that does what we're doing now when necessary, and one that just sets src for GET with no headers.

[ditman]

We should probably make two paths in that method, one that does what we're doing now when necessary, and one that just sets src for GET with no headers.

You're absolutely right, I should have noticed this use case when in PR (x_x)

[timbotimbo]

@ditman
I just tried webview_flutter_web: ^0.2.2 with the fix and it now seems to work properly.

The only thing unclear to me is the documentation.
It tells you to depend on webview_flutter, but it works fine without.

The example uses PlatformWebViewController and PlatformWebViewWidget but I can also use WebWebViewController WebWebViewWidget instead.

[stuartmorgan]

The standard way to use a federated plugin is to depend on the app-facing package, and to treat the various platform implementation packages as implementation details; the README reflects that.

Clients who are comfortable relying on an API layer that's not primarily designed for public use (and may thus not always be as easy to use, as well documented, etc.) can certainly use the platform interface layer instead.

[ditman]

@timbotimbo thank you very much for keeping at this! I hope the standard webview package works as needed!

[timbotimbo]

Looks like #761 got included in version 2022.2.1 on pub.dev, which means this is finally in a public plugin release.