Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: SharedArrayBuffer support #6182

Closed
1 task done
marcelo-nagatomo opened this issue Dec 21, 2022 · 6 comments
Closed
1 task done

bug: SharedArrayBuffer support #6182

marcelo-nagatomo opened this issue Dec 21, 2022 · 6 comments
Labels
needs reproduction needs reproducible example to illustrate the issue platform: ios

Comments

@marcelo-nagatomo
Copy link

marcelo-nagatomo commented Dec 21, 2022

Bug Report

Capacitor Version

💊   Capacitor Doctor  💊 

Latest Dependencies:

  @capacitor/cli: 4.6.1
  @capacitor/core: 4.6.1
  @capacitor/android: 4.6.1
  @capacitor/ios: 4.6.1

Installed Dependencies:

  @capacitor/android: not installed
  @capacitor/cli: 4.6.1
  @capacitor/core: 4.6.1
  @capacitor/ios: 4.6.1

Platform(s)

  • iOS

Current Behavior

I'm using the latest Cornerstone.js for scan/image viewing which heavily uses SharedArrayBuffer.

To enable SharedArrayBuffer I need to set the following Response headers at the top HTML Document level, - capacitor://localhost for iOS:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

After digging into the code, it seems capacitor-ios uses WebKit UrlSchemeHandler to load the local files via capacitor://localhost and it always set some Response headers as default. e.g. "Cache-Control": "no-cache":

Screen Shot 2022-12-21 at 12 04 00 am

Screen Shot 2022-12-21 at 12 05 38 am

However, these default headers (or even the 200 status code) are not included in the initial files loaded to launch the app:
Screen Shot 2022-12-20 at 11 40 52 pm

Since I cannot set custom Response headers at the top level, I cannot use SharedArrayBuffer in Ionic apps.

Expected Behavior

All Reponse headers set on WebViewAssetHandler should be included on all files loaded during app initialisation.

Code Reproduction

The code reproduction can be found here: https://github.com/marcelo-nagatomo/capacitor-issue-6182

Other Technical Details

npm --version output: 8.19.2

node --version output: v16.18.1

pod --version output (iOS issues only): 1.11.2

iOS version: 15.2

Additional Context

Similar issue was previously reported: #4520

I'm also investigating the same issue on Cordova, on that case the WKWebView initially loads with correct headers but the WebView is reloaded at some point and the Response headers information is lost. I'm not sure if the same happens in Capacitor though.

More info on COOP/COEP headers: https://web.dev/why-coop-coep/

@ionitron-bot ionitron-bot bot added the triage label Dec 21, 2022
@ionitron-bot ionitron-bot bot removed the triage label Dec 21, 2022
@jcesarmobile jcesarmobile added the needs reproduction needs reproducible example to illustrate the issue label Dec 21, 2022
@Ionitron
Copy link
Collaborator

This issue may need more information before it can be addressed. In particular, it will need a reliable Code Reproduction that demonstrates the issue.

Please see the Contributing Guide for how to create a Code Reproduction.

Thanks!
Ionitron 💙

@Ionitron Ionitron added the needs reply needs reply from the user label Dec 21, 2022
@marcelo-nagatomo
Copy link
Author

@jcesarmobile thanks for your time, I've added the reproduction code here:
https://github.com/marcelo-nagatomo/capacitor-issue-6182

@Ionitron Ionitron removed the needs reply needs reply from the user label Dec 21, 2022
@marcelo-nagatomo
Copy link
Author

After more debugging I noticed the following behaviour:

If we add a breakpoint before the WebView is created and we slowly go step-by-step until the WebView is instantiated, we can open Safari DevTools and inspect the WebView while the app is still called about:blank:
Screen Shot 2022-12-21 at 6 32 22 pm

If we keep going step-by-step until the application fully starts, then we can see that the Response headers are set correctly by the URLSchemeHandler:
Screen Shot 2022-12-21 at 6 06 32 pm

However, at some point the WebView seems to be reloaded and once that happens all Response headers are lost.

My question is why this reload happens? Is it part of Capacitor lifecycle? Can we prevent the second reload?

@marcelo-nagatomo
Copy link
Author

marcelo-nagatomo commented Dec 22, 2022

Found this related discussion on the community:
#5502

@marcelo-nagatomo
Copy link
Author

Ok, I did more investigations on this issue and here is my findings:

  1. This is not a capacitor issue! We tried to replicate this issue on a native iOS project using the WKUrlSchemeHandler as it's done by capacitor-ios to serve the local files. The same behavior stated here is seen on native iOS so this is likely to be on WebKit itself and not on capacitor.
    More details about this implementation can be found here: https://dev.to/gualtierofr/custom-url-schemes-in-a-wkwebview-oak

  2. I was able to set the response headers and enable SharedArrayBuffer using cordova-plugin-ionic-webview@2.5.3 and changing local web server code to add the COEP/COOP headers.
    I'd say a local web server is a more solid solution than URLSchemeHandler now and it's also consistent to what's being done on Android.

  3. Android Webview seems to not support COOP header today, even if it supports SharedArrayBuffer we can't enable this feature via the header 'cause there's no site isolation support on Android Webview.
    More info: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#modes-and-availability

@jcesarmobile I'm closing this issue!

@ionitron-bot
Copy link

ionitron-bot bot commented Feb 5, 2023

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out.

@ionitron-bot ionitron-bot bot locked and limited conversation to collaborators Feb 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs reproduction needs reproducible example to illustrate the issue platform: ios
Projects
None yet
Development

No branches or pull requests

3 participants