Bug 187843 – -[WKContentView(WKInteraction) _restoreFocusWithToken:] crashed

• Component: WebKit2
• Status: RESOLVED INVALID

we found a crash on wkwebview above iOS11.3. It maybe happened when the UIViewController is animating. Hope fix it or get a workaround.

Created attachment 345420 [details]
Call stacks when crash happened.

[Alexey Proskuryakov]

*** Bug 187842 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

This is unlikely to be actionable without more information. Please provide steps to reproduce, or at least attach a complete crash log.

What application is affected, and how frequently does this happen?

[Radar WebKit Bug Importer]

<rdar://problem/42454640>

Thank you for your attention.we did not reproduce it offline, but a fews happened online. so there is no complete crash log which can be exported from iOS device locally. I will attach a log from our reporter. The application affected is JDApp from JD.com, the proportion is about 5% in total crashes.

(In reply to Alexey Proskuryakov from comment #3)
> This is unlikely to be actionable without more information. Please provide
> steps to reproduce, or at least attach a complete crash log.
> 
> What application is affected, and how frequently does this happen?

Created attachment 345554 [details]
crash log including all threads

[Wenson Hsieh]

Thanks for the information! From a quick glance, what could be happening is that we're getting an extra call to -_restoreFocusWithToken: when we don't expect to. The API (SPI?) contract for focus restoration is that each call to -_preserveFocusWithToken: should be bookended with exactly one call to -_restoreFocusWithToken:, so any mismatch here would cause us to crash in the UI process when we try and remove from _focusStateStack in this if statement:

    if (_focusStateStack.takeLast())

It probably makes sense to fail gracefully by bailing early if the focus state stack is empty here instead of merely debug asserting like we do now. That being said, the root cause is most likely beneath WebKit, in logic that's responsible for telling us to preserve or restore focus.

Regarding your comment in the other bug (181510):

> if we remove a webview when it is not on the top of navigationcontroller's viewcontrollers. when back to the 'webviewpage(had removed)', a crash will happen low frequently

Do you happen to have a test app that exercises this scenario? That would be very helpful in confirming a fix!

[Hank]

The RootViewController (push)-> a webviewController(present)->The A (a native viewcontroller)(push)-> a webviewcontroller(push)->a native viewcontroller(push)->a webviewcontroller,then the A dismiss,at the time,the app crash

Thanks a lot.

Unfortunately! It is our Official app instead of test app! we found two scenes the problem occurs. The first one is when UINaivgationController pop to the webviewController which had been removed as mentioned above (we do not remove the webviewController in our newer app, and the crash rate Significantly reduced).The other is when a presented ViewController who had push some webviewcontrollers is dismissing,then app crashed, the detail navigation stack just as Hank said.

It should be noted that all conclusion is summarized from our monitor. not reproducing the problem.

(In reply to Wenson Hsieh from comment #7)
> Thanks for the information! From a quick glance, what could be happening is
> that we're getting an extra call to -_restoreFocusWithToken: when we don't
> expect to. The API (SPI?) contract for focus restoration is that each call
> to -_preserveFocusWithToken: should be bookended with exactly one call to
> -_restoreFocusWithToken:, so any mismatch here would cause us to crash in
> the UI process when we try and remove from _focusStateStack in this if
> statement:
> 
>     if (_focusStateStack.takeLast())
> 
> It probably makes sense to fail gracefully by bailing early if the focus
> state stack is empty here instead of merely debug asserting like we do now.
> That being said, the root cause is most likely beneath WebKit, in logic
> that's responsible for telling us to preserve or restore focus.
> 
> Regarding your comment in the other bug (181510):
> 
> > if we remove a webview when it is not on the top of navigationcontroller's viewcontrollers. when back to the 'webviewpage(had removed)', a crash will happen low frequently
> 
> Do you happen to have a test app that exercises this scenario? That would be
> very helpful in confirming a fix!

Dear Wenson Hsieh:

We are sorry about that this is not a problem about webkit, we found a memory leak which is used to mananger navigationBar to webview controller. The problem was fixed after the memory leak was resolved. Thank you very much.  

(In reply to Wenson Hsieh from comment #7)
> Thanks for the information! From a quick glance, what could be happening is
> that we're getting an extra call to -_restoreFocusWithToken: when we don't
> expect to. The API (SPI?) contract for focus restoration is that each call
> to -_preserveFocusWithToken: should be bookended with exactly one call to
> -_restoreFocusWithToken:, so any mismatch here would cause us to crash in
> the UI process when we try and remove from _focusStateStack in this if
> statement:
> 
>     if (_focusStateStack.takeLast())
> 
> It probably makes sense to fail gracefully by bailing early if the focus
> state stack is empty here instead of merely debug asserting like we do now.
> That being said, the root cause is most likely beneath WebKit, in logic
> that's responsible for telling us to preserve or restore focus.
> 
> Regarding your comment in the other bug (181510):
> 
> > if we remove a webview when it is not on the top of navigationcontroller's viewcontrollers. when back to the 'webviewpage(had removed)', a crash will happen low frequently
> 
> Do you happen to have a test app that exercises this scenario? That would be
> very helpful in confirming a fix!