iOS Crash [RNCWebViewDecisionManager setResult:forLockIdentifier:]

[MAKARD]

Since the time we updated react-native-webview from 12.4.0 to 13.3.1, we constantly see the following crash on iOS devices:

0   libobjc.A.dylib               	0x00000001a4de5c08 objc_msgSend + 8 (:-1)
1   CoreFoundation                	0x00000001abc5d844 -[__NSDictionaryM objectForKey:] + 164 (NSDictionaryM_Common.h:32)
2   MyApp                	        0x0000000103069bf4 -[RNCWebViewDecisionManager setResult:forLockIdentifier:] + 116 (RNCWebViewDecisionManager.m:29)
3   MyApp                	        0x0000000103074648 -[RNCWebViewManager shouldStartLoadWithLockIdentifier:lockIdentifier:] + 60 (RNCWebViewManager.mm:219)
4   CoreFoundation                	0x00000001abccf6b4 __invoking___ + 148 (:-1)
5   CoreFoundation                	0x00000001abc7bb1c -[NSInvocation invoke] + 428 (NSForwarding.m:3377)
6   CoreFoundation                	0x00000001abc7b534 -[NSInvocation invokeWithTarget:] + 64 (NSForwarding.m:3474)
7   MyApp                	        0x0000000102dc1954 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 388 (RCTModuleMethod.mm:584)
8   MyApp                	        0x0000000102dc39a4 facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) + 456 (RCTNativeModule.mm:197)
9   MyApp                	        0x0000000102dc35f4 facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)::$_0::operator()() const + 68 (RCTNativeModule.mm:114)
10  MyApp                	        0x0000000102dc35f4 invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int) + 112 (RCTNativeModule.mm:105)
11  libdispatch.dylib             	0x00000001b327b460 _dispatch_call_block_and_release + 32 (init.c:1518)
12  libdispatch.dylib             	0x00000001b327cf88 _dispatch_client_callout + 20 (object.m:560)
13  libdispatch.dylib             	0x00000001b3284640 _dispatch_lane_serial_drain + 672 (inline_internal.h:2632)
14  libdispatch.dylib             	0x00000001b328518c _dispatch_lane_invoke + 384 (queue.c:3940)
15  libdispatch.dylib             	0x00000001b328fe10 _dispatch_workloop_worker_thread + 652 (queue.c:6876)
16  libsystem_pthread.dylib       	0x00000001f9edcdf8 _pthread_wqthread + 288 (pthread.c:2618)
17  libsystem_pthread.dylib       	0x00000001f9edcb98 start_wqthread + 8 (:-1)

Bug description: With an overall audience of 500K iOS users, we've got only 300 users faced with this issue for the last month, it's an edge case.

To Reproduce: According to our tracking system, there are no specific steps to reproduce, users try to open WebView, and get the crash. We don't see anything common(apart from opening WebView) for different occurrences.

Expected behavior: App is not crashing:)

Screenshots/Videos: N/A

Environment:

• OS:iOS
• OS version:15.x, 16.x, 17.x
• react-native version: 0.72.4
• react-native-webview version: 13.3.1

[chhornponleu]

same crash on ios

"react-native": 0.72.4,
"react-native-webview": "13.2.2",

[LukasBombach]

We get those too, with exactly the same version numbers as @chhornponleu . We also use a custom native config with a natively implemented WebView. I am not sure if you do that as well or of this is independent of that.

[LukasBombach]

The diff of 12.4.0 vs 13.3.1 shows that they introduced these lines of code:

    if (_onOpenWindow && !hasTargetFrame) {
      // When OnOpenWindow should be called, we want to prevent the navigation
      // If not prevented, the `decisionHandler` is called first and after that `createWebViewWithConfiguration` is called
      // In that order the WebView's ref would be updated with the target URL even if `createWebViewWithConfiguration` does not call `loadRequest`
      // So the WebView's document stays on the current URL, but the WebView's ref is replaced by the target URL
      // By preventing the navigation here, we also prevent the WebView's ref mutation
      // The counterpart is that we have to manually call `_onOpenWindow` here, because no navigation means no call to `createWebViewWithConfiguration`
      NSMutableDictionary<NSString *, id> *event = [self baseEvent];
      [event addEntriesFromDictionary: @{@"targetUrl": request.URL.absoluteString}];
      decisionHandler(WKNavigationActionPolicyCancel);
      _onOpenWindow(event);
      return;
    }

which acts on the decision handler that throws the error here

[LukasBombach]

Just random intel: I thought this error would occour when there's calls to window.open from the WebView so we tried to roll-out a fix where we shimmed window.open with location.assign, but we still get that error, so this is not te cause.

[MAKARD]

still the issue for react-native-webview 13.6.2 on react-native 0.72.6

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[MAKARD]

still searching for solutions

[thep-dr]

We are seeing the same issue on 13.6.2

[MAKARD]

still the issue for react-native-webview 13.8.1 on react-native 0.73.5

I have a feeling the issue occurs because of some other 3rd party

@thep-dr @LukasBombach @chhornponleu Are you guys still seeing this issue as well?

Maybe we can share package.json dependencies of projects and try to find a common dependency that could potentially affect webview?

[LukasBombach]

@MAKARD we use the nativeConfig prop of react-native-webview to pass a native instance of WKWebView. On that Webview we have three third party libraries that fiddle with that instance:

1. GoogleMobileAds
2. TaboolaSDK
3. IOMbLibrary (that's a German thing, some tracking library for advertisement folks)

[MAKARD]

@LukasBombach, the only thing we have that is similar to your configuration is content-square integration, especially this part of integration https://docs.contentsquare.com/en/react-native/track-webviews/

So maybe that could be the cause, can't imagine how and why it could affect webview though

[MatthiasDh]

Also having this error, while not using any of the libraries mentioned here.

On version 13.6.2

[MatthiasDh]

@Titozzz do you have any idea what is going on?

This is causing a lot of issues for one of our largest customers.

I've been trying to see what the cause is but can't find a lead.

[MatthiasDh]

@chhornponleu @MAKARD @LukasBombach have you guys been able to find a solution?

[chhornponleu]

@MAKARD @MatthiasDh I remember that WebView without onContentProcessDidTerminate made app crash on iOS when it stay in background for a while and return back but i didn't noticed the error log at that time. I've just found out that the screen that reported the crash also has multiple WebView without the prop.

I'm preparing the next app release with the prop soon. It's just what I guess. Will report back the result!

Sample

<Webview
  ....
  onContentProcessDidTerminate={() => {
     // screen will be white blank, so try to reload webview or ...
  }}
/>

[MatthiasDh]

We have onContentProcessDidTerminate implemented but that doesn't get triggered when this error is received for some reason unfortunately.

Thanks for the reaction!

So unfortunatly we are still stuck

[MatthiasDh]

bump

[chhornponleu]

@MAKARD @MatthiasDh I remember that WebView without onContentProcessDidTerminate made app crash on iOS when it stay in background for a while and return back but i didn't noticed the error log at that time. I've just found out that the screen that reported the crash also has multiple WebView without the prop.

I'm preparing the next app release with the prop soon. It's just what I guess. Will report back the result!

Sample

<Webview
  ....
  onContentProcessDidTerminate={() => {
     // screen will be white blank, so try to reload webview or ...
  }}
/>

Quick update... After adding the prop, no such crash reported yet.

[LukasBombach]

To me, that seems like you're just overriding the error handler, so your WebView might still just crash, but instead of reporting, it will execute the onContentProcessDidTerminate handler without reporting the crash

[MatthiasDh]

We have onContentProcessDidTerminate implemented to reload the webview, however we still see this issue happening.

This method doesn't get called when our webviews turn white and inresponsive.