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

fix(ipc): fallback to postMessage if protocol fails, closes #8476 #9038

Merged
merged 1 commit into from
Feb 29, 2024

Conversation

lucasfernog
Copy link
Member

This PR changes the IPC mechanism to always support the custom-protocol and postMessage variants. The frontend now handles the custom protocol fetch call failing (usually due to CSP or webview denying access to the protocol) and fallbacks to the postMessage API).

The fixes for #7662 (#7751, #7754 and #7764) are still valid.

This is a more generic approach to #8887

@lucasfernog lucasfernog requested a review from a team as a code owner February 29, 2024 16:30
@lucasfernog lucasfernog merged commit a77be97 into dev Feb 29, 2024
20 checks passed
@lucasfernog lucasfernog deleted the feat/dynamic-ipc branch February 29, 2024 21:24
@thewh1teagle
Copy link
Contributor

thewh1teagle commented Mar 24, 2024

@lucasfernog
Looks like the IPC fallback doesn't work in case of CSP errors when plugins used (eg. event.listen).
Is there a way to control it manually and force use of old IPC only?

Also I when it fallback to postMessage if I return any object value (eg serde_json::Value) the promise doesn't resolve on webview2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants