WebView select boxes drop down dialogs are throwing on some tablets #54164
Comments
amirh
added
platform-android
|
This only happens with Android WebView versions older than 67.0.3367.0 (prior to Chromium commit afb450). Before afb450, on tablets Chromium used a With Android WebView versions prior to afb450, the following sequence happens when a select drop down is shown:
This is an unfortunate case where a combination of grey area behaviors by Flutter, Chromium, and Android, each work on their own, crash when they are combined together. This crash should not be popular as it requires a combination of an old Chromium version (vast majority of devices have a newer webview than I can imagine a workaround in the form of preventing the webview's focus lost listener from being invoked in this specific case, though I'm not super excited to land such a hack. I'm currently working with |
|
We need to workaround as I tried this as a workaround (in our @Override
protected void onFocusChanged(boolean focused, int direction, Rect previouslyFocusedRect) {
if (isCalledFromListPopupWindowShow() && !focused) {
return;
}
super.onFocusChanged(focused, direction, previouslyFocusedRect);
}
private boolean isCalledFromListPopupWindowShow() {
StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace();
for (int i = 0; i < stackTraceElements.length; i++) {
if (stackTraceElements[i].getClassName().equals(ListPopupWindow.class.getCanonicalName())
&& stackTraceElements[i].getMethodName().equals("show")) {
return true;
}
}
return false;
}
Extremely hacky. But seems to work. I'm actually considering landing this given that I know for sure that with the current implementations of Difficulty testing thisIntegration testThis is the kind of fix that would normally make most sense to test with an integration test, though integration testing this is going to have a significant overhead (as non of the available emulator images use an old enough webview to have this bug, it will probably require us to set up our own emulator image which is not a business I want to get into), and probably puts Unit testingThis is not really trivial to test, you would normally want to confirm whether Something we can do is instrument our overridden Testing exemption?Flutter's testing policy has been recently formalized as: no code lands without a test, on extreme cases a testing exemption should be approved by @Hixie. I think this is a case where our limited ability to unit test, and the high cost of putting together an integration test harness (both bootstraping and ongoing maintenance of an emulator image with an outdated Android webview), in addition with the low and temporary return (the vast majority of webviews out there don't have this issue, and AT are likely to upgrade soon as well) calls for a test exemption. @Hixie do you approve? |
|
can you unit test isCalledFromListPopupWindowShow() in some way? e.g. pass it a stack trace known to be relevant, and one known not to be, and verify that it handles them correctly? anyway, skipping tests here is fine either way given your description, thanks for checking. |
jmagman
added this to Awaiting triage
in Mobile - Android platform view review
via automation
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
The failing codepath is only active on tablets, I was only able to reproduce the crash on Android Things.
Repro steps, load a web page with a drop-down select box (like:
https://loc.gov) on a tablet running Android Things, and tap the drop down.The following exception is thrown:
Note: I'm assigning April milestone as this is when
customer: dreamwant it by, though at this point I'm still investigating and before we root cause the issue I have no real estimate for how involved is the fix.b/152465158
The text was updated successfully, but these errors were encountered: