Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 41b65165bb54ce1b1165ceb25bb856a6504ec809
https://github.com/WebKit/WebKit/commit/41b65165bb54ce1b1165ceb25bb856a6504ec809
Author: Wenson Hsieh <[email protected]>
Date: 2025-12-11 (Thu, 11 Dec 2025)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/forms/WKFormSelectPicker.mm
Log Message:
-----------
REGRESSION (iOS 26.1): Frequent UI process crashes in
WebCore::ElementContext::isSameElement under WKSelectPicker
https://bugs.webkit.org/show_bug.cgi?id=303917
rdar://163148093
Reviewed by Tim Horton.
When dismissing a select menu after the changes in 300720@main, it's possible
that we now crash in
the case where `WKSelectPicker` outlives the underlying web view. This is
because `view` is `nil`
here:
```
[animator addCompletion:[weakSelf = WeakObjCPtr<WKSelectPicker>(self),
elementContext = _view.focusedElementInformation.elementContext] {
auto strongSelf = weakSelf.get();
if (strongSelf) {
RetainPtr view = strongSelf->_view; // <------
if (elementContext.isSameElement([view
focusedElementInformation].elementContext))
```
...which causes the `ElementContext` passed into `isSameElement` to be a
**zero-initialized** C++
struct. Notably, this does not call the default constructor for the underlying
`Markable`s
representing each of the element/document/page IDs, which initializes the
underlying value to the
empty value (not the same as the zero-initialized value). Comparing against
this zero-initialized
`Markable` subsequently crashes, since `Traits::isEmptyValue` returns `false`
and we then try to
dereference the underlying value.
To fix this, we ensure that `WKSelectPicker` handles the above case gracefully
by checking
`-_hasFocusedElement` (which is consistent with the other call sites in
`WKContentViewInteraction`
that try to check against the focused element context). We add a new helper
method that encapsulates
this logic, and deploy that in the various places where we need to check the
combination of:
- Content view has a focused element.
- The focused element context is the same element as a given element context's
element.
Writing a test for this is tricky without swizzling WebKit internal code, since
layout tests don't
support destroying the containing web view until the test is complete, and the
iOS API test harness
doesn't support showing UIKit context menus in any sensible way.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _keyboardDismissalGestureRecognized:]):
(-[WKContentView _isSameAsFocusedElement:]):
Add a helper method on the content view that returns whether or not the given
element context
represents the same underlying DOM element as the currently focused element;
returns NO in the case
where there is no currently focused element.
(-[WKContentView _isTextInputContextFocused:]):
(-[WKContentView
_elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
(-[WKContentView _didProgrammaticallyClearFocusedElement:]):
(-[WKContentView _updateFocusedElementInformation:]):
(-[WKContentView _elementForTextInputContextIsFocused:]):
Consolidate all of these `-_hasFocusedElement` checks into the new
`-_isSameAsFocusedElement:`
helper method above.
* Source/WebKit/UIProcess/ios/forms/WKFormSelectPicker.mm:
(-[WKSelectPicker contextMenuInteraction:willEndForConfiguration:animator:]):
Fix the bug by adopting `-_isSameAsFocusedElement:` above.
Canonical link: https://commits.webkit.org/304320@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
