[webkit-changes] [WebKit/WebKit] 13e383: AX: Ensure Nodes are cleaned up from AXObjectCache...
Tyler Wilcock
noreply at github.com
Fri Jan 17 08:50:54 PST 2025
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 13e383f65077cfd61c0763208830dd2a12a2ae67
https://github.com/WebKit/WebKit/commit/13e383f65077cfd61c0763208830dd2a12a2ae67
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M Source/WebCore/dom/Node.cpp
Log Message:
-----------
AX: Ensure Nodes are cleaned up from AXObjectCache::m_nodeObjectMapping when they are destroyed
https://bugs.webkit.org/show_bug.cgi?id=285962
rdar://142764858
Reviewed by Chris Fleizach.
With this commit, we add a call to AXObjectCache::remove(Node&) as a speculative fix for a crash. This crash happens
because AXObjectCache::m_nodeObjectMapping is an UncheckedKeyHashMap<WeakRef<Node, WeakPtrImplWithEventTargetData>, AXID>,
and in seemingly rare edgecases, we fail to remove `Node`s from this map before they are destroyed, causing the WeakRef
to become null, in turn causing a crash next time any operation (e.g. a lookup) compares with this nullified WeakRef.
Prior to this commit, we relied on Node::willBeDeletedFrom(Document&) to perform AXObjectCache::remove(Node&). And the
vast majority of the time, this works perfectly. Some theories I considered and ruled out:
- Every Node subclass ends up calling into willBeDeletedFrom, except for DocumentType. But we never create an accessibility
object for this type of Node, so it could not get into m_nodeObjectMapping in the first place.
- ~ContainerNode only conditionally calls willBeDeletedFrom, specifically only when !isDocumentNode(). But again, we
will not create an accessibility object for a Document Node, so it could not ever enter the map.
* Source/WebCore/dom/Node.cpp:
(WebCore::Node::~Node):
Canonical link: https://commits.webkit.org/289060@main
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list