Update web_embedding to new bootstrapping templates

[johnpryan]

No description provided.

[ekuleshov]

@johnpryan is WASM support for that is on the table or should I open a separate issue once this issue is closed?

I tried to update the web_embedding/element_embedding_demo/web/index.html to this and then flutter build web --wasm and local dhttpd as described in the WASM docs.

    <script>
      {{flutter_js}}
      {{flutter_build_config}}

      let target = document.querySelector("#flutter_target");
      _flutter.loader.load({
        config: {hostElement: target},
      });
    </script>
    <script src="js/demo-js-interop.js" defer></script>
    <script src="js/demo-css-fx.js" defer></script>

[parlough]

\cc @ditman For any potential input/thoughts on ^.

[ditman]

@parlough this is most likely related to the web_embedding demo using an "outdated" js-interop mechanism, compared to what's needed for WASM. (never attempted to compile this example to WASM, tbh!)

[ekuleshov]

@ditman it compiles fine, but fail at runtime. I wonder if there is a better way.

My own app compiled to wasm seem to run in embedded element, but fail to get data from a rest service when running on a local httpd due to cors. Could really use some support in tools for that

[ditman]

fail to get data from a rest service when running on a local httpd due to cors.

@ekuleshov It's hard to help without seeing the specific errors, but CORS errors should be independent from Wasm compilation, you should have the same issues when compiling to JS.

[ekuleshov]

@ditman my current workaround is to use the following command to get a Chrome browser instance with web security disabled

flutter run -d chrome --web-browser-flag "--disable-web-security"

Then follow the Flutter WASM instructions to build and serve locally.

Then use the above Chrome instance with disabled web security to open locally served WASM web app on http://localhost:8080/

The CORS-restricted resources usually give a generic error, like ClientException: XMLHttpRequest error., uri=https://some.cors-protected.remote.api/ with stack trace:

dart-sdk/lib/_internal/js_dev_runtime/patch/core_patch.dart 843:28  get current
packages/http/src/browser_client.dart 98:22                         <fn>
dart-sdk/lib/async/zone.dart 1661:54                                runUnary
...

[ditman]

@ekuleshov right, but you can't expect your users to disable web security for your app to work. I'd recommend that you ensure that the response for the resource you're downloading is allow-listing the domain of your web app to use CORS as intended.

If enabling CORS for your app on the server-side is not enabled (maybe because you don't own the service), then you can either proxy, or fall back to img tags using HtmlElementView.fromTag (platform views, which won't behave exactly identically to the canvas version when compositing, filtering, effects...)

[ekuleshov]

@ditman that is exactly the issue I'm referring to. The external resource is configured with CORS and it disallow access from a web application with a localhost origin (i.e. served locally). There is no issue when web application is co-hosted there in production, but in dev/debugging environment the web application can't load these resources.

I guess the dhttpd configuration to serve WASM locally is serving a similar purpose. And it is somewhat non-trivial to configure proxy and/or dns to make requests from a locally served web application (both WASM and JS) to match with the origin expected by CORS.

I guess this discussion deviated from this specific issue...

[ditman]

I guess this discussion deviated from this specific issue...

Haha yes, also you'd have the same issue with any other web stack, not just Flutter Web :P

[ekuleshov]

Haha yes, also you'd have the same issue with any other web stack, not just Flutter Web :P

True to some extent. Yet Flutter is somewhat special with its flutter run ... command and even dhttpd tool for local WASM serving.