Skip to content

Commit 3f3394a

Browse files
Rachit Mishrafacebook-github-bot
Rachit Mishra
authored andcommitted
fix: handle webview provider missing exception (#34456)
Summary: The [existing fix](https://github.com/facebook/react-native/blob/fb936dfffb3ca2d9bc0969dfe36a70bdf66783e0/ReactAndroid/src/main/java/com/facebook/react/modules/network/ForwardingCookieHandler.java#L151) to handle missing WebView provider uses string comparison based checks to handle the exception gracefully, or otherwise simply throw the exception. This ends up crashing the app for the end user. <img width="1319" alt="Screenshot 2022-08-19 at 4 33 31 PM" src="https://user-images.githubusercontent.com/933314/185605137-24757dad-806e-4cca-b000-7d6ce2d191e1.png"> Fatal exceptions are bad in any case and not good user experience, we can gracefully handle this by [returning](main...rachitmishra:react-native-1:patch-2#diff-f7ca1976002c4612051e4949395e64511b6f769e347c488e9a0d15cb5331fe76R141) `null` for all cases when WebView provider is not found. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [Android] [Fixed] - Gracefully handle crash if no WebView provider is found on the device Pull Request resolved: #34456 Test Plan: IMO no testing is required as we were already returning null in certain cases after handling the exception message, also `ForwardingCookieManager::getCookieManager` is already marked `Nullable` so we are safe there. Reviewed By: lunaleaps Differential Revision: D39809020 Pulled By: cortinico fbshipit-source-id: 54b290ad7740859bdc84401904236c32761a4631
1 parent 8cdc9e7 commit 3f3394a

File tree

1 file changed

+12
-21
lines changed

1 file changed

+12
-21
lines changed

ReactAndroid/src/main/java/com/facebook/react/modules/network/ForwardingCookieHandler.java

Lines changed: 12 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -138,27 +138,18 @@ protected void doInBackgroundGuarded(Void... params) {
138138
// https://bugs.chromium.org/p/chromium/issues/detail?id=559720
139139
return null;
140140
} catch (Exception exception) {
141-
String message = exception.getMessage();
142-
// We cannot catch MissingWebViewPackageException as it is in a private / system API
143-
// class. This validates the exception's message to ensure we are only handling this
144-
// specific exception.
145-
// The exception class doesn't always contain the correct name as it depends on the OEM
146-
// and OS version. It is better to check the message for clues regarding the exception
147-
// as that is somewhat consistent across OEMs.
148-
// For instance, the Exception thrown on OxygenOS 11 is a RuntimeException but the message
149-
// contains the required strings.
150-
// https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/WebViewFactory.java#348
151-
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException")
152-
|| (message != null
153-
&& (message.contains("WebView provider")
154-
|| message.contains("No WebView installed")
155-
|| message.contains("Cannot load WebView")
156-
|| message.contains("disableWebView")
157-
|| message.contains("WebView is disabled")))) {
158-
return null;
159-
} else {
160-
throw exception;
161-
}
141+
// Ideally we would like to catch a `MissingWebViewPackageException` here.
142+
// That API is private so we can't access it.
143+
// Historically we used string matching on the error message to understand
144+
// if the exception was a Missing Webview One.
145+
// OEMs have been customizing that message making really hard to catch it.
146+
// Therefore we result to returning null as a default instead of rethrowing
147+
// the exception as it will result in a app crash at runtime.
148+
// a) We will return null for all the other unhandled conditions when a webview provider is
149+
// not found.
150+
// b) We already have null checks in place for `getCookieManager()` calls.
151+
// c) We have annotated the method as @Nullable to notify future devs about our return type.
152+
return null;
162153
}
163154
}
164155

0 commit comments

Comments
 (0)