Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: a025d4972620201ee8954eae0da50a62427ada9e
https://github.com/WebKit/WebKit/commit/a025d4972620201ee8954eae0da50a62427ada9e
Author: Chris Dumez <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/page/Page.cpp
Log Message:
-----------
Cherry-pick 309170@main (a6e683bb5a79).
https://bugs.webkit.org/show_bug.cgi?id=300137
REGRESSION(300617@main): [macOS iOS]
imported/w3c/web-platform-tests/html/semantics/scripting-1/the-script-element/json-module/repeated-imports.any.sharedworker.html
is flaky failure
https://bugs.webkit.org/show_bug.cgi?id=300137
rdar://161922656
Reviewed by Basuke Suzuki.
The test repeated-imports.any.sharedworker.html was flaky because the
second import() call to the same URL (but without { type: "json" }) was
sometimes served a cached text/json response from the first import
instead of making a fresh network request to get the application/javascript
response.
It could happen because:
Worker module imports go through WorkerScriptLoader → ThreadableLoader →
DocumentThreadableLoader → CachedResourceLoader::requestRawResource().
Both the JSON and JavaScript imports create CachedRawResource objects
with the same resource type, so WebKit's MemoryCache type-mismatch check
(which protects the Document/Window path, where CachedScript::JSON vs
CachedScript::Script are differentiated) does not apply.
SharedWorkers proxy their network requests through a synthetic Document
created in Page::setupForRemoteWorker(). This synthetic page never
dispatches its window load event, so document->loadEventFinished() is
permanently false.
In CachedResourceLoader::determineRevalidationPolicy(), there is an
optimization at line 1545:
```
if (document() && !document()->loadEventFinished() &&
m_validatedURLs.contains(existingResource->url()))
return Use;
```
This is designed to avoid redundantly re-fetching the same resource
during initial page load. But for the SharedWorker's synthetic page,
loadEventFinished() is always false and m_validatedURLs is never
cleared, so this optimization applies permanently. After the first
import caches the URL, the second import hits this check and returns
Use, bypassing all freshness and revalidation checks. The stale
text/json response is served for what should be a JavaScript import.
The flakiness (rather than consistent failure) is because
MemoryCache::pruneSoon() is scheduled after the first import's client is
removed. If the prune timer fires and evicts the resource before the
second import arrives, the cache misses and a fresh request succeeds. If
not, the cached response is reused and the test fails.
DedicatedWorker is unaffected because it proxies through the parent
page's Document, whose load event fires normally, so the m_validatedURLs
check is bypassed.
The Window path is unaffected because it uses CachedScript with distinct
JSON/Script types that trigger a type-mismatch reload.
To address the problem:
Call document->dispatchWindowLoadEvent() on the synthetic page in
Page::setupForRemoteWorker() before attaching it to the frame. This sets
m_loadEventFinished = true and calls documentDidFinishLoadEvent() (which
clears m_validatedURLs), preventing the optimization from
inappropriately applying to worker resource loads. The event dispatch
itself is a no-op since the synthetic page has no listeners.
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/platform/mac/TestExpectations:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::setupForRemoteWorker):
Canonical link: https://commits.webkit.org/309170@main
Canonical link: https://commits.webkit.org/305877.193@webkitglib/2.52
Commit: 28f93c8b331db565c736042c324e6362bcf6dd75
https://github.com/WebKit/WebKit/commit/28f93c8b331db565c736042c324e6362bcf6dd75
Author: Fujii Hironori <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/crashtests/div-in-hidden.html
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Cherry-pick 308897@main (ca3b56d49b32).
https://bugs.webkit.org/show_bug.cgi?id=307963
ASSERTION FAILED: !isSkippedContentRoot(*this) in
WebCore::RenderBox::foregroundIsKnownToBeOpaqueInRect
https://bugs.webkit.org/show_bug.cgi?id=307963
Reviewed by Alan Baradlay.
An assertion failed in RenderBox::foregroundIsKnownToBeOpaqueInRect(). It
asserts `this` is not a skipped content root because a skipped content root
paints no foregrounds and never obscure the background.
In foregroundIsKnownToBeOpaqueInRect(), if isSkippedContentRoot(childBox),
we
shound't recursively call childBox.foregroundIsKnownToBeOpaqueInRect().
RenderBox::computeBackgroundIsKnownToBeObscured also calls
foregroundIsKnownToBeOpaqueInRect(). However, in this functions, `this` is
not
a skipped content root. Added an assertion to ensure that.
Test:
imported/w3c/web-platform-tests/css/css-contain/content-visibility/crashtests/div-in-hidden.html
*
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/crashtests/div-in-hidden.html:
Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::foregroundIsKnownToBeOpaqueInRect const):
(WebCore::RenderBox::computeBackgroundIsKnownToBeObscured):
Canonical link: https://commits.webkit.org/308897@main
Canonical link: https://commits.webkit.org/305877.194@webkitglib/2.52
Commit: 619df758c4c6aaaece242517d15ac7ccb8df9d92
https://github.com/WebKit/WebKit/commit/619df758c4c6aaaece242517d15ac7ccb8df9d92
Author: Fujii Hironori <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
A
LayoutTests/compositing/scrolling/async-overflow-scrolling/sticky-in-scrollable-crash-expected.txt
A
LayoutTests/compositing/scrolling/async-overflow-scrolling/sticky-in-scrollable-crash.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 308838@main (53d54af388d6).
https://bugs.webkit.org/show_bug.cgi?id=309156
SHOULD NEVER BE REACHED in ScrollingStateNode::insertChild()
https://bugs.webkit.org/show_bug.cgi?id=309156
Reviewed by Simon Fraser.
An assertion failed in ScrollingStateNode::insertChild() because the
argument
`index` exceeded the child count.
RenderLayerCompositor::updateScrollCoordinationForLayer should reset
childTreeState.nextChildIndex if it sets a new parent.
Unskipped compositing/scrolling/async-overflow-scrolling test directory for
glib port as well as Mac and iOS ports do.
Test:
compositing/scrolling/async-overflow-scrolling/sticky-in-scrollable-crash.html
*
LayoutTests/compositing/scrolling/async-overflow-scrolling/sticky-in-scrollable-crash-expected.txt:
Added.
*
LayoutTests/compositing/scrolling/async-overflow-scrolling/sticky-in-scrollable-crash.html:
Added.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateScrollCoordinationForLayer):
Canonical link: https://commits.webkit.org/308838@main
Canonical link: https://commits.webkit.org/305877.195@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/d665e8f7577f...619df758c4c6
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
