react-native-webview: [ANDROID] Crashes appeared around March 13th (Chrome 73)
We have encountered an issue when using Android 9 in combination with Chrome 73. When wrapping a WebView within a View styled with overflow: hidden the entire app crashes. I solved it by setting opacity: 0.99 on the WebView, and keep the overflow: hidden style on the wrapper. I found the solution here.
This problem will most likely be more and more common since more and more people are getting Chrome 73 each day.
I hope this issue will be useful to some people that are experiencing the same problem. However, this is not an elegant solution and I would be very happy if someone with more Android knowledge could give it a shot and try to fix the real problem.
Thanks!
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 49
- Comments: 67 (3 by maintainers)
Commits related to this issue
- Fix Android ANR's Summary: Fixes android ANR's based on this link: https://github.com/react-native-community/react-native-webview/issues/429 Changes 2 properties for a hidden container, which is lik... — committed to wildfyre-app/web by deleted user 5 years ago
- [Wallet] Apply WebView opacity hack fix globally (#6498) ### Description Wrap the `opacity: 0.99` hack into our own `WebView`, so we can apply it everywhere we use a `WebView`, instead of duplicat... — committed to celo-org/celo-monorepo by jeanregisser 3 years ago
- fix:Android11 or higher crush https://github.com/react-native-webview/react-native-webview/issues/430 https://github.com/react-native-webview/react-native-webview/issues/429 — committed to batazo/react-native-youtube-iframe by batazo 9 months ago
Adding
androidHardwareAccelerationDisabledreally hits the performance hard. The following worked for me:Adding not only the
opacitybut also theminHeightdoes the trick for me.We aren’t trying to hide the fix from you. We merged this into an auto-reported crash report, which we hide from the public by default to protect user security (the report has detailed crash stacks, which might potentially help a malicious actor trigger crashes or exploit user security). Fixes are landing (commit, commit). The public issue should still be comment-able, and you can ask on that ticket to hear status updates (I’ve pinged the thread to ask what state the bug is in).
We recognize this bug affects real apps/users. Please understand this is not an intentional change, and bugs slip into every release (chromium is a relatively complex project, making it hard to verify every use case).
My team considers this to be a bug in WebView, and we’re working hard to solve it. If you want to try workarounds, well, that’s a decision you could make. I’d recommend you consider waiting until we release a fix (you can see we triaged this for M73, so that should be a matter of days rather than a 6-week release cycle). You can help us by telling us your app’s package name and how to repro, so we can verify our fix is correct. Again, please do so on the public crbug.
As a final plug: Android WebView has a beta channel, which allows your team to get WebView updates 6 weeks before users. You can use this as an opportunity to smoke test your app to make sure our team hasn’t accidentally broken it (and if we have, please file bugs against us).
Please take all of my comments with a grain of salt: I’m not promising what my team will push to production, I’m only trying to improve visibility and provide advice (based purely on the publicly available information).
@Titozzz don’t be sad. I think this package has seen some great improvement since it has been extracted from react-native. Love where it’s going and this sort of bug is not something you can prepare for.
Since webviews do not crash when loaded inside a react-native Modal component on Android 9 with Chrome 73 i still have some hope there is a fix beyond waiting for Chromium to do something though. I’d rather not wait for that 😃 Still think there is something in the interaction between the webview and the type of component it’s embedded in specifically in react-native that is triggering this render crash.
Just to add some more context; we too experienced this issue once Chrome 73 started rolling out last thursday. We had about 150.000 crashes before we applied the opacity: 0.99 hack which fixed it in most cases. We did however run into an issue with that fix where it prevents the webview content from rendering correctly (scroll actions behave erratically, taps are registered in different location from the actual tap) with the fix applied. Seems to be limited to large webviews e.g. 5000px high embedded in a ScrollView. For those specific webview we now open them in a Modal which seems to ‘fix’ the crash even without needing the opacity: 0.99 fix. We are still in the middle of researching this so i don’t have much more specific info than that but perhaps this extra info will help someone out who is running into the same issue.
It’s not stale.
FYI it appears to be fixed on chromium team side so we are now just wait for the release 😍
@Salakar @Titozzz I’ve created a sample app that crashes on the following device: Android 9; Nokia 6.1 with Chrome 73.0.3683.75.
https://github.com/lukebaker/WebViewScrollBug
Steps to reproduce should be:
Still alive problem should be reopened
This was probably not stale, but I’m also no longer interested in having to keep this open by some horrible bot that does nothing but generate more noise. Good luck everyone!
I added
overScrollMode="never"to my containerScrollViewand that seems to have fixed the problem for me.I noticed that the app crashes only the second time you mount a screen containing the WebView component. But the first time, it works fine. I am not sure if this happens for you too.
Another thing I noticed was that the app crash only occurs in the Android emulator but when run on a device, the app does not crash even when the second time the screen with the WebView component is loaded. That being said, make sure, to all of you facing this app crash issue, to ALSO test the app crash behaviour on your physical Android devices! You can simply connect your mobile to the computer via a cable and then enable USB Debugging and run the app on the device on WebStorm or whatever IDE you use.
Looks like it was released today. Tested and fixed. Thank you @nfischer 🎉
I can confirm that it still happens and that the 0.99 hack still works.
@Titozzz Thanks for the test and update! I just give a try, it is also fixing my problem as well!! But user need to upgrade their android chrome to the latest 73.03683.90 version. (the buggy version is 73.0.3683.75),
For other people, just a remainder make sure you update the android chrome before doing the test~~
@Titozzz Maybe we should still pin this issue at the top just for little while longer?
@nfischer thanks so much to fix it!
Just a piece of though - we did find a workaround but it’s the hackiest thing I’ve seen in a while and it’s extremely error-prone. You can implement special Android Chrome 72+ dedicated screens which will route to new stacks after Webviews are loaded and come back right after to have everything work without overflow: hidden. Don’t implement it in your codebases tho! I mean it, it will work but you are almost 100% better of waiting for a serious fix.
Thank you for noticing this issue so fast, we can’t wait for a reliable fix!
@nfischer I did not mean anything bad, just described the current situation so that users don’t panic. I well aware you guys are probably handling this right now 💪.
@salakar this made me think, would it be possible to write a test for detox with different chrome versions?
I can confirm that it still happens and that the 0.99 hack still works.
I have not confirmed this works without the 0.99 opacity hack, and I see others are still searching for solutions. I doubt it’s actually fixed/addressed.
Are you using react-navigation? If so have you tried this: https://github.com/facebook/react-native/issues/25494#issuecomment-724871241
This is still an issue for me using Android 11. No amount of opacity hacks are helping me ether. The web view renders fine but as soon as i change pages it crashes.
The bug I’m referring to was in Android WebView (the project I work on), not in the react-native-webview library. WebView updates automatically on users’ Android devices, your app doesn’t need to do anything.
If you can reproduce this, please file a bug for the Android WebView team at https://bugs.chromium.org/p/chromium/issues/entry?template=Webview+Bugs
@nfischer this is 100% not solved in 9.4.0 of this library; people on expo are “stuck” with
"react-native-webview": "9.4.0",for the time being, so unsure (of the little information you’ve given) if this would be a fix that’s pushed to android phones via the webview update or if people need to update something here.We thought it might be #1161, but crashes happen both on mount and unmount, also on up-to-date 2016 class phones and later. The gist is, as soon as an app starts crashing because of a webview inside a scrollview, it doesn’t get back into a fixed state. Uninstalling and re-installing the app might work, for a while, until it starts happening.
Once we added
opacity: 0.99it started working without crashes, on all phones.My team and I also encountered this issue and fixed it by setting
opacity: 0.99.Could someone explain how/why that work? Since it looks like magic/sorcery to me.
@Titozzz Many thanks for the reply! please keep us update if you got anything ~ 😃
I like the thought of this but I don’t think we can 😞 not sure how we could control changing which webview to use in dev settings for example as detox only has apis to control the app
@tijs Thanks, you made my day. 😃
@Titozzz The device logs didn’t give us that much:
To reproduce it you have to: