Bug 184144 – Reproducible, recurring crash when the completion handler passed to -[runJavaScriptAlertPanelWithMessage:initiatedByFrame: completionHandler:] is deallocated without being called once

• Component: WebKit2
• Status: RESOLVED INVALID

[AV]

1. Open a page that shows a Javascript alert/confirm/text-input prompt.
2. Destroy the WKWebView Object when the alert/prompt is active.
3. App crashes with any of the following errors depending on the type of prompt:

- Uncaught exception: Completion handler passed to -[WebViewController webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:completionHandler:] was not called
- Uncaught exception: Completion handler passed to -[WebViewController webView:runJavaScriptConfirmPanelWithMessage:initiatedByFrame:completionHandler:] was not called
- Uncaught exception: Completion handler passed to -[WebViewController webView:runJavaScriptTextInputPanelWithPrompt: defaultText:initiatedByFrame:completionHandler:] was not called

[AV]

I use this link to simulate an alert:

https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_alert

[Alexey Proskuryakov]

Could you please attach a crash log, and a test project that reproduces this problem?

[AV]

Created attachment 336981 [details]
xCode Project

[AV]

I have attached a test project to reproduce this. Below is the crash logs. The scenario is, we delete a view controller when the app enters background and dismiss all active modals.

This crash happens when the alert view gets dismissed as part of clearing all active modals from the view before entering into the background state.

Is there a way to handle this other than manually keeping track of all active WebKit JS Modals and calling all their corresponding completion-handlers, as this seems to be a complex workaround?


------------------------------------------------------------------------------------

2018-04-02 19:06:36.665964+0530 webKitCompText[1175:13720] [MC] Reading from private effective user settings.
2018-04-02 19:06:38.173182+0530 webKitCompText[1175:13720] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Completion handler passed to -[ViewController webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:completionHandler:] was not called'
*** First throw call stack:
(
	0   CoreFoundation                      0x0000000109c4112b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00000001092d5f41 objc_exception_throw + 48
	2   CoreFoundation                      0x0000000109cb6245 +[NSException raise:format:] + 197
	3   WebKit                              0x0000000108529365 _ZN6WebKit28CompletionHandlerCallCheckerD2Ev + 129
	4   WebKit                              0x000000010856bfc4 _ZNK3WTF20ThreadSafeRefCountedIN6WebKit28CompletionHandlerCallCheckerEE5derefEv + 36
	5   WebKit                              0x0000000108605889 _ZZN3WTF8BlockPtrIFvvEE12fromCallableIZN6WebKit10UIDelegate8UIClient18runJavaScriptAlertEPNS4_12WebPageProxyERKNS_6StringEPNS4_13WebFrameProxyERKN7WebCore18SecurityOriginDataEONS_8FunctionIS1_EEE3$_1EES2_T_ENUlPKvE_8__invokeESO_ + 29
	6   libsystem_blocks.dylib              0x000000011205d99d _Block_release + 111
	7   webKitCompText                      0x000000010821796d __destroy_helper_block_ + 29
	8   libsystem_blocks.dylib              0x000000011205d99d _Block_release + 111
	9   UIKit                               0x000000010aba2e9a -[UIAlertController _clearActionHandlers] + 246
	10  UIKit                               0x000000010aba1282 -[UIAlertController dealloc] + 420
	11  libobjc.A.dylib                     0x00000001092eb178 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 860
	12  FrontBoardServices                  0x0000000115f074a0 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 32
	13  FrontBoardServices                  0x0000000115f0714e -[FBSSerialQueue _performNext] + 464
	14  FrontBoardServices                  0x0000000115f076bd -[FBSSerialQueue _performNextFromRunLoopSource] + 45
	15  CoreFoundation                      0x0000000109be4101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	16  CoreFoundation                      0x0000000109c83f71 __CFRunLoopDoSource0 + 81
	17  CoreFoundation                      0x0000000109bc8a19 __CFRunLoopDoSources0 + 185
	18  CoreFoundation                      0x0000000109bc7fff __CFRunLoopRun + 1279
	19  CoreFoundation                      0x0000000109bc7889 CFRunLoopRunSpecific + 409
	20  GraphicsServices                    0x000000010d7a09c6 GSEventRunModal + 62
	21  UIKit                               0x000000010a7d25d6 UIApplicationMain + 159
	22  webKitCompText                      0x0000000108217adf main + 111
	23  libdyld.dylib                       0x0000000111fecd81 start + 1
	24  ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

[Radar WebKit Bug Importer]

<rdar://problem/39106756>

[Andy Estes]

The title claims this happens "when the WKWebView is destroyed."

But it doesn't look like the web view is being destroyed on backgrounding, just the UIAlert. Is that right?

[Aravind V]

Yes, if happens when the alert is destroyed.




(In reply to Andy Estes from comment #6)
> The title claims this happens "when the WKWebView is destroyed."
> 
> But it doesn't look like the web view is being destroyed on backgrounding,
> just the UIAlert. Is that right?

[Andy Estes]

JavaScript alerts run synchronously from the perspective of web content, so the web process hangs waiting for you to call the alert completion handler. If you allow the completion handler to be deallocated without calling it once, your WKWebView would become unresponsive.

That's why we throw this exception. You really need to call the completion handler whenever you dismiss the alert, whether its dismissed programmatically or by the user.

[AV]

Thank you so much, Andy.

I get the solution. I know there is a way to handle this as I mentioned in my 2nd comment, by manually keeping track of the instances of all alerts and their respective completion handlers and call each of these completion handlers one by one when the app needs to be de-allocated for a valid reason.

Let's assume the following scenario:

1) I have an application that has an in-built secure browser built on top of WebKit, which gets locked when the app enters into the background. When locking, if the webkit instance is maintained and the alerts aren't dismissed, the alerts will show-up on top of the app's lock screen(or on top of whichever view is currently being rendered), which is not a good user experience.

2) In the last few versions of iOS, UIAlertView is deprecated and Apple suggests developers to use UIAlertController. UIAlertController doesn't have a method similar to UIAlertView's "dismissWithClickedButtonIndex: animated:(BOOL)animated". Hence, the best way to work-around on this is to use UIAlertView and dismiss alerts whenever necessary by calling "dismissWithClickedButtonIndex: animated:(BOOL)animated", but this is ruled-out as UIAlertView is deprecated.

3) The only other possible way, as I've mentioned in my previous comments, is to maintain a list of all active Alerts by adding each alert instance and it's respective completion-handlers as and when the JS Alert delegate methods get called, and traversing through the list maintained and calling all active alerts' completion-handlers manually. This works, but seems to be a complex workaround.


Can you please advice as to whether the work-around mentioned in "3)" is the only way to deal with this? If so, it piles-up the code for just dismissing the active alerts by maintaining the state of each active alert. Though UIAlertView's "dismissWithClickedButtonIndex: animated:(BOOL)animated" would work well, it may not be advisable as Apple has already deprecated and may soon remove UIAlertView from it's SDK soon in the future.

Please if there is a possible fix or a better work-around for this, or if WebKit already has methods exposed to clear pending completion handlers before dismissing the alerts using "dismissViewController".


Thank you you much for your support.

[Andy Estes]

I can't give you advice for how to manage the UIAlerts in your application. That's outside the scope of WebKit; we've delegated how to display the alert UI to you.

There can only be one active alert per WKWebView, though, so it doesn't seem overly complex to keep track of up to one completion handler per view. I can't really speak to your application, though.