Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: af08d1599d8b7003dc8328873ecf2b992693813d
https://github.com/WebKit/WebKit/commit/af08d1599d8b7003dc8328873ecf2b992693813d
Author: Chris Dumez <[email protected]>
Date: 2026-05-12 (Tue, 12 May 2026)
Changed paths:
M Source/WebKit/Platform/cocoa/WebPrivacyHelpers.h
M Source/WebKit/UIProcess/API/APIContentRuleListStore.cpp
M Source/WebKit/UIProcess/API/APIContentRuleListStore.h
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
Log Message:
-----------
Cherry-pick 312745@main (af0162d45a8f).
https://bugs.webkit.org/show_bug.cgi?id=307300
REGRESSION (297757@main): [ Tahoe wk2 debug arm64 ] Multiple
http/tests/iframe-monitor tests are consistent timeouts
https://bugs.webkit.org/show_bug.cgi?id=307300
rdar://169934202
Reviewed by Basuke Suzuki.
297757@main fixed parallel compilations for the same identifier racing on
the same
file by replacing per-instance work queues with a single static serial
WorkQueue
shared across all ContentRuleListStore instances. This was too aggressive:
it
serializes all operations (compiles, reads, removes) across all stores
globally,
even when they operate on different directories and cannot conflict.
On Tahoe bots running multiple WebKitTestRunner instances, this causes two
problems:
1. Cross-process filesystem contention:
platformCompileResourceMonitorRuleList()
was using [WKContentRuleListStore defaultStore] whose directory is
shared across
all WKTR instances. Multiple processes writing the same file
concurrently makes
compilation extremely slow.
2. Within-process queue starvation: the built-in resource monitor rule list
compilation (triggered by page navigation via
ResourceMonitorURLsController::prepare())
and the test's rule list compilation both serialize on the same global
queue.
If the built-in list is large, it blocks the test's compilation past the
timeout.
Fix both issues:
- Replace the global static serial queue with a per-directory serial
WorkQueue,
keyed by store path. Stores sharing the same directory serialize on the
same
queue (preventing the race that 297757@main fixed), while stores with
different
directories operate in parallel. The queue map is reference-counted so
entries
are cleaned up when the last store for a given path is destroyed.
- Have platformCompileResourceMonitorRuleList() use the per-pid store
configured
by WKTR (via ResourceMonitorURLsController) instead of the shared default
store,
eliminating cross-process filesystem contention.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebKit/Platform/cocoa/WebPrivacyHelpers.h:
(WebKit::ResourceMonitorURLsController::contentRuleListStore const):
* Source/WebKit/UIProcess/API/APIContentRuleListStore.cpp:
(API::workQueueMap):
(API::retainWorkQueueForPath):
(API::releaseWorkQueueForPath):
(API::ContentRuleListStore::ContentRuleListStore):
(API::ContentRuleListStore::~ContentRuleListStore):
(API::ContentRuleListStore::lookupContentRuleListFile):
(API::ContentRuleListStore::getAvailableContentRuleListIdentifiers):
(API::ContentRuleListStore::compileContentRuleListFile):
(API::ContentRuleListStore::removeContentRuleListFile):
(API::ContentRuleListStore::getContentRuleListSource):
* Source/WebKit/UIProcess/API/APIContentRuleListStore.h:
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformCompileResourceMonitorRuleList):
Canonical link: https://commits.webkit.org/312745@main
Canonical link: https://commits.webkit.org/305877.487@webkitglib/2.52
Commit: 822a38e50852b4412cc9cb83bdc7a1f42df7b686
https://github.com/WebKit/WebKit/commit/822a38e50852b4412cc9cb83bdc7a1f42df7b686
Author: Eric Carlson <[email protected]>
Date: 2026-05-12 (Tue, 12 May 2026)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
Log Message:
-----------
Cherry-pick 312598@main (640e6ff568d1).
https://bugs.webkit.org/show_bug.cgi?id=314034
ASSERT under HTMLMediaElement::virtualHasPendingActivity
https://bugs.webkit.org/show_bug.cgi?id=314034
rdar://176143872
Reviewed by Jean-Yves Avenard and Ryosuke Niwa.
Many MediaPlayerPrivateMediaSourceAVFObjC member variables are a
main-thread-only but
it can be access from the worker thread by the MediaSource/Private, so its
destructor
should always run on the main thread.
While investigation this it was observed that
HTMLMediaElement::virtualHasPendingActivity
may be called from the GC thread but it calls
HTMLMediaElement::canProduceAudio() which
calls MediaPlayer::hasAudio() and creates a temporary RefPtr to the
MediaPlayerPrivate.
This is unnecessary as every MediaPlayer notifies HTMLMediaElement when its
ability to
produce audio changes, so fix this by caching `canProduceAudio` in a
std::atomic which is
updated only on the main thread whenever relevant state changes.
canProduceAudio()
now just returns the cached value and is safe to call from any thread.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::canProduceAudio const):
(WebCore::HTMLMediaElement::computeCanProduceAudio const):
(WebCore::HTMLMediaElement::canProduceAudioChanged):
* Source/WebCore/html/HTMLMediaElement.h:
*
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
Canonical link: https://commits.webkit.org/312598@main
Canonical link: https://commits.webkit.org/305877.488@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/024db5335281...822a38e50852
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
