There is at least a workaround, from one of those other issues:

<WebView
  domStorageEnabled={ true }
  javaScriptEnabled={ true }
  renderError={ (e) => {
    if (e === 'WebKitErrorDomain') {
      return
    }
  }}
  source={{ uri: "https://99f9e623.ngrok.io/auth/sign_in_with_slack?source=app" }}
  style={ styles.container }
/>

The question which I don't know the answer to is whether this behavior is inherent to WebView and the right solution is switching to WKWebView (as some have suggested), or whether this can just be fixed in WebView.

@lacker that workaround does not solve this issue for me :( it only hides the error message but the webview turns blank when it happens.

I'm testing in react-native 0.36.1.

yes @lacker, that workaround does not seem to work.

Well an easy solution would be just to return NO for shouldStartLoadWithRequest if the protocol is not HTTP or HTTPS: https://github.com/facebook/react-native/blob/master/React/Views/RCTWebView.m#L251

Any idea what the repercussions might be if that were the case?

Alternatively, could add a property to WebView supporting an array of ignored protocols. For a quick and dirty solution until this is resolved I modified the above linked line as such to support Plaid Link:

if (!isJSNavigation) {
	BOOL isPlaidNavigation = [request.URL.scheme isEqualToString:@"plaidlink"];
	return !isPlaidNavigation;
}
return YES;

There also seems to be a shouldStartLoadWithRequest prop on the WebView RN component, but it is undocumented and I am not sure if it works completely.

@jjshammas Do you have working example for your RCTWebView? I am trying to get it to work with Plaid Link too with not much luck :/

I'm on RN version 0.43,I have this problem too
Have you fixed this problem, please help?
@lacker @eggli

@firetheworld Yes, we did solve this problem by doing it in a super brutal and not-very-open-source-way: We wrote our own iOS WebView to replace React Native's built in since no one in Facebook cares about this problem and we found it's not easy to solve, here's our solution, it's brutal, not very cool, but it works:

- (BOOL)webView:(__unused UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
 navigationType:(UIWebViewNavigationType)navigationType
{
 
  if (![request.URL.scheme isEqual:@"http"] && 
      ![request.URL.scheme isEqual:@"https"] && 
      ![request.URL.scheme isEqual:@"about:blank"]) {
         if ([[UIApplication sharedApplication]canOpenURL:request.URL]) {
             [[UIApplication sharedApplication]openURL:request.URL];
         }
      return NO;
  }

return YES;

}

In the code above, if we found the URL is not whatever we can handle, we skip it to avoid any error message being throw to React Native, and asks iOS if user's device is capable to handle that custom scheme url, if so, we hand over the URL to iOS so user still get other apps' deep linking URL working.

I believe there SHOULD be a better way ( or at least a neat one ) to handle this.

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

Any update on whether this will be fixed in a future release? Still having the exact same issue