Bug 187843 - -[WKContentView(WKInteraction) _restoreFocusWithToken:] crashed
Summary: -[WKContentView(WKInteraction) _restoreFocusWithToken:] crashed
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: Other
Hardware: iPhone / iPad iOS 11
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 187842 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-07-19 19:29 PDT by 894110476
Modified: 2018-08-26 20:33 PDT (History)
7 users (show)

See Also:


Attachments
Call stacks when crash happened. (1.77 KB, text/plain)
2018-07-19 19:33 PDT, 894110476
no flags Details
crash log including all threads (11.60 KB, text/plain)
2018-07-22 19:23 PDT, 894110476
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description 894110476 2018-07-19 19:29:14 PDT
we found a crash on wkwebview above iOS11.3. It maybe happened when the UIViewController is animating. Hope fix it or get a workaround.
Comment 1 894110476 2018-07-19 19:33:33 PDT
Created attachment 345420 [details]
Call stacks when crash happened.
Comment 2 Alexey Proskuryakov 2018-07-20 19:24:02 PDT
*** Bug 187842 has been marked as a duplicate of this bug. ***
Comment 3 Alexey Proskuryakov 2018-07-20 19:26:30 PDT
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?
Comment 4 Radar WebKit Bug Importer 2018-07-20 19:29:19 PDT
<rdar://problem/42454640>
Comment 5 894110476 2018-07-22 19:19:20 PDT
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?
Comment 6 894110476 2018-07-22 19:23:00 PDT
Created attachment 345554 [details]
crash log including all threads
Comment 7 Wenson Hsieh 2018-07-26 21:00:11 PDT
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!
Comment 8 Hank 2018-08-02 19:37:26 PDT
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
Comment 9 894110476 2018-08-03 06:26:54 PDT
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!
Comment 10 894110476 2018-08-26 20:33:12 PDT
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!