Branch: refs/heads/webkitglib/2.44
Home: https://github.com/WebKit/WebKit
Commit: e93bb5b3910212e7e93c6ea1a74d48ac5bc1fb31
https://github.com/WebKit/WebKit/commit/e93bb5b3910212e7e93c6ea1a74d48ac5bc1fb31
Author: Georges Basile Stavracas Neto <feane...@igalia.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitGtk/TestInspectorServer.cpp
M Tools/TestWebKitAPI/Tests/WebKitGtk/TestWebViewEditor.cpp
Log Message:
-----------
Cherry-pick 279185@main (aa28356f83b8).
https://bugs.webkit.org/show_bug.cgi?id=274578
[GTK] Build failures in TestWebKitAPI for WebKitGTK
https://bugs.webkit.org/show_bug.cgi?id=274578
Unreviewed build fix.
Add explicit return types to the lambdas, which makes Clang happy
enough to finish the build.
* Tools/TestWebKitAPI/Tests/WebKitGtk/TestInspectorServer.cpp:
* Tools/TestWebKitAPI/Tests/WebKitGtk/TestWebViewEditor.cpp:
Canonical link: https://commits.webkit.org/279185@main
Canonical link: https://commits.webkit.org/274313.266@webkitglib/2.44
Commit: 40ddaf4044d23d8a708ffb11a5d5049e0fb94022
https://github.com/WebKit/WebKit/commit/40ddaf4044d23d8a708ffb11a5d5049e0fb94022
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/JavaScriptCore/runtime/CustomGetterSetter.h
Log Message:
-----------
Cherry-pick 272448.523@safari-7618-branch (66d8614c41ca).
https://bugs.webkit.org/show_bug.cgi?id=268897
[JSC] Harden CustomGetterSetter by adding MethodTable overrides that always
crash
https://bugs.webkit.org/show_bug.cgi?id=268897
<rdar://122171568>
Reviewed by Mark Lam.
Just like GetterSetter, CustomGetterSetter is never purposely exposed to
userland code.
However, to make exploitation of accidentally exposed CustomGetterSetter
objects difficult, this
patch implements MethodTable overrides that abort the program when reached,
similar to GetterSetter.
* Source/JavaScriptCore/runtime/CustomGetterSetter.h:
(JSC::CustomGetterSetter::getOwnPropertySlot):
(JSC::CustomGetterSetter::put):
(JSC::CustomGetterSetter::putByIndex):
(JSC::CustomGetterSetter::setPrototype):
(JSC::CustomGetterSetter::defineOwnProperty):
(JSC::CustomGetterSetter::deleteProperty):
Canonical link: https://commits.webkit.org/272448.523@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.267@webkitglib/2.44
Commit: 5e5cde0c683fd8e3c901b633d446cc432ecc63f3
https://github.com/WebKit/WebKit/commit/5e5cde0c683fd8e3c901b633d446cc432ecc63f3
Author: Said Abou-Hallawa <s...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M LayoutTests/css3/filters/filter-visited-links-expected.html
M LayoutTests/css3/filters/filter-visited-links.html
M Source/WebCore/rendering/InlineBoxPainter.cpp
Log Message:
-----------
Cherry-pick 272448.560@safari-7618-branch (36df2fc04fb9).
https://bugs.webkit.org/show_bug.cgi?id=262337
Prevent SVG filters from leaking the background of visited hyperlinks
https://bugs.webkit.org/show_bug.cgi?id=262337
rdar://116206368
Reviewed by Simon Fraser.
We should prevent websites from learning which sites have been visited via
SVG
filters on hyperlinks, per the attack described in
https://arxiv.org/abs/2305.12784.
This is a follow up for 266683@main. The background color of the visited
links
should be ignored when an SVG filter is applied.
* LayoutTests/css3/filters/filter-visited-links-expected.html:
* LayoutTests/css3/filters/filter-visited-links.html:
* Source/WebCore/rendering/InlineBoxPainter.cpp:
(WebCore::InlineBoxPainter::paintDecorations):
Canonical link: https://commits.webkit.org/272448.560@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.268@webkitglib/2.44
Commit: e5b99737a050e85bb92878e04bad9ed2a49b5b74
https://github.com/WebKit/WebKit/commit/e5b99737a050e85bb92878e04bad9ed2a49b5b74
Author: Scott Marcy <msc...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A LayoutTests/fast/svg/mutual-recursion-test-expected.txt
A LayoutTests/fast/svg/mutual-recursion-test.html
M Source/WebCore/rendering/svg/SVGResources.cpp
M Source/WebCore/rendering/svg/SVGResources.h
Log Message:
-----------
Cherry-pick 272448.561@safari-7618-branch (e14592228595).
https://bugs.webkit.org/show_bug.cgi?id=268556
Break a mutual recursion cycle laying out SVG elements.
https://bugs.webkit.org/show_bug.cgi?id=268556
rdar://118510445
Reviewed by shallawa (Said Abou-Hallawa).
Breaks the recursion cycle by having the SVGResource object track if it is
already doing layout for a different root.
* LayoutTests/fast/svg/mutual-recursion-test-expected.txt: Added.
* LayoutTests/fast/svg/mutual-recursion-test.html: Added.
* Source/WebCore/rendering/svg/SVGResources.cpp:
(WebCore::SVGResources::layoutDifferentRootIfNeeded):
* Source/WebCore/rendering/svg/SVGResources.h:
Canonical link: https://commits.webkit.org/272448.561@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.269@webkitglib/2.44
Commit: b304ede731cf4bfbbf069c39206047eee9bf7ce4
https://github.com/WebKit/WebKit/commit/b304ede731cf4bfbbf069c39206047eee9bf7ce4
Author: Keith Miller <keith_mil...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
Log Message:
-----------
Cherry-pick 272448.563@safari-7618-branch (630351ee51ab).
https://bugs.webkit.org/show_bug.cgi?id=269220
[JSC] presenceConditionIfConsistent should check knownBase's structure is
in the structure set
https://bugs.webkit.org/show_bug.cgi?id=269220
rdar://122171551
Reviewed by Yusuke Suzuki.
This patch rewrites ByteCodeParser::presenceConditionIfConsistent. Now it
just checks that the presence condition
we're trying to create is possible for the knownBase. Additionally, we have
to check that the knownBase's structure
was executed at least once before. This allows us to know if
GetOwnPropertySlot ran successfully at least once for
this structure.
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::presenceConditionIfConsistent):
Canonical link: https://commits.webkit.org/272448.563@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.270@webkitglib/2.44
Commit: 04cf158f8e87d105da76842c5a7b6beb03b5d88a
https://github.com/WebKit/WebKit/commit/04cf158f8e87d105da76842c5a7b6beb03b5d88a
Author: Tyler Wilcock <tyle...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/accessibility/AccessibilityListBoxOption.cpp
Log Message:
-----------
Cherry-pick 272448.566@safari-7618-branch (1bd91e17cd5b). rdar://122892805
AX: AccessibilityListBoxOption::elementRect() should use dynamicDowncast
instead of downcast
rdar://122892805
Reviewed by Chris Fleizach.
Failing to do so can cause a crash. Also improve smart pointer usage in
this function, and eliminate instances of doing work that never gets
used depending on branches taken.
* Source/WebCore/accessibility/AccessibilityListBoxOption.cpp:
(WebCore::AccessibilityListBoxOption::elementRect const):
Canonical link: https://commits.webkit.org/272448.566@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.271@webkitglib/2.44
Commit: 9dd183796e2397fd36dd52809ea82c379a9e0a2b
https://github.com/WebKit/WebKit/commit/9dd183796e2397fd36dd52809ea82c379a9e0a2b
Author: Ryosuke Niwa <rn...@webkit.org>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py
M Source/WebCore/dom/ScriptElement.cpp
M Source/WebCore/svg/SVGElement.cpp
Log Message:
-----------
Cherry-pick 272448.567@safari-7618-branch (d915a3b6357c).
https://bugs.webkit.org/show_bug.cgi?id=268598
nonce hiding in SVG is buggy
https://bugs.webkit.org/show_bug.cgi?id=268598
Reviewed by Chris Dumez.
The bug was caused by SVGElement::insertedIntoAncestor hiding nonce after
it had an early exit for returning
InsertedIntoAncestorResult::NeedsPostInsertionCallback. Fixed the bug by
hiding it before this early exit.
*
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py:
Added.
* Source/WebCore/dom/ScriptElement.cpp:
(WebCore::ScriptElement::didFinishInsertingNode):
* Source/WebCore/svg/SVGElement.cpp:
(WebCore::SVGElement::insertedIntoAncestor):
Canonical link: https://commits.webkit.org/272448.567@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.272@webkitglib/2.44
Commit: 2fdf11cf5f045bde902d2b37642685551ef61041
https://github.com/WebKit/WebKit/commit/2fdf11cf5f045bde902d2b37642685551ef61041
Author: Chris Dumez <cdu...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/workers/WorkerOrWorkletThread.cpp
Log Message:
-----------
Cherry-pick 272448.578@safari-7618-branch (459d377c63c2).
https://bugs.webkit.org/show_bug.cgi?id=269731
Flaky crash under WorkerDedicatedRunLoop::runCleanupTasks() during fuzzing
https://bugs.webkit.org/show_bug.cgi?id=269731
rdar://121961101
Reviewed by Brent Fulgham.
I haven't been able to reproduce but based on the ASAN report, it looks
like the WorkerOrWorkletGlobalScope is getting destroyed in the middle
of WorkerDedicatedRunLoop::runCleanupTasks(), causing a use-after free
of the context.
To make sure this can't happen, apply our smart pointer adoption rules
and make sure the WorkerOrWorkletGlobalScope is being protected on the
stack at the call site of WorkerDedicatedRunLoop::run() before passing
it in argument.
* Source/WebCore/workers/WorkerOrWorkletThread.cpp:
(WebCore::WorkerOrWorkletThread::runEventLoop):
Canonical link: https://commits.webkit.org/272448.578@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.273@webkitglib/2.44
Commit: 2153a1f55818faea01a1567be2785afad389890d
https://github.com/WebKit/WebKit/commit/2153a1f55818faea01a1567be2785afad389890d
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/loader/EmptyClients.cpp
M Source/WebCore/page/EditorClient.h
M Source/WebCore/page/LocalFrame.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.h
Log Message:
-----------
Cherry-pick 272448.579@safari-7618-branch (be0e10372eb5).
https://bugs.webkit.org/show_bug.cgi?id=269769
Compromised web process can grant pasteboard access by spamming
WebPage::RequestDOMPasteAccess
https://bugs.webkit.org/show_bug.cgi?id=269769
rdar://97343267
Reviewed by Ryosuke Niwa and Richard Robinson.
It's currently possible for a compromised web process to send arbitrary
`originIdentifiers` through
`requestDOMPasteAccess` to the UI process during programmatic paste. Since
the UI process
automatically grants programmatic pasteboard access in the case where the
incoming origin ID matches
the origin ID of the current pasteboard content, it's possible to send a
large number of origins
through this IPC endpoint, with the end goal of discovering both (1) which
website origin the user
last copied from, and (2) the contents of the pasteboard in the case where
the pasteboard copied
from web content in WebKit.
To mitigate this attack vector, we add a `FrameIdentifier` in the IPC
endpoint, which is used in the
UI process to verify that:
1. The incoming frame ID corresponds to a frame underneath the destination
page.
2. The pasteboard origin matches the origin of the frame, unless the
pasteboard origin is an opaque
(null) origin.
Additionally, we throttle pasteboard access requests to a maximum of 10
different domains every 5
seconds, to mitigate another variation on this attack vector where the
compromised web process loads
a large number of cross-origin frames and requests pasteboard access on
behalf of those origins, in
an attempt to get around the limitations above.
With this change, a compromised web process is only capable of grabbing
data for a pasteboard origin
that matches itself, or another origin under the same `WebPage`.
* Source/WebCore/loader/EmptyClients.cpp:
* Source/WebCore/page/EditorClient.h:
* Source/WebCore/page/LocalFrame.cpp:
(WebCore::LocalFrame::requestDOMPasteAccess):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::requestDOMPasteAccess):
Add the new `MESSAGE_CHECK`s.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp:
(WebKit::WebEditorClient::requestDOMPasteAccess):
* Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::requestDOMPasteAccess):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.h:
Canonical link: https://commits.webkit.org/272448.579@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.274@webkitglib/2.44
Commit: c65c2f9c0a8ea51f003b59322819c80dddd7d988
https://github.com/WebKit/WebKit/commit/c65c2f9c0a8ea51f003b59322819c80dddd7d988
Author: Nisha Jain <nisha_j...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A
LayoutTests/fast/rendering/render-layer-with-providedbacking-crash-expected.txt
A LayoutTests/fast/rendering/render-layer-with-providedbacking-crash.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick 272448.600@safari-7618-branch (fc090f6ee88d).
https://bugs.webkit.org/show_bug.cgi?id=269865
RenderLayer : Unbalanced begin/endTransparencyLayers with nested masked
elements and backing sharing causes a crash.
https://bugs.webkit.org/show_bug.cgi?id=269865
rdar://113144444.
Reviewed by Simon Fraser.
In order to balance the begin/endTransparencyLayers call for a
TransparencyLayer with nested masked elements and backing sharing, added
'provided backing/paint to' into account while doing 'ancestor' traversal.
*
LayoutTests/fast/rendering/render-layer-with-providedbacking-crash-expected.txt:
Added.
* LayoutTests/fast/rendering/render-layer-with-providedbacking-crash.html:
Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::transparentPaintingAncestor):
Canonical link: https://commits.webkit.org/272448.600@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.275@webkitglib/2.44
Commit: b584f36a37b9951596d4445a8627dd72c7eb9d41
https://github.com/WebKit/WebKit/commit/b584f36a37b9951596d4445a8627dd72c7eb9d41
Author: Antti Koivisto <an...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A LayoutTests/fast/ruby/ruby-continuation-crash-expected.txt
A LayoutTests/fast/ruby/ruby-continuation-crash.html
M Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
Log Message:
-----------
Cherry-pick 272448.763@safari-7618-branch (df9629adcf83).
https://bugs.webkit.org/show_bug.cgi?id=271167
Crash with ruby and continuations
https://bugs.webkit.org/show_bug.cgi?id=271167
rdar://124432235
Reviewed by Ryosuke Niwa.
* LayoutTests/fast/ruby/ruby-continuation-crash-expected.txt: Added.
* LayoutTests/fast/ruby/ruby-continuation-crash.html: Added.
* Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:
(WebCore::RenderTreeBuilder::destroyAndCleanUpAnonymousWrappers):
Improve robustness by using WeakPtr for destroyRoot and null checking
before calling destroy(*destroyRoot)
as it might get deleted by an earlier destroy() call.
Canonical link: https://commits.webkit.org/272448.763@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.276@webkitglib/2.44
Commit: 0570649a48242bce89bba815c19a98c4f9d07c96
https://github.com/WebKit/WebKit/commit/0570649a48242bce89bba815c19a98c4f9d07c96
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioWorkletMessagingProxy.cpp
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/EmptyScriptExecutionContext.h
M Source/WebCore/dom/ScriptExecutionContext.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/workers/Worker.cpp
M Source/WebCore/workers/WorkerGlobalScope.cpp
M Source/WebCore/workers/WorkerInitializationData.h
M Source/WebCore/workers/WorkerMessagingProxy.cpp
M Source/WebCore/workers/WorkerOrWorkletGlobalScope.cpp
M Source/WebCore/workers/WorkerOrWorkletGlobalScope.h
M Source/WebCore/workers/WorkerScriptLoader.cpp
M Source/WebCore/workers/WorkerScriptLoader.h
M Source/WebCore/workers/WorkerThread.cpp
M Source/WebCore/workers/WorkerThread.h
M Source/WebCore/workers/service/ServiceWorkerClientData.cpp
M Source/WebCore/workers/service/ServiceWorkerClientData.h
M Source/WebCore/workers/service/context/ServiceWorkerThread.cpp
M Source/WebCore/workers/service/context/ServiceWorkerThread.h
M Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServer.h
M Source/WebCore/workers/service/server/SWServerToContextConnection.h
M Source/WebCore/workers/shared/SharedWorkerScriptLoader.cpp
M Source/WebCore/workers/shared/context/SharedWorkerThreadProxy.cpp
M Source/WebCore/worklets/WorkletGlobalScope.cpp
M Source/WebCore/worklets/WorkletParameters.h
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp
M
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.messages.in
M
Source/WebKit/WebProcess/Storage/WebSharedWorkerContextManagerConnection.cpp
M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm
Log Message:
-----------
Cherry-pick 272448.764@safari-7618-branch (e285de6f4a70).
https://bugs.webkit.org/show_bug.cgi?id=271159
[Private Browsing] Noise injection doesn't apply when using OffscreenCanvas
in shared/service workers
https://bugs.webkit.org/show_bug.cgi?id=271159
rdar://124702163
Reviewed by Sihui Liu and Chris Dumez.
In Private Browsing mode in Safari 17, each `ScriptExecutionContext` has a
noise injection hash salt
(unique by security origin) and `AdvancedPrivacyProtections` flags, sourced
from the document
loader. These are used to generate noise when reading pixels back from
`canvas` or `OffscreenCanvas`.
For dedicated workers, plumbing already exists to propagate the hash salt
via `WorkerParameters` to
`WorkerGlobalScope`, where they apply to `OffscreenCanvas`. However, for
both shared workers and
service workers, this is insufficient, since the `OffscreenCanvas` APIs are
called in a separate,
potentially-remote `Page` (which currently has neither a hash salt nor the
requisite
`AdvancedPrivacyProtections` flags).
To fix this, we extend `AdvancedPrivacyProtection` flag plumbing to work
for these two remaining
types of workers; see below for more details.
Test:
AdvancedPrivacyProtections.NoiseInjectionForOffscreenCanvasInSharedWorker
* Source/WebCore/Modules/webaudio/AudioWorkletMessagingProxy.cpp:
(WebCore::generateWorkletParameters):
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::noiseInjectionPolicy const):
(WebCore::Document::advancedPrivacyProtections const):
* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/EmptyScriptExecutionContext.h:
* Source/WebCore/dom/ScriptExecutionContext.h:
Add an override point to return the set of active advanced privacy
protection flags. For `Document`,
this goes through the top document's loader. For worklets and workers, this
state is passed in via
`WorkerParameters` and `WorkletParameters`.
* Source/WebCore/page/Page.cpp:
(WebCore::Page::setupForRemoteWorker):
Allow shared/service workers to pass in privacy protections when
initializing the remote `Page`.
* Source/WebCore/page/Page.h:
* Source/WebCore/workers/Worker.cpp:
(WebCore::Worker::notifyFinished):
* Source/WebCore/workers/WorkerGlobalScope.cpp:
(WebCore::WorkerGlobalScope::WorkerGlobalScope):
* Source/WebCore/workers/WorkerInitializationData.h:
(WebCore::WorkerInitializationData::isolatedCopy const):
* Source/WebCore/workers/WorkerMessagingProxy.cpp:
(WebCore::WorkerMessagingProxy::startWorkerGlobalScope):
* Source/WebCore/workers/WorkerOrWorkletGlobalScope.cpp:
(WebCore::WorkerOrWorkletGlobalScope::WorkerOrWorkletGlobalScope):
* Source/WebCore/workers/WorkerOrWorkletGlobalScope.h:
(WebCore::WorkerOrWorkletGlobalScope::WorkerOrWorkletGlobalScope):
* Source/WebCore/workers/WorkerScriptLoader.cpp:
(WebCore::WorkerScriptLoader::loadSynchronously):
(WebCore::WorkerScriptLoader::loadAsynchronously):
* Source/WebCore/workers/WorkerScriptLoader.h:
(WebCore::WorkerScriptLoader::advancedPrivacyProtections const):
Add a member as well as a getter to keep track of the active privacy
protections for the currently
loading (or loaded) worker. Later consulted in `SharedWorkerScriptLoader`
to plumb the protection
options into `WorkerInitializationData`, when spinning up shared workers.
* Source/WebCore/workers/WorkerThread.cpp:
(WebCore::WorkerParameters::isolatedCopy const):
* Source/WebCore/workers/WorkerThread.h:
* Source/WebCore/workers/service/ServiceWorkerClientData.cpp:
(WebCore::ServiceWorkerClientData::isolatedCopy const):
(WebCore::ServiceWorkerClientData::isolatedCopy):
(WebCore::ServiceWorkerClientData::from):
* Source/WebCore/workers/service/ServiceWorkerClientData.h:
* Source/WebCore/workers/service/context/ServiceWorkerThread.cpp:
(WebCore::generateWorkerParameters):
(WebCore::ServiceWorkerThread::ServiceWorkerThread):
* Source/WebCore/workers/service/context/ServiceWorkerThread.h:
* Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp:
(WebCore::ServiceWorkerThreadProxy::ServiceWorkerThreadProxy):
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::forEachClientForOriginImpl):
(WebCore::SWServer::forEachClientForOrigin const):
(WebCore::SWServer::forEachClientForOrigin):
(WebCore::SWServer::advancedPrivacyProtectionsFromClient const):
When installing a new service worker, consult the set of matching clients
(by client origin), to
check if any clients of the service worker have active privacy protections;
pass along the union of
these active policies when installing the service worker.
(WebCore::SWServer::installContextData):
Pass in `AdvancedPrivacyProtections` when spinning up a new service worker.
(WebCore::SWServer::runServiceWorker):
* Source/WebCore/workers/service/server/SWServer.h:
* Source/WebCore/workers/service/server/SWServerToContextConnection.h:
* Source/WebCore/workers/shared/SharedWorkerScriptLoader.cpp:
(WebCore::SharedWorkerScriptLoader::notifyFinished):
* Source/WebCore/workers/shared/context/SharedWorkerThreadProxy.cpp:
(WebCore::generateWorkerParameters):
* Source/WebCore/worklets/WorkletGlobalScope.cpp:
(WebCore::WorkletGlobalScope::WorkletGlobalScope):
* Source/WebCore/worklets/WorkletParameters.h:
(WebCore::WorkletParameters::isolatedCopy const):
(WebCore::WorkletParameters::isolatedCopy):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::controlClient):
*
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp:
(WebKit::WebSWServerToContextConnection::installServiceWorkerContext):
*
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp:
(WebKit::WebSWContextManagerConnection::installServiceWorker):
Call `setupForRemoteWorker` with the privacy protection flags.
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h:
*
Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.messages.in:
*
Source/WebKit/WebProcess/Storage/WebSharedWorkerContextManagerConnection.cpp:
(WebKit::WebSharedWorkerContextManagerConnection::launchSharedWorker):
Call `setupForRemoteWorker` with the privacy protection flags.
* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
(TestWebKitAPI::sharedWorkerMainBytes):
Add a new API test.
Canonical link: https://commits.webkit.org/272448.764@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.277@webkitglib/2.44
Commit: 279c9d7963182cc35cf4e0bfebe87df2d83eaef8
https://github.com/WebKit/WebKit/commit/279c9d7963182cc35cf4e0bfebe87df2d83eaef8
Author: Keith Miller <keith_mil...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A JSTests/wasm/stress/many-calls-results-on-stack.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Cherry-pick 272448.770@safari-7618-branch (6d311cd7fefc).
https://bugs.webkit.org/show_bug.cgi?id=271175
BBQ needs to move stack results from a call to their canonical location
https://bugs.webkit.org/show_bug.cgi?id=271175
rdar://124060867
Reviewed by Yusuke Suzuki.
Right now we can end up clobbering a value, `X`, on the stack in BBQ
because it gets left in a
`StackArgument` `Location` after a call. This breaks when a later call
before `X` has been consumed
would set the same `StackArgument` location as `X`. The fix is to just
always move stack results
to their canonical location. This is probably fine because stack results
are super rare in practice.
* JSTests/wasm/stress/many-calls-results-on-stack.js: Added.
(repeat):
(check):
(async test):
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJIT::returnValuesFromCall):
Canonical link: https://commits.webkit.org/272448.770@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.278@webkitglib/2.44
Commit: 2e380f6b35eee137028c7485fc2043029cd6da30
https://github.com/WebKit/WebKit/commit/2e380f6b35eee137028c7485fc2043029cd6da30
Author: David Degazio <d_dega...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A
JSTests/wasm/stress/catch-should-keep-alive-inline-parent-expression-stack.js
M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
Log Message:
-----------
Cherry-pick 272448.849@safari-7618-branch (0b59e3f5e9ff).
https://bugs.webkit.org/show_bug.cgi?id=271987
[JSC] Catch should preserve top expression stack of inline parents in OMG
https://bugs.webkit.org/show_bug.cgi?id=271987
rdar://125145754
Reviewed by Justin Michaud.
This patch makes it so we include the top-level expression stack
(m_parser->expressionStack()) among the values we consider live when
figuring
out which values need to be reloaded at a catch entrypoint. Previously, we
only
considered the enclosed expression stacks buried in the control entries for
each inline parent, which only captures values live in enclosing blocks and
not
the current block being executed.
*
JSTests/wasm/stress/catch-should-keep-alive-inline-parent-expression-stack.js:
Added.
(async test):
* Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::preparePatchpointForExceptions):
(JSC::Wasm::B3IRGenerator::emitCatchImpl):
Canonical link: https://commits.webkit.org/272448.849@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.279@webkitglib/2.44
Commit: 8e20e7adc44316af84e19e23261dfa9172b0cd2b
https://github.com/WebKit/WebKit/commit/8e20e7adc44316af84e19e23261dfa9172b0cd2b
Author: Rob Buis <rb...@igalia.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A
LayoutTests/fast/css/repeating-radial-gradient-small-range-large-extent-expected.txt
A
LayoutTests/fast/css/repeating-radial-gradient-small-range-large-extent.html
M Source/WebCore/rendering/style/StyleGradientImage.cpp
Log Message:
-----------
Cherry-pick 274097.16@webkit-2024.2-embargoed (c2f3e54dfeed).
https://bugs.webkit.org/show_bug.cgi?id=271904
ASAN_TRAP | WTF::Vector::expandCapacity; WTF::Vector::expandCapacity;
WTF::Vector::appendSlowCase
https://bugs.webkit.org/show_bug.cgi?id=271904
Reviewed by Antti Koivisto.
For https://bugs.webkit.org/show_bug.cgi?id=264639 a fix was done to deal
with repeating gradients
where a tiny offset range was repeated, causing a large number of items to
be added to the stop vector.
That fix does not apply when the offset range is reasonable but the
maxExtent is large. So, also take the
maxExtent into account when deciding whether to produce extra gradient
stops.
*
LayoutTests/fast/css/repeating-radial-gradient-small-range-large-extent-expected.txt:
Added.
*
LayoutTests/fast/css/repeating-radial-gradient-small-range-large-extent.html:
Added.
* Source/WebCore/rendering/style/StyleGradientImage.cpp:
(WebCore::StyleGradientImage::computeStops const):
Canonical link: https://commits.webkit.org/274097.16@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.888@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.280@webkitglib/2.44
Commit: 3dd3ae5e0d8e094c76ab9268a13797c4fef0b161
https://github.com/WebKit/WebKit/commit/3dd3ae5e0d8e094c76ab9268a13797c4fef0b161
Author: Nitin Mahendru <nitinmahen...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 272448.906@safari-7618-branch (cb2f03208aa6).
https://bugs.webkit.org/show_bug.cgi?id=272491
Removing unbounded resize of Vector
https://bugs.webkit.org/show_bug.cgi?id=272491
rdar://126132559
Reviewed by Alex Christensen.
Resize the vector with an option to fallback to default value.
Test Case has been added to verify the fix.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::readRTCCertificate):
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebCore/SerializedScriptValue.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/272448.906@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.281@webkitglib/2.44
Commit: f20814203a5ae26ec5f8349285f83d8d87cf7221
https://github.com/WebKit/WebKit/commit/f20814203a5ae26ec5f8349285f83d8d87cf7221
Author: Chris Dumez <cdu...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioBuffer.cpp
M Source/WebCore/Modules/webaudio/AudioBuffer.h
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h
Log Message:
-----------
Cherry-pick 272448.925@safari-7618-branch (4201e96638f0).
https://bugs.webkit.org/show_bug.cgi?id=272607
[WebAudio] Use-after-free in
WebCore::AudioBufferSourceNode::renderFromBuffer
https://bugs.webkit.org/show_bug.cgi?id=272607
rdar://126326144
Reviewed by Yusuke Suzuki.
The JS on the main thread can detach the AudioBuffer's channels while
it is being read by the audio rendering thread, causing use-after-frees.
In a previous fix attempt, we starting copying the AudioBuffer's channels
so that the audio thread would read a copy instead. However, the increased
memory usage resulted in increased jetsams on gaming sites.
As a temporary stop gap measure, this patch simply marks the AudioBuffer's
channels as non-detachable to prevent the issue. This is not quite spec
compliant but it addresses the security issue until we can implement the
specification correctly without causing jetsams.
* Source/WebCore/Modules/webaudio/AudioBuffer.cpp:
(WebCore::AudioBuffer::markBuffersAsNonDetachable):
* Source/WebCore/Modules/webaudio/AudioBuffer.h:
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
(WebCore::AudioBufferSourceNode::acquireBufferContent):
(WebCore::AudioBufferSourceNode::setBufferForBindings):
(WebCore::AudioBufferSourceNode::startPlaying):
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h:
Canonical link: https://commits.webkit.org/272448.925@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.282@webkitglib/2.44
Commit: 0badc7896b26c6dec585a09751c15a307d8fa3c9
https://github.com/WebKit/WebKit/commit/0badc7896b26c6dec585a09751c15a307d8fa3c9
Author: Vitor Roriz <vitor.ro...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-balance-empty-range-crash-expected.html
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-balance-empty-range-crash.html
M Source/WebCore/layout/formattingContexts/inline/InlineContentBalancer.cpp
Log Message:
-----------
Cherry-pick 272448.926@safari-7618-branch (a76aaa768a18). rdar://126011869
Guard balanceRangeWithLineRequirement against empty/invalid ranges
rdar://126011869
Reviewed by Brent Fulgham.
InlineItemRange is used for calculating the
number of line break opportunities (NLBO),
We always insert at least 1 dummy item to the Vector
tracking line break opportunities for algorithm purposes,
so NLBO is never zero. However, when initializing
SlidingWidth, balanceRangeWithLineRequirement starts
counting line break opportunities from startIndex = 1,
assuming that the received range had at least 1 item.
We should consider that an empty or invalid range
can be received and guard against it.
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-balance-empty-range-crash-expected.html:
Added.
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-balance-empty-range-crash.html:
Added.
* Source/WebCore/layout/formattingContexts/inline/InlineContentBalancer.cpp:
(WebCore::Layout::InlineContentBalancer::computeBalanceConstraints):
(WebCore::Layout::InlineContentBalancer::balanceRangeWithLineRequirement):
(WebCore::Layout::InlineContentBalancer::balanceRangeWithNoLineRequirement):
Canonical link: https://commits.webkit.org/272448.926@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.283@webkitglib/2.44
Commit: 5ca7c9873a9ec6f245d61538ca1cd29214c909c3
https://github.com/WebKit/WebKit/commit/5ca7c9873a9ec6f245d61538ca1cd29214c909c3
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2024-05-28 (Tue, 28 May 2024)
Changed paths:
A JSTests/wasm/stress/try-and-block-with-v128-results.js
A JSTests/wasm/stress/try-and-block-with-v128-results.wasm
M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
Log Message:
-----------
Cherry-pick 272448.873@safari-7618-branch (e6123d8a8215).
https://bugs.webkit.org/show_bug.cgi?id=271494
[WASM] Block with v128 results should notify SIMD uses
https://bugs.webkit.org/show_bug.cgi?id=271494
rdar://125146449
Reviewed by Justin Michaud.
We should notify the SIMD use when wasm block within the code has v128
results.
* JSTests/wasm/stress/try-and-block-with-v128-results.js: Added.
(globalThis.callerIsBBQOrOMGCompiled.instantiateJsc):
(else.instantiateBrowser):
(async let):
* JSTests/wasm/stress/try-and-block-with-v128-results.wasm: Added.
Canonical link: https://commits.webkit.org/272448.873@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.284@webkitglib/2.44
Compare: https://github.com/WebKit/WebKit/compare/6f733fdfb8d2...5ca7c9873a9e
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
