Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 20790ef5e0288815eef06cd31fb0ade3c0ef8982
https://github.com/WebKit/WebKit/commit/20790ef5e0288815eef06cd31fb0ade3c0ef8982
Author: Chris Dumez <[email protected]>
Date: 2026-06-17 (Wed, 17 Jun 2026)
Changed paths:
M Source/WebCore/page/SecurityOrigin.h
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
Log Message:
-----------
Clear-Site-Data: "cache" does not evict BFCache or MemoryCache entries due to
SecurityOriginHash visibility
https://bugs.webkit.org/show_bug.cgi?id=317269
rdar://179387089
Reviewed by Darin Adler and Basuke Suzuki.
BackForwardCache::clearEntriesForOrigins and
MemoryCache::removeResourcesWithOrigins
silently failed to evict matching entries after an HTTP Clear-Site-Data: "cache"
response. The HashSet<Ref<SecurityOrigin>> built in WebProcess.cpp used the
pointer-based PtrHash, while WebCore queried it using the content-based
SecurityOriginHash, so contains(SecurityOrigin::create(...)) never matched a
freshly-created origin and neither the back/forward cache nor the memory cache
was cleared for the calling site.
The root cause was that the content-based DefaultHash<Ref<SecurityOrigin>>
specialization lived in SecurityOriginHash.h, so the meaning of
HashSet<Ref<SecurityOrigin>> depended on whether that header happened to be
included at the point of instantiation. Where it was not visible,
DefaultHash<Ref<SecurityOrigin>> fell back to the pointer-based PtrHash primary
template in HashFunctions.h. Because both spellings resolve to the identically
named HashSet<Ref<SecurityOrigin>, DefaultHash<Ref<SecurityOrigin>>> but with
two
different definitions of DefaultHash, this is an ODR violation: the linker keeps
one definition of the inline add()/contains() arbitrarily. The mismatch became
active in 307882@main, which converted these containers from
RefPtr<SecurityOrigin> to Ref<SecurityOrigin> and thereby changed which
definition won the merge.
Forward-declare the explicit DefaultHash<Ref<SecurityOrigin>> specialization in
SecurityOrigin.h (the type's own header), leaving the definition in
SecurityOriginHash.h. The full specialization out-ranks the generic PtrHash
partial, so Ref<SecurityOrigin> can no longer silently resolve to pointer
hashing; and because the declared-but-undefined specialization is an incomplete
type, using Ref<SecurityOrigin> as a hash-table key without including
SecurityOriginHash.h is now a hard compile error rather than a silent
miscompile. This mirrors the existing DefaultHash<RefPtr<StringImpl>> idiom
(declared in StringImpl.h, defined in StringHash.h).
MediaPlayerPrivateWebM.mm is updated to include SecurityOriginHash.h, which the
new guard now requires at the point it uses a HashSet<Ref<SecurityOrigin>>.
Covered by existing test http/tests/clear-site-data/bfcache.html.
* Source/WebCore/page/SecurityOrigin.h: Forward-declare the
WTF::DefaultHash<Ref<SecurityOrigin>> specialization (defined in
SecurityOriginHash.h) so that using Ref<SecurityOrigin> as a hash key without
that header is a compile error instead of a silent fall back to PtrHash. Include
<wtf/Ref.h>.
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm: Include
SecurityOriginHash.h, now required by the guard for the m_origins member.
Canonical link: https://commits.webkit.org/315432@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
