I don’t know the underlying cause of this, so does anyone know if it makes sense that it would suddenly start happening in an app where it did not happen once through a couple of months of development, and not consistently? Several webviews all opened correctly, and then (day before delivery of the app of course 😉), without any change to how those webviews are triggered, the general structure of the app, or the OS/device/emulator it suddenly became “Fatal signal 11” city. Also, another potential solution may be to set androidHardwareAccelerationDisabled= as a prop to the WebView, although this will cause performance setback in rendering the WebView.
#Idisplay win 10 crashing android#
Update: the app only crashes for me an on Android emulator but running it on an actual Android device (API 28 Google Pixel) does not cause the app to crash. I put the opacity:0.99 on both the web views which are rendered in two separated components, but still no fix. I also tried the opacity: 0.99 fix on the style of the WebView itself, like suggested in #430, but that did not fix it for me. The problem for me occurs when I navigate back to the previous screen using react-navigation, which is meant to display another web view, but the Android app crashes unexpectedly.Īnyone know where I can find the android device logs to dive deeper into the problem. I display a web view in a screen and the view displays properly. In my case, I have a web view in two screens. 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). 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). Again, please do so on the public crbug.Īs a final plug: Android WebView has a beta channel, which allows your team to get WebView updates 6 weeks before users.
#Idisplay win 10 crashing how to#
You can help us by telling us your app’s package name and how to repro, so we can verify our fix is correct. 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). If you want to try workarounds, well, that’s a decision you could make. My team considers this to be a bug in WebView, and we’re working hard to solve it. Still have some hope there is a fix beyond waiting for Chromium to do something though
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). We recognize this bug affects real apps/users. 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 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). We aren’t trying to hide the fix from you.
Until it went moved to internal threads we can’t see
0 kommentar(er)
