Skip to content

Commit d1821cc

Browse files
sganovAndroid (Google) Code Review
authored andcommitted
This is wrong since it fixed the symptom not the problem. Alan is uploading a correct patch.
Revert "Reducing WebView navigation timeout for accessibility." This reverts commit 2203cf3 Change-Id: I5b2d999851af98acb953529ebfcda608ce27799d
1 parent 2203cf3 commit d1821cc

File tree

1 file changed

+1
-12
lines changed

1 file changed

+1
-12
lines changed

core/java/android/webkit/AccessibilityInjector.java

Lines changed: 1 addition & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -710,18 +710,7 @@ private static class CallbackHandler {
710710
"javascript:(function() { %s.onResult(%d, %s); })();";
711711

712712
// Time in milliseconds to wait for a result before failing.
713-
// Based on recorded times, we have found that in a complex real-world
714-
// web app (such as the desktop version of Gmail), there can be spikes
715-
// of ~2600ms in the worst case. These are temporary spikes and are not
716-
// repeatable; GMail eventually settles down to around ~60ms. The
717-
// longest duration that is consistently repeatable is ~300ms when
718-
// loading extremely large plain text documents in WebView.
719-
// If this timeout hits, the navigation is considered to have "failed",
720-
// meaning there is no content. Since the longer spikes are one-off
721-
// events triggered by the page loading and itself running a large
722-
// amount of JS, subsequent runs would succeed, so the worst impact
723-
// is that the first run will look like it had not loaded yet.
724-
private static final long RESULT_TIMEOUT = 1500;
713+
private static final long RESULT_TIMEOUT = 5000;
725714

726715
private final AtomicInteger mResultIdCounter = new AtomicInteger();
727716
private final Object mResultLock = new Object();

0 commit comments

Comments
 (0)