requestDocumentEditingContext() performs a layout, which can do anything, including document destruction. Ensure that the focused frame has a view before computing the editing context.
<rdar://problem/60843660>
Created attachment 394419 [details] Patch
Comment on attachment 394419 [details] Patch Why no test case?
(In reply to Darin Adler from comment #3) > Comment on attachment 394419 [details] > Patch > > Why no test case? It is hard to write one. I don't even know how to write such a test. I mean, here's what I need to do: 1. Write a test that will run JavaScript on layout (so, probably need a resize observer) that performs a synchronous navigation. 2. Write an API test that loads that page, get the page into a state where layout is needed, but **not** performed, then call -requestDocumentContext: (again, hoping that layout timer has not run before message gets to web process; otherwise, need to disable that). Then -requestDocumentContext will message to requestDocumentEditingContext(), which will update layout => triggers navigation => view destroyed and the test will crash without the patch and not crash with it.
If there is an easier way to write a test I am all ears
That sounds like the right way to write the test. We should really write it. Otherwise we are just making code changes and crossing our fingers.
This patch was modifying: https://searchfox.org/wubkat/rev/711120e7edec012527620d07bf63d85713a180fd/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm#4935 Which is: RefPtr frame = m_page->checkedFocusController()->focusedOrMainFrame(); if (!frame) return completionHandler({ }); __ So I think 275171@main addressed this in bug 269761 and rdar://116201648. @Alex - above commit was from your side, do you think we need to do anything more here or we can tag this as 'Duplicate' to above bug?