Fixed
Status Update
Comments
ia...@gmail.com <ia...@gmail.com> #2
Comment has been deleted.
il...@google.com <il...@google.com> #4
Attached is a sample project that demonstrates the issue in two ways:
- when long pressing text (e.g. the headline)
- when opening a select
Both will ultimately load an alert dialog with a list adapter that has the layout ids for the content set to 0.
https://drive.google.com/file/d/1Fe2ym2F0o4XWEDHvKY8-UzpvSJq4wbWq/view?usp=drive_web (WebViewAppCompatBug.zip)
This is reproducible on an API 21 emulator (Nexus 5 configuration, no Chrome installed).
NB There is a second issue when loading the web view in the first place which in this sample project is worked around by using a resource wrapper. This is already reported underhttps://issuetracker.google.com/issues/140884278 and the attached project will also display this error when commenting out lines 13-15 in MainActivity.kt.
- when long pressing text (e.g. the headline)
- when opening a select
Both will ultimately load an alert dialog with a list adapter that has the layout ids for the content set to 0.
This is reproducible on an API 21 emulator (Nexus 5 configuration, no Chrome installed).
NB There is a second issue when loading the web view in the first place which in this sample project is worked around by using a resource wrapper. This is already reported under
pr...@google.com <pr...@google.com> #5
Please take a look at this issue and provide your inputs.
so...@gmail.com <so...@gmail.com> #6
Wrapping Resources is not supported by the framework and you must not create your own instances of Resources at all (the APIs to do so are now marked deprecated after they were accidentally exposed).
We can't do anything to fix this - you need to solve the underlying problem with appcompat and stop wrapping it like this, and then resources will work.
We can't do anything to fix this - you need to solve the underlying problem with appcompat and stop wrapping it like this, and then resources will work.
na...@gmail.com <na...@gmail.com> #7
While I agree this is WontFIx from WebView's perspective (the WebView APK in question already shipped), it seems like this should still be considered a regression from appcompat's perspective, given the community can no longer test on lower-level emulators. We've received several unique user reports of this issue, not to mention the internal reports which led to filing issue 139710458 .
Surprisingly, issue 142086375 claims this bug repros on Marshmallow, which is something we haven't observed so far and doesn't fit into the current hypothesis:
> in Android 6.0 (API 23) it crashes on tapping the <select> element.
---
From issue 141132133 :
> This change is the root cause:https://android.googlesource.com/platform/frameworks/support/+/26079d87c79a64829f036236353fac1dae4e0613%5E%21/#F2
>
> sAlwaysOverrideConfiguration forces updating the Resources configuration and therby messing up the webview inflation on older devices.
Chis, any chance this checks out? I didn't look too closely into this, so I'm not sure if there are consequences to not overriding the configuration on L-M only, or perhaps further limited old WebView versions only.
Surprisingly,
> in Android 6.0 (API 23) it crashes on tapping the <select> element.
---
From
> This change is the root cause:
>
> sAlwaysOverrideConfiguration forces updating the Resources configuration and therby messing up the webview inflation on older devices.
Chis, any chance this checks out? I didn't look too closely into this, so I'm not sure if there are consequences to not overriding the configuration on L-M only, or perhaps further limited old WebView versions only.
ju...@veepee.com <ju...@veepee.com> #8
Same problem appear simply by using a WebView on Android 5 / 5.1 (on actual devices, no emulator) with appcompat:1.1.0 directly causing a crash (on display, no interaction needed).
Description
The use case is that I would like to start Activity being sure that the context used will not crash my app in case I missed a flag or I had to instantiate a Dialog using the local context.