react-native-webview: Inconsistent onNavigationStateChange behaviour between iOS and Android for SPAs
Bug description:
When navigating on an SPA that modifies the URL (history) without making any request, iOS will trigger the onNavigationStateChange event and Android will not.
Investigating the cause of this it seems that the iOS implementation deliberately injects JavaScript with a history shim using the pushState API. This posts back messages that are intercepted and used to trigger an onLoadingFinish, that in turn generates the onNavigationStateChange.
This injected history shim is simply not present on Android. The pushState API did not used to be available pre-Android 5.0, but should be in all versions currently supported by React Native.
This being missing on Android is problematic for custom hardware back handling with SPAs in web views.
Can we add this history shim functionality to match on Android? There have been reports of problems with this functionality on Android in the past but they were closed due to inactivity.
If this is desirable, but no-one is able to pick this up soon, would you be open to a contribution implementing it?
To Reproduce:
Point webview at an SPA and an onNavigationStateChange handler.
Expected behavior: Same behaviour on each platform.
Environment: Tested on:
- OS: iOS and Android
- OS version: iOS 15.5, Android 13
- react-native version: 0.70.0
- react-native-webview version: 11.23.1
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 2
- Comments: 22
Commits related to this issue
- fix: react-native-webview target="_blank" on iOS Also fix the html5 history.pushState navigation on android More infos on both issues below: - https://github.com/react-native-webview/react-native-webv... — committed to LedgerHQ/ledger-live by Justkant a year ago
- fix: react-native-webview target="_blank" on iOS Also fix the html5 history.pushState navigation on android More infos on both issues below: - https://github.com/react-native-webview/react-native-webv... — committed to LedgerHQ/ledger-live by Justkant a year ago
- fix: react-native-webview target="_blank" on iOS Also fix the html5 history.pushState navigation on android More infos on both issues below: - https://github.com/react-native-webview/react-native-webv... — committed to LedgerHQ/ledger-live by Justkant a year ago
- fix: react-native-webview target="_blank" on iOS Also fix the html5 history.pushState navigation on android More infos on both issues below: - https://github.com/react-native-webview/react-native-webv... — committed to LedgerHQ/ledger-live by Justkant a year ago
- Stacks integration - rebased (#16) * chore: remove extra commitlint.out * added PTX player on LLM * removed temporary code * support: add e2e tests for install and restore set of apps in LLD... — committed to Zondax/ledger-live by haammar-ledger a year ago
This fix is still needed
We’ve actually patched our usage of web view for this problem:
Just wanted to reiterate what krzysztofnowak said. This fix is still needed. I updated to 12.1.0 and I’m still having the same issues with this.Edit: I realized I was incorrect and posted below as an update.
If you’re going with patching node_modules then I strongly recommend using patch-package: https://www.npmjs.com/package/patch-package
That way the patched version becomes part of your module install process and you will be alerted on upgrade if the patch can’t be applied cleanly.
I believe there’s a Kotlin rewrite going on, hopefully it’ll include something like the above patch, but if not, I’m not really expecting anyone to consider a PR until after that’s done and shipped.
You can also inject JavaScript that shims the History API like they do on iOS, but entirely from the JS side, then track whether you can go back in the
onMessagehandler. That’s what I’m doing while waiting for some response on whether a PR (like the patch above) would be accepted.I’m facing same issues, any fixes?
Latest version 13.8.6 causes weird infinite reloading page in my case, so this issue is not fixed
i am having the same issue on android, some of the redirections on SPA are not at all intercepted. and some times detected but randomly