Issue with JSAny for web

[alikamal1]

During build with flutter build web --wasm and when open inappwebview there is type error

 'com.pichillilorenzo/flutter_inappwebview', (int viewId) {
Type 'int' is not a subtype of type 'JSValue' in type cast

Connected to #2067

After updating the type from JSAny to String the webview works

[pichillilorenzo]

I was able to compile using flutter build web --wasm the example of this plugin and launch it without any error.
JSAny should be pretty compatible with both int or String dart types without any error.

Here is the JSAny definition:

/// A non-nullish JavaScript value.
///
/// A [JSAny] can be any JavaScript value except JavaScript null and
/// undefined. JavaScript null and undefined are instead converted to Dart
/// null by the compiler. Therefore, [JSAny]? is the top type of
/// the type hierarchy as it includes nullish JavaScript values as well.

[alikamal1]

@pichillilorenzo after building it with wasm, did you also force it to launch as wasm, not canvaskit?

flutter build web --wasm
cd build/web
dart pub global run  dhttpd '--headers=Cross-Origin-Embedder-Policy=credentialless;Cross-Origin-Opener-Policy=same-origin'

https://docs.flutter.dev/platform-integration/web/wasm#build-or-run-the-app-flutter-build-web-wasm

[ArturLevchuk]

@alikamal1 @pichillilorenzo Hi guys! I tested both of your variants. I also encountered the same issue as @alikamal1:

After applying your implementation, that issue was resolved, but now we’re facing a new one:

Flutter 3.24.4

[ArturLevchuk]

We also can run wasm app by flutter run --wasm but it's available in Flutter 3.24+

[pichillilorenzo]

@alikamal1 I could merge this PR to resolve the error on WASM, but it seems that when it is compiled with it, the iframe is not positioned correctly as you can see from @ArturLevchuk example (tested also by myself).
If I move the window rendering the webpage to another monitor, seems to fix the issue, but as soon as I move it back to the other monitor, the layout is broken again.

Also, using WASM doesn't load the same iframe of the example that is loading and rendering correctly without it!
Setting --headers=Cross-Origin-Embedder-Policy=credentialless;Cross-Origin-Opener-Policy=same-origin didn't help either.
Loading any iframe with whatever URL that should load (also editing manually HTML using inspect developer tools) doesn't work.

[alikamal1]

@alikamal1 I could merge this PR to resolve the error on WASM, but it seems that when it is compiled with it, the iframe is not positioned correctly as you can see from @ArturLevchuk example (tested also by myself). If I move the window rendering the webpage to another monitor, it seems to fix the issue, but as soon as I move it back to the other monitor, the layout is broken again.

@pichillilorenzo This issue of the iframe position seems related to the current Flutter stable version. I am not sure what is causing the issue, but it seems to be working fine on master channel (3.27.0-1.0.pre.11) as shown in the screenshot below

Also, using WASM doesn't load the same iframe of the example that is loading and rendering correctly without it! Setting --headers=Cross-Origin-Embedder-Policy=credentialless;Cross-Origin-Opener-Policy=same-origin didn't help either. Loading any iframe with whatever URL that should load (also editing manually HTML using inspect developer tools) doesn't work.

yes, because the nature of Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
to enable the Wasm, which requires including these headers, or it will fallback to canvaskit
https://docs.flutter.dev/platform-integration/web/wasm#serve-the-built-output-with-an-http-server
this will result in the browser blocking the iframe content unless the website that's running inside iframe includes these headers with these values 'Cross-Origin-Embedder-Policy' = 'credentialless' and 'Cross-Origin-Opener-Policy' = 'same-origin'
I think this will makes the running of wsam not practical for inappwebview unless you have access to the website or use a proxy to include headers.

[p-mazhnik]

You should also update type in flutter_inappwebview_web/lib/assets/web/web_support.js and in nativeCommunication-related code:

• flutter_inappwebview_web/lib/web/web_platform.dart: JSAny viewId, dynamic viewId
• flutter_inappwebview_web/lib/web/web_platform_manager.dart: webViews should have Map<String, dynamic> type
• flutter_inappwebview_web/lib/web/in_app_web_view_web_element.dart: dynamic _viewId
• other places where viewId is used as int or dynamic

As is, this PR could break functionality for cases where viewId is still used as int.

[alikamal1]

thank you @p-mazhnik .. I edited the part of flutter_inappwebview_web\lib\web\web_platform.dart to change int to string .. other parts are dynamic which should work without breaking functionality.

[ArturLevchuk]

@alikamal1 i tried your solution after this changes. now it fails :(

[alikamal1]

@ArturLevchuk I have revert it back for now

[ArturLevchuk]

@alikamal1 also as mentioned @p-mazhnik with String value only changed here it brokes callbacks like 'onLoadStart' , 'onLoadStop'... But if we passing value like (_viewId as int).toJS it works. Anyway callbacks on wasm mode still dead. I tested your solution on version 6.1.5 because on 6.2 callbacks dead on web in general

[pichillilorenzo]

Sorry guys, I will take a look at it deeper as soon as possible as I’m currently working on the 6.2.0 beta release, thanks!

[pichillilorenzo]

I managed to fix the issue. The problem was really simple, the _viewId should be converted to the correct JS type using the .toJS property, so I just used this code:

_viewId is int ? (_viewId as int).toJS : _viewId.toString().toJS

Thanks to everyone.
This should be available on the next 6.2.0 beta release 👍

[rohanacko]

When is 6.2 stable release planned? @pichillilorenzo