Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 13e383f65077cfd61c0763208830dd2a12a2ae67
https://github.com/WebKit/WebKit/commit/13e383f65077cfd61c0763208830dd2a12a2ae67
Author: Tyler Wilcock <[email protected]>
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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
