Branch: refs/heads/webkitglib/2.42
Home: https://github.com/WebKit/WebKit
Commit: ccb347deb663acb38a2b8be927a48bfdf3bccc2d
https://github.com/WebKit/WebKit/commit/ccb347deb663acb38a2b8be927a48bfdf3bccc2d
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/page/NavigatorBase.cpp
M Source/WebCore/workers/WorkerOrWorkletGlobalScope.cpp
M Source/WebCore/workers/shared/SharedWorkerGlobalScope.cpp
Log Message:
-----------
Cherry-pick 273637@main (23ed729b1703).
https://bugs.webkit.org/show_bug.cgi?id=268194
ASSERTION FAILED: m_suspendIfNeededWasCalled
https://bugs.webkit.org/show_bug.cgi?id=268194
rdar://121689893
Reviewed by Darin Adler.
Protect the scriptExecutionContext in NavigatorBase::serviceWorker()
before passing it to ServiceWorkerContainer::create().
* Source/WebCore/page/NavigatorBase.cpp:
(WebCore::NavigatorBase::serviceWorker):
Canonical link: https://commits.webkit.org/273637@main
Canonical link: https://commits.webkit.org/266719.354@webkitglib/2.42
Commit: d121f6653698ffc40b8288b185c86f7ad6481774
https://github.com/WebKit/WebKit/commit/d121f6653698ffc40b8288b185c86f7ad6481774
Author: David Kilzer <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/ThirdParty/libwebrtc/Source/webrtc/api/sctp_transport_interface.h
Log Message:
-----------
Cherry-pick 273738@main (5201724511e7).
https://bugs.webkit.org/show_bug.cgi?id=268258
webrtc::SctpTransportInformation::state_ is not initialized in default
constructor
https://bugs.webkit.org/show_bug.cgi?id=268258
<rdar://121811341>
Reviewed by Youenn Fablet.
* Source/ThirdParty/libwebrtc/Source/webrtc/api/sctp_transport_interface.h:
(webrtc::SctpTransportInformation):
- Initialize state_ to SctpTransportState::kNew.
Canonical link: https://commits.webkit.org/273738@main
Canonical link: https://commits.webkit.org/266719.355@webkitglib/2.42
Commit: 53c8c77c7f67778ff618692ed1d515f5b70b10dc
https://github.com/WebKit/WebKit/commit/53c8c77c7f67778ff618692ed1d515f5b70b10dc
Author: Adrian Perez de Castro <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/ThirdParty/libwebrtc/CMakeLists.txt
M
Source/ThirdParty/libwebrtc/Source/webrtc/modules/rtp_rtcp/source/rtcp_transceiver_impl.cc
Log Message:
-----------
Fix the build when using libwebrtc
Unreviewed build fixes.
* Source/ThirdParty/libwebrtc/CMakeLists.txt: Set the CXX_STANDARD
property on the webrtc target to use C++17, as required by some part
of libabseil.
*
Source/ThirdParty/libwebrtc/Source/webrtc/modules/rtp_rtcp/source/rtcp_transceiver_impl.cc:
Add missing include for <optional>.
Canonical link: https://commits.webkit.org/266719.356@webkitglib/2.42
Commit: 836179dd795b891aa7925d2e791444e1999419b8
https://github.com/WebKit/WebKit/commit/836179dd795b891aa7925d2e791444e1999419b8
Author: Yusuke Suzuki <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/runtime/JSLock.cpp
Log Message:
-----------
Cherry-pick 273803@main (fa7db09c3bb2).
https://bugs.webkit.org/show_bug.cgi?id=268415
[JSC] Do not destroy VM after clearing AtomStringTable for current thread
https://bugs.webkit.org/show_bug.cgi?id=268415
rdar://86151259
Reviewed by Michael Saboff.
This patch changes the ordering of VM destruction and thread's
AtomStringTable clearing.
This happens when JSVirtualMachine gets destroyed during execution of
microtasks. While this
should not happen (because it is destroying VM while running code
associated to this VM), we
can alleviate this case by destroying VM under the right AtomStringTable.
* Source/JavaScriptCore/runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
Canonical link: https://commits.webkit.org/273803@main
Canonical link: https://commits.webkit.org/266719.357@webkitglib/2.42
Commit: bc083b65c3cb597f09228e80de744985fa1be2f7
https://github.com/WebKit/WebKit/commit/bc083b65c3cb597f09228e80de744985fa1be2f7
Author: Youenn Fablet <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A LayoutTests/http/wpt/webcodecs/h264_small-size.any-expected.txt
A LayoutTests/http/wpt/webcodecs/h264_small-size.any.html
A LayoutTests/http/wpt/webcodecs/h264_small-size.any.js
M Source/ThirdParty/libwebrtc/Source/webrtc/common_video/h264/sps_parser.cc
M Source/ThirdParty/libwebrtc/Source/webrtc/common_video/h264/sps_parser.h
M
Source/ThirdParty/libwebrtc/Source/webrtc/sdk/objc/components/video_codec/nalu_rewriter.cc
Log Message:
-----------
Cherry-pick 273823@main (a8ddee0e8c2e).
https://bugs.webkit.org/show_bug.cgi?id=268440
ComputeH264ReorderSizeFromSPS should use pic_width_in_mbs_minus1 and
pic_height_in_map_units_minus1 to compute max_dpb_frames_from_sps
https://bugs.webkit.org/show_bug.cgi?id=268440
rdar://121957799
Reviewed by Jean-Yves Avenard.
Using state.width and state.height for max_dpb_frames_from_sps computation
can lead to divide by zero issues since either one can be below 16.
We instead use pic_width_in_mbs_minus1 and pic_height_in_map_units_minus1
to ensure we do not divide by zero.
* LayoutTests/http/wpt/webcodecs/h264_small-size.any-expected.txt: Added.
* LayoutTests/http/wpt/webcodecs/h264_small-size.any.html: Added.
* LayoutTests/http/wpt/webcodecs/h264_small-size.any.js: Added.
(promise_test.async t):
* Source/ThirdParty/libwebrtc/Source/webrtc/common_video/h264/sps_parser.cc:
* Source/ThirdParty/libwebrtc/Source/webrtc/common_video/h264/sps_parser.h:
*
Source/ThirdParty/libwebrtc/Source/webrtc/sdk/objc/components/video_codec/nalu_rewriter.cc:
Canonical link: https://commits.webkit.org/273823@main
Canonical link: https://commits.webkit.org/266719.358@webkitglib/2.42
Commit: 6d9f34215008dc36bac9fdb66b30f9db15df1e46
https://github.com/WebKit/WebKit/commit/6d9f34215008dc36bac9fdb66b30f9db15df1e46
Author: Kimmo Kinnunen <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/Platform/IPC/Connection.cpp
M Source/WebKit/Platform/IPC/Connection.h
M Source/WebKit/Platform/IPC/StreamClientConnection.cpp
M Source/WebKit/Platform/IPC/StreamClientConnection.h
M Tools/TestWebKitAPI/Tests/IPC/ConnectionTests.cpp
M Tools/TestWebKitAPI/Tests/IPC/StreamConnectionTests.cpp
Log Message:
-----------
Cherry-pick 273851@main (d1fb58818ff3).
https://bugs.webkit.org/show_bug.cgi?id=268362
Unthrottled IPC::Connection loses messages when connection is closed
https://bugs.webkit.org/show_bug.cgi?id=268362
rdar://121910136
Reviewed by Matt Woodrow.
When IPC::Connection::invalidate() would be called, some of the messages
already sent might have been lost:
1. Unsent messages due to outgoing messages buffering
2. Messages not delivered at the recipient because message delivery
would check isValid()
Fix 1. by adding a blocking IPC::Connection::flushSentMessages()
that will wait until send list flips to zero.
The flushSentMessages() call is distinct from invalidate() to preserve
the ability to call invalidate() in non-blocking manner.
Fix 2. by not checking for isValid() but for m_client / m_syncState.
isValid() flips immediately in the IPC receive queue when OS signals
that the connection was closed.
m_client, m_syncState flips to nullptr when client signals that
they do not want to receive messages anymore, via invalidate().
By contract, IPC::Connection invalidates itself after Client::didClose(),
too.
Fixes mostly upcoming GPUP cases where one connection is closed, but
not the whole per-WP session (GPUConnectionToWebProcess). The
individual connections might carry important messages up until
the disconnection, so all must be played back before handling the
connection closing.
* Source/WebKit/Platform/IPC/Connection.cpp:
(IPC::Connection::flushSentMessages):
(IPC::Connection::connectionDidClose):
(IPC::Connection::sendOutgoingMessages):
(IPC::Connection::dispatchMessage):
* Source/WebKit/Platform/IPC/Connection.h:
* Source/WebKit/Platform/IPC/StreamClientConnection.cpp:
(IPC::StreamClientConnection::flushSentMessages):
* Source/WebKit/Platform/IPC/StreamClientConnection.h:
* Tools/TestWebKitAPI/Tests/IPC/ConnectionTests.cpp:
(TestWebKitAPI::TEST_P):
* Tools/TestWebKitAPI/Tests/IPC/StreamConnectionTests.cpp:
(TestWebKitAPI::TEST_P):
Canonical link: https://commits.webkit.org/273851@main
Canonical link: https://commits.webkit.org/266719.359@webkitglib/2.42
Commit: 3e6ec526a4645886e6e68090a97047357b1eaffd
https://github.com/WebKit/WebKit/commit/3e6ec526a4645886e6e68090a97047357b1eaffd
Author: Charlie Wolfe <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/platform/Widget.cpp
M Source/WebCore/platform/Widget.h
Log Message:
-----------
Cherry-pick 273869@main (5373d9e1c714).
https://bugs.webkit.org/show_bug.cgi?id=268428
Widget::root() should return a FrameView
https://bugs.webkit.org/show_bug.cgi?id=268428
rdar://121974586
Reviewed by Alex Christensen.
Widget::root() should return the top FrameView even if it is being hosted
in another process.
* Source/WebCore/platform/Widget.cpp:
(WebCore::Widget::root const):
* Source/WebCore/platform/Widget.h:
Canonical link: https://commits.webkit.org/273869@main
Canonical link: https://commits.webkit.org/266719.360@webkitglib/2.42
Commit: 35a830599d112f84e3b72fb9c58a1ca8ffb8526b
https://github.com/WebKit/WebKit/commit/35a830599d112f84e3b72fb9c58a1ca8ffb8526b
Author: Tim Nguyen <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/fullscreen/fullscreen-add-disconnected-to-top-layer-expected.txt
A LayoutTests/fullscreen/fullscreen-add-disconnected-to-top-layer.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 273885@main (de15933efb3d).
https://bugs.webkit.org/show_bug.cgi?id=268434
CrashTracer: com.apple.WebKit.WebContent at WebCore:
WebCore::Document::addTopLayerElement
https://bugs.webkit.org/show_bug.cgi?id=268434
rdar://117975912
Reviewed by Chris Dumez.
The release assertion here is bogus, the top layer is a DOM construct that
is used for various DOM algorithms, not just a rendering one.
Things in the top layer are not required to be rendered.
*
LayoutTests/fullscreen/fullscreen-add-disconnected-to-top-layer-expected.txt:
Added.
* LayoutTests/fullscreen/fullscreen-add-disconnected-to-top-layer.html:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::addTopLayerElement):
Canonical link: https://commits.webkit.org/273885@main
Canonical link: https://commits.webkit.org/266719.361@webkitglib/2.42
Commit: 301a10b47ee34fc3f75bdd2256c02284cb9f314a
https://github.com/WebKit/WebKit/commit/301a10b47ee34fc3f75bdd2256c02284cb9f314a
Author: Alex Christensen <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 273989@main (439730f0a148).
https://bugs.webkit.org/show_bug.cgi?id=268603
Document::isFullyActive should return true for root frames in addition to
main frames
https://bugs.webkit.org/show_bug.cgi?id=268603
rdar://122164616
Reviewed by Charlie Wolfe.
Before this change XMLHttpRequest::open would always throw an exception if
called from a
cross-site iframe with site isolation enabled. This will probably fix a
lot of behavior.
* LayoutTests/platform/mac-site-isolation/TestExpectations:
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::isFullyActive const):
Canonical link: https://commits.webkit.org/273989@main
Canonical link: https://commits.webkit.org/266719.362@webkitglib/2.42
Commit: bc24a9244e03d4e95081364e114e27d94da47e40
https://github.com/WebKit/WebKit/commit/bc24a9244e03d4e95081364e114e27d94da47e40
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/Modules/cache/DOMCacheStorage.cpp
M Source/WebCore/Modules/cache/DOMCacheStorage.h
Log Message:
-----------
Cherry-pick 274013@main (656c046fbbef).
https://bugs.webkit.org/show_bug.cgi?id=268625
Null check scriptExecutionContext before using it in DOMCacheStorage.cpp
https://bugs.webkit.org/show_bug.cgi?id=268625
rdar://122170377
Reviewed by Sihui Liu, Brent Fulgham and Youenn Fablet.
* Source/WebCore/Modules/cache/DOMCache.cpp:
(WebCore::DOMCache::create):
(WebCore::DOMCache::DOMCache):
* Source/WebCore/Modules/cache/DOMCache.h:
* Source/WebCore/Modules/cache/DOMCacheStorage.cpp:
(WebCore::DOMCacheStorage::findCacheOrCreate):
(WebCore::DOMCacheStorage::doOpen):
Canonical link: https://commits.webkit.org/274013@main
Canonical link: https://commits.webkit.org/266719.363@webkitglib/2.42
Commit: 2ffb54b69bab2e6b55d3eabd9e50121c5b84d783
https://github.com/WebKit/WebKit/commit/2ffb54b69bab2e6b55d3eabd9e50121c5b84d783
Author: Darin Adler <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M LayoutTests/TestExpectations
M Source/WTF/wtf/text/StringImpl.cpp
Log Message:
-----------
Cherry-pick 274036@main (de609ec640c9).
https://bugs.webkit.org/show_bug.cgi?id=237953
Greek uppercase transforms fail for some characters
https://bugs.webkit.org/show_bug.cgi?id=237953
rdar://problem/90364897
Reviewed by Chris Dumez.
Skip the fast path when uppercasing in the "el" locale.
* LayoutTests/TestExpectations: Expect more tests to pass.
* Source/WTF/wtf/text/StringImpl.cpp:
(WTF::needsTurkishCasingRules): Tweaked comment.
(WTF::needsGreekUppercasingRules): Added.
(WTF::StringImpl::convertToUppercaseWithLocale): Don't use fast path when
needsGreekUppercasingRules returns true.
Canonical link: https://commits.webkit.org/274036@main
Canonical link: https://commits.webkit.org/266719.364@webkitglib/2.42
Commit: d74eb4fb3de44e6c68f7461fe6f8d309f3208e3d
https://github.com/WebKit/WebKit/commit/d74eb4fb3de44e6c68f7461fe6f8d309f3208e3d
Author: Darin Adler <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M LayoutTests/TestExpectations
M Source/WTF/wtf/text/StringImpl.cpp
M Source/WebCore/rendering/RenderText.cpp
Log Message:
-----------
Cherry-pick 274073@main (6e67536ebe5b).
https://bugs.webkit.org/show_bug.cgi?id=268705
text-transform test failures due to Lithuanian rules and out-of-flow
characters
https://bugs.webkit.org/show_bug.cgi?id=268705
rdar://122251072
Reviewed by Tim Nguyen.
Changed so Lithuanian won't use the fast path, and so we won't consider out
of line
characters when doing title case.
* LayoutTests/TestExpectations: Expect 3 more tests to pass. Also took off
incorrect bug
numbers. Many tests were marked with a closed bug, which is not what bug
numbers in this
file are supposed to mean.
* Source/WTF/wtf/text/StringImpl.cpp:
(WTF::needsTurkishCasingRules): Tweaked style.
(WTF::needsGreekUppercasingRules): Ditto.
(WTF::needsLithuanianCasingRules): Added.
(WTF::StringImpl::convertToLowercaseWithLocale): Don't use fast path for
Lithuanian.
(WTF::StringImpl::convertToUppercaseWithLocale): Ditto.
* Source/WebCore/rendering/RenderText.cpp:
(WebCore::RenderText::previousCharacter const): Skip renderers that are not
in flow.
Canonical link: https://commits.webkit.org/274073@main
Canonical link: https://commits.webkit.org/266719.365@webkitglib/2.42
Commit: 95ff606462474c30e54242710d6cea9035a46d09
https://github.com/WebKit/WebKit/commit/95ff606462474c30e54242710d6cea9035a46d09
Author: Elad Lahav <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WTF/wtf/posix/OSAllocatorPOSIX.cpp
Log Message:
-----------
Cherry-pick 274171@main (c4f8b92246b4).
https://bugs.webkit.org/show_bug.cgi?id=268713
Detect mmap() failure in OSAllocator::tryReserveUncommittedAligned()
https://bugs.webkit.org/show_bug.cgi?id=268713
Reviewed by Keith Miller
Bail out if tryReserveUncomitted() fails. This avoids a call to
munmap() on a large region that the call never allocated.
* Source/WTF/wtf/posix/OSAllocatorPOSIX.cpp:
(WTF::OSAllocator::tryReserveUncommittedAligned):
Canonical link: https://commits.webkit.org/274171@main
Canonical link: https://commits.webkit.org/266719.366@webkitglib/2.42
Commit: fbff039136a59e47d567eecf1db1e69692e40b10
https://github.com/WebKit/WebKit/commit/fbff039136a59e47d567eecf1db1e69692e40b10
Author: Philippe Normand <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp
M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 274202@main (ca5c43b47399).
https://bugs.webkit.org/show_bug.cgi?id=268541
[GStreamer]
imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audioworklet-interface/audioworkletprocessor-promises.https.html
is flaky crash
https://bugs.webkit.org/show_bug.cgi?id=268541
<rdar://problem/122117396>
Reviewed by Xabier Rodriguez-Calvar.
The crash backtrace suggested the WebAudioSource element was attempting to
use a dangling pointer.
Ideally we should make the AudioDestination a weak pointer in the
WebAudioSource but that breaks
assumptions elsewhere where AudioDestination is used as a RefCounted.
* Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp:
(WebCore::AudioDestinationGStreamer::~AudioDestinationGStreamer):
* Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp:
(webkit_web_audio_src_class_init):
(webKitWebAudioSrcConstructed):
(webKitWebAudioSrcRenderAndPushFrames):
Canonical link: https://commits.webkit.org/274202@main
Canonical link: https://commits.webkit.org/266719.367@webkitglib/2.42
Commit: 70bdb85e436de9f45240bfd2829349b4963adf5c
https://github.com/WebKit/WebKit/commit/70bdb85e436de9f45240bfd2829349b4963adf5c
Author: Keith Miller <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A JSTests/stress/destructuring-class-in-constructor-exception.js
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h
M Source/JavaScriptCore/parser/ASTBuilder.h
M Source/JavaScriptCore/parser/Parser.cpp
M Source/JavaScriptCore/parser/ParserTokens.h
M Source/JavaScriptCore/parser/SyntaxChecker.h
Log Message:
-----------
Cherry-pick 274213@main (5a241c1e2822).
https://bugs.webkit.org/show_bug.cgi?id=268849
Destructuring exception shouldn't crash
https://bugs.webkit.org/show_bug.cgi?id=268849
rdar://121869296
Reviewed by Yusuke Suzuki.
We recently changed how we saved expression info for exceptions, which
saved a bunch of memory.
The new system exposed some places where we were not setting
JSTextPositions properly. This
patch fixes that and adds some asserts that the expression info is
initialized. We also now
return early rather than emit bad expression info if not all parts are
initialized in production.
This means users will see the wrong expression in their stack trace but we
won't crash.
* JSTests/stress/destructuring-class-in-constructor-exception.js: Added.
(try.C0):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitExpressionInfo):
* Source/JavaScriptCore/parser/ASTBuilder.h:
(JSC::ASTBuilder::finishObjectPattern):
(JSC::ASTBuilder::setExceptionLocation):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseForStatement):
* Source/JavaScriptCore/parser/ParserTokens.h:
(JSC::JSTextPosition::operator bool const):
* Source/JavaScriptCore/parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
Canonical link: https://commits.webkit.org/274213@main
Canonical link: https://commits.webkit.org/266719.368@webkitglib/2.42
Commit: e2049d64d194212190b2c9ffd6a4ef57913d926d
https://github.com/WebKit/WebKit/commit/e2049d64d194212190b2c9ffd6a4ef57913d926d
Author: Simon Fraser <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog-expected.txt
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog.html
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-expected.txt
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant-expected.txt
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant.html
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen.html
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover-expected.txt
A
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h
Log Message:
-----------
Cherry-pick 274290@main (1021d66fe7c3).
https://bugs.webkit.org/show_bug.cgi?id=268891
Crash under RenderLayer::calculateClipRects() when going into fullscreen
https://bugs.webkit.org/show_bug.cgi?id=268891
rdar://121960496
Reviewed by Alan Baradlay.
A combination of top layer and compositing backing sharing can cause a null
de-ref when entering fullscreen,
or using modal dialogs or popovers.
The issue occurs when the renderer going into top layer participates in a
backing sharing sequence, in the
`RenderLayer::paintsIntoProvidedBacking()` sense. What happens in that case
is that after the top layer
configuration is changed we do a layout, after which
`RenderLayerBacking::updateAfterLayout()` calls
`RenderLayerBacking::updateCompositedBounds()` (this seems like an odd
thing to do, because we're going
to do a compositing update anyway, but a comment explains why we do it).
This call requires that we compute
clip rects, which calls `RenderLayer::canUseOffsetFromAncestor()`, which
gets confused because the ancestor
layer is no longer an ancestor.
The fix is to clear any relevant backing sharing sequences when going into
top layer, where "relevant" means
backing sharing sequences in the stacking context of the layer that's going
into top layer. We do that
by calling into RenderLayerCompositor from
`RenderLayer::establishesTopLayerWillChange()`. Normally traversing
layers in a stacking context would walk the z-order lists, and this works
for popover and dialog, but fullscreen
triggers a style update before this code runs, which clears the z-order
lists. So this stacking context
traversal is written in terms of the RenderLayer tree (like
`collectLayers()`).
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog-expected.txt:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-dialog.html:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-expected.txt:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant-expected.txt:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen-variant.html:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-fullscreen.html:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover-expected.txt:
Added.
*
LayoutTests/compositing/shared-backing/top-layer/backing-sharing-split-by-popover.html:
Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::establishesTopLayerWillChange):
(WebCore::RenderLayer::calculateClipRects const):
(WebCore::outputPaintOrderTreeLegend):
(WebCore::outputPaintOrderTreeRecursive):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::establishesTopLayerWillChangeForLayer):
(WebCore::clearBackingSharingWithinStackingContext):
(WebCore::RenderLayerCompositor::clearBackingProviderSequencesInStackingContextOfLayer):
* Source/WebCore/rendering/RenderLayerCompositor.h:
Canonical link: https://commits.webkit.org/274290@main
Canonical link: https://commits.webkit.org/266719.369@webkitglib/2.42
Commit: 3314d2d8eb17ddc8a2c5487f112c5ebefa4ea49a
https://github.com/WebKit/WebKit/commit/3314d2d8eb17ddc8a2c5487f112c5ebefa4ea49a
Author: Vivienne Watermeier <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp
Log Message:
-----------
Cherry-pick 274464@main (41a2e3c52030).
https://bugs.webkit.org/show_bug.cgi?id=268559
[GStreamer] Include MpegAudioParse plugin in Brcm Nexus gstreamer pipeline
https://bugs.webkit.org/show_bug.cgi?id=268559
Reviewed by Xabier Rodriguez-Calvar.
On broadcom/nexus with progressive audio, gst_element_query_duration()
returns wrong values, which is avoided by forcing mpegaudioparse.
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1213
Original author: suresh-khurdiya-epam
<[email protected]>
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::ensureGStreamerInitialized): Override mpegaudioparse rank
Canonical link: https://commits.webkit.org/274464@main
Canonical link: https://commits.webkit.org/266719.370@webkitglib/2.42
Commit: e620daf8eb8e1780788f29c99848ff3f019047ea
https://github.com/WebKit/WebKit/commit/e620daf8eb8e1780788f29c99848ff3f019047ea
Author: Dana Estra <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/html/track/VTTCue.cpp
Log Message:
-----------
Cherry-pick 274480@main (379505f1665c).
https://bugs.webkit.org/show_bug.cgi?id=269085
Subtitle size is enlarged in Full screen
https://bugs.webkit.org/show_bug.cgi?id=269085
rdar://122584350
Reviewed by Jer Noble.
Webkit-media-text-track-display pseudo-elements should have a font size
unit of CQMIN instead of CQH. CQMIN will be calculated to be CQW if the width
of the video element is shorter than the height, or CQH vice versa. This
creates a more appropriate font size.
* Source/WebCore/html/track/VTTCue.cpp:
(WebCore::VTTCueBox::applyCSSProperties):
Canonical link: https://commits.webkit.org/274480@main
Canonical link: https://commits.webkit.org/266719.371@webkitglib/2.42
Commit: 724a0deadd386ec47efc9016953a7fab09033a52
https://github.com/WebKit/WebKit/commit/724a0deadd386ec47efc9016953a7fab09033a52
Author: Sihui Liu <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick 274575@main (31136601a244).
https://bugs.webkit.org/show_bug.cgi?id=269308
Null pointer dereference in elementHasClassInClosestAncestors
https://bugs.webkit.org/show_bug.cgi?id=269308
rdar://122892811
Reviewed by Brent Fulgham.
Ensure ancestor is non-null before accessing it.
* Source/WebCore/page/Quirks.cpp:
(WebCore::elementHasClassInClosestAncestors):
Canonical link: https://commits.webkit.org/274575@main
Canonical link: https://commits.webkit.org/266719.372@webkitglib/2.42
Commit: 18e8f9b5e1bddb1c24b570374aef3fe6e34001cd
https://github.com/WebKit/WebKit/commit/18e8f9b5e1bddb1c24b570374aef3fe6e34001cd
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Cherry-pick 274641@main (c3b754f8cd59).
https://bugs.webkit.org/show_bug.cgi?id=269373
Crash under WebPage::close()
https://bugs.webkit.org/show_bug.cgi?id=269373
rdar://118486861
Reviewed by Brent Fulgham.
Add a null check for the LocalFrame given that nothing prevents it
from being null and we're seeing null dereferences in the wild.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close):
Canonical link: https://commits.webkit.org/274641@main
Canonical link: https://commits.webkit.org/266719.373@webkitglib/2.42
Commit: 63709f564b7cf38cf44950a65c5fd30d7b4c240e
https://github.com/WebKit/WebKit/commit/63709f564b7cf38cf44950a65c5fd30d7b4c240e
Author: Vitaly Dyachkov <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.cpp
M Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.h
M Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp
M
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp
M
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.h
Log Message:
-----------
Cherry-pick 275168@main (9f21b9e439f9).
https://bugs.webkit.org/show_bug.cgi?id=269288
[Nicosia] Add support for translate/rotate/scale animations
https://bugs.webkit.org/show_bug.cgi?id=269288
Reviewed by Nikolas Zimmermann.
Nicosia already supports accelerated transform animations.
This patch implements translate, rotate, and scale animations.
It also ensures that when multiple animations are applied,
they run in the correct order required the spec [1]:
- translate
- rotate
- scale
- transform
[1] https://drafts.csswg.org/css-transforms-2/#ctm
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.cpp:
(Nicosia::Animation::apply):
(Nicosia::Animation::applyInternal):
(Nicosia::Animations::apply):
(Nicosia::Animations::hasRunningTransformAnimations const):
(Nicosia::Animation::applyKeepingInternalState): Deleted.
(Nicosia::Animations::applyKeepingInternalState): Deleted.
* Source/WebCore/platform/graphics/nicosia/NicosiaAnimation.h:
(Nicosia::Animations::setTranslate):
(Nicosia::Animations::setRotate):
(Nicosia::Animations::setScale):
(Nicosia::Animations::setTransform):
* Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:
(WebCore::TextureMapperLayer::syncAnimations):
*
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::didChangeAnimations):
(WebCore::CoordinatedGraphicsLayer::addAnimation):
(WebCore::CoordinatedGraphicsLayer::transformRelatedPropertyDidChange):
*
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.h:
Canonical link: https://commits.webkit.org/275168@main
Canonical link: https://commits.webkit.org/266719.374@webkitglib/2.42
Commit: cdd65d7ff6b61e26e0177d09f469f45f73372720
https://github.com/WebKit/WebKit/commit/cdd65d7ff6b61e26e0177d09f469f45f73372720
Author: Mark Lam <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/Scripts/process-entitlements.sh
M Source/JavaScriptCore/jit/ExecutableAllocator.cpp
M Source/WebKit/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick 272448.472@safari-7618-branch (7fdb5ce499c7).
https://bugs.webkit.org/show_bug.cgi?id=267886
Clean up some JSC entitlements.
https://bugs.webkit.org/show_bug.cgi?id=267886
rdar://121395716
Reviewed by Justin Michaud, Per Arne Vollan, and Alexey Shvaika.
* Source/JavaScriptCore/Scripts/process-entitlements.sh:
* Source/JavaScriptCore/jit/ExecutableAllocator.cpp:
(JSC::isJITEnabled):
(JSC::ExecutableAllocator::disableJIT):
* Source/WebKit/Scripts/process-entitlements.sh:
Canonical link: https://commits.webkit.org/272448.472@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.375@webkitglib/2.42
Commit: 934077a8d9156a9d487437581686d59b69c63e7e
https://github.com/WebKit/WebKit/commit/934077a8d9156a9d487437581686d59b69c63e7e
Author: Jean-Yves Avenard <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 272448.473@safari-7618-branch (00b3f3ccf06e).
https://bugs.webkit.org/show_bug.cgi?id=268731
Block "setMediaOverridesForTesting" media IPC endpoints when not testing
and instead reset values
https://bugs.webkit.org/show_bug.cgi?id=268731
rdar://122218365
Reviewed by Youenn Fablet.
The fix in https://commits.webkit.org/272448.445@safari-7618-branch was
insufficient as
the setMediaOverridesForTesting IPC endpoints is also used to reset the
flags to their default.
So rather than disabling the IPC endpoints altogether we restrict its use
to only reset
the default values (which are all unset).
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp:
(WebKit::GPUConnectionToWebProcess::setMediaOverridesForTesting):
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.messages.in:
Canonical link: https://commits.webkit.org/272448.473@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.376@webkitglib/2.42
Commit: 4a6a7c5d2195d675180593f21eb0e569264d8c34
https://github.com/WebKit/WebKit/commit/4a6a7c5d2195d675180593f21eb0e569264d8c34
Author: Mark Lam <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/Scripts/process-entitlements.sh
M Source/WebKit/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick 272448.494@safari-7618-branch (0ebcda9ff537).
https://bugs.webkit.org/show_bug.cgi?id=268792
Refine application of new JIT entitlement for build fix.
https://bugs.webkit.org/show_bug.cgi?id=268792
rdar://122352736
Reviewed by Tim Horton.
* Source/JavaScriptCore/Scripts/process-entitlements.sh:
* Source/WebKit/Scripts/process-entitlements.sh:
Canonical link: https://commits.webkit.org/272448.494@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.377@webkitglib/2.42
Commit: d83eab5a0c0e1f103235871450325d9cb7110884
https://github.com/WebKit/WebKit/commit/d83eab5a0c0e1f103235871450325d9cb7110884
Author: Matthew Finkel <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt
A LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html
M Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp
Log Message:
-----------
Cherry-pick 272448.2@safari-7618-branch (18fd76f8a016).
https://bugs.webkit.org/show_bug.cgi?id=266703
Ensure Filesystem root path is not empty
https://bugs.webkit.org/show_bug.cgi?id=266703
rdar://119813501
Reviewed by Chris Dumez.
When the root path is empty, then the file's name can define an arbitrary
filesystem path. This change ensures that the path is non-empty, therefore
the
virtual filesystem must be defined under a directory that the user selected.
*
LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt:
Added.
* LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html:
Added.
* Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp:
(WebCore::DOMFileSystem::getEntry):
(WebCore::DOMFileSystem::getFile):
Canonical link: https://commits.webkit.org/272448.2@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.378@webkitglib/2.42
Commit: b88b266d7c604587800373a3ccb4bc6941618a44
https://github.com/WebKit/WebKit/commit/b88b266d7c604587800373a3ccb4bc6941618a44
Author: Jonathan Bedard <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
R JSTests/stress/arrow-function-captured-arguments-aliased.js
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
M Source/JavaScriptCore/runtime/GetPutInfo.h
M Source/JavaScriptCore/runtime/ScopedArguments.h
M Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp
M Source/JavaScriptCore/runtime/ScopedArgumentsTable.h
M Source/JavaScriptCore/runtime/SymbolTable.cpp
M Source/JavaScriptCore/runtime/SymbolTable.h
Log Message:
-----------
Cherry-pick 272387@main (84589d65a760).
https://bugs.webkit.org/show_bug.cgi?id=266720
Unreviewed, reverting 272253@main
https://bugs.webkit.org/show_bug.cgi?id=266720
rdar://119946693
Causes stability critical crashes
Reverted change:
Scoped Arguements needs to alias between named and unnamed accesses and
across nested scopes
rdar://119594814
https://bugs.webkit.org/show_bug.cgi?id=261934
rdar://114925088
https://commits.webkit.org/272253@main
Canonical link: https://commits.webkit.org/272387@main
Canonical link: https://commits.webkit.org/266719.379@webkitglib/2.42
Commit: 45919f57923d789631a32d8e5bf957f6e7a7465a
https://github.com/WebKit/WebKit/commit/45919f57923d789631a32d8e5bf957f6e7a7465a
Author: Michael Saboff <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A JSTests/stress/arrow-function-captured-arguments-aliased.js
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
M Source/JavaScriptCore/runtime/GetPutInfo.h
M Source/JavaScriptCore/runtime/ScopedArguments.cpp
M Source/JavaScriptCore/runtime/ScopedArguments.h
M Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp
M Source/JavaScriptCore/runtime/ScopedArgumentsTable.h
M Source/JavaScriptCore/runtime/SymbolTable.h
Log Message:
-----------
Cherry-pick 272448.5@safari-7618-branch (97894699773c).
https://bugs.webkit.org/show_bug.cgi?id=261934
Scoped Arguments needs to alias between named and unnamed accesses and
across nested scopes
https://bugs.webkit.org/show_bug.cgi?id=261934
rdar://114925088
rdar://117838992
Reviewed by Yusuke Suzuki.
Fixed issue where an access to a named argument and a seperate access via
its argument[i] counterpart weren't recognized throughout
all JIT tiers as accesses to the same scoped value. The DFG bytecode
parser can unknowingly constant fold the read access.
Added aliasing via the SymbolTable and its ScopedArgumentsTable for both
types of accesses of such values.
related objects
Added watchpoints for scoped arguments, and shared the watchpoint from the
SymbolTableEntry for the named parameter with the
ScopedArgument entry for the matching index. Tagged op_put_to_scope
bytecodes with a new ScopedArgumentInitialization
initialization type in GetPutInfo to signify this shared watchpoint case.
Since currently all tiers write to scoped arguments
via ScopedArguments::setIndexQuickly(), that is where we fire its
watchpoint.
Added a new test.
* JSTests/stress/arrow-function-captured-arguments-aliased.js: Added.
(createOptAll):
(createOpt500):
(createOpt2000):
(createOpt5000):
(main):
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm:
* Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:
* Source/JavaScriptCore/runtime/GetPutInfo.h:
(JSC::initializationModeName):
(JSC::isInitialization):
* Source/JavaScriptCore/runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::unmapArgument):
* Source/JavaScriptCore/runtime/ScopedArguments.h:
* Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp:
(JSC::ScopedArgumentsTable::tryCreate):
(JSC::ScopedArgumentsTable::tryClone):
(JSC::ScopedArgumentsTable::trySetLength):
(JSC::ScopedArgumentsTable::trySetWatchpointSet):
* Source/JavaScriptCore/runtime/ScopedArgumentsTable.h:
* Source/JavaScriptCore/runtime/SymbolTable.cpp:
(JSC::SymbolTable::cloneScopePart):
* Source/JavaScriptCore/runtime/SymbolTable.h:
Canonical link: https://commits.webkit.org/272448.5@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.380@webkitglib/2.42
Commit: d0583948fd719b2090d161288ed7b6354d4e05b9
https://github.com/WebKit/WebKit/commit/d0583948fd719b2090d161288ed7b6354d4e05b9
Author: Yusuke Suzuki <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A JSTests/stress/attribute-custom-accessor.js
M Source/JavaScriptCore/bytecode/PropertyCondition.cpp
Log Message:
-----------
Cherry-pick 272448.6@safari-7618-branch (24d1c08b9dfa).
https://bugs.webkit.org/show_bug.cgi?id=266695
[JSC] PropertyCondition::isValidValueForAttributes should handle custom
accessor and custom value
https://bugs.webkit.org/show_bug.cgi?id=266695
rdar://119854137
Reviewed by Mark Lam.
PropertyCondition::isValidValueForAttributes only handled accessors and
values. And it
didn't handle custom accessor / custom values. This patch changes it so
that we can
check custom accessor / custom value cases correctly.
* JSTests/stress/attribute-custom-accessor.js: Added.
(async asyncSleep):
(setHasBeenDictionary):
(watchToJSONForReplacements):
(async watchLastMatchForReplacements.getLastMatch):
(async watchLastMatchForReplacements):
(const.target.toJSON):
(opt):
(async main):
* Source/JavaScriptCore/bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isValidValueForAttributes):
Canonical link: https://commits.webkit.org/272448.6@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.381@webkitglib/2.42
Commit: 2134a7c198bf74aa554e8bdcf83dc33556bf8d63
https://github.com/WebKit/WebKit/commit/2134a7c198bf74aa554e8bdcf83dc33556bf8d63
Author: Youenn Fablet <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp8/encoder/encodeframe.c
Log Message:
-----------
Cherry-pick 272448.9@safari-7618-branch (965fd49504ed).
https://bugs.webkit.org/show_bug.cgi?id=266695
Potential 'overflow' issue commited to upstream libwebrtc
rdar://119595026
Reviewed by Jean-Yves Avenard.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/193b1511956f1732a8d54041a26ca9633a92abf9
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/encode_api_test.cc:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp8/encoder/encodeframe.c:
(encode_mb_row):
Canonical link: https://commits.webkit.org/272448.9@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.382@webkitglib/2.42
Commit: 3dce211c2d4f457e700711da289a01de24f16e5d
https://github.com/WebKit/WebKit/commit/3dce211c2d4f457e700711da289a01de24f16e5d
Author: Youenn Fablet <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M
LayoutTests/http/tests/blink/sendbeacon/beacon-cross-origin.https-expected.txt
M
LayoutTests/http/tests/navigation/ping-attribute/anchor-cross-origin-from-https-expected.txt
M
LayoutTests/http/tests/navigation/ping-attribute/anchor-cross-origin-from-https.html
M
LayoutTests/http/tests/navigation/ping-attribute/area-cross-origin-from-https-expected.txt
M
LayoutTests/http/tests/navigation/ping-attribute/area-cross-origin-from-https.html
M
LayoutTests/http/tests/navigation/ping-attribute/resources/secure-anchor-cross-origin.html
M
LayoutTests/http/tests/navigation/ping-attribute/secure-anchor-cross-origin-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-beacon-in-iframe-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-beacon-in-iframe.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-iframe-expected.txt
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-main-frame-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe.https-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe.https.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-iframe-expected.txt
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-main-frame-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-beacon.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-css.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-iframe.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-image.html
A
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-ping.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-plugin.html
M
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-script.html
M
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.http-rp/opt-in/beacon.https-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/opt-in/beacon.https-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/unset/beacon.https-expected.txt
R
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.http-rp/opt-in/beacon.https-expected.txt
R
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/opt-in/beacon.https-expected.txt
R
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/unset/beacon.https-expected.txt
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-iframe-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-main-frame-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-main-frame-expected.txt
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
Log Message:
-----------
Cherry-pick 272448.10@safari-7618-branch (b856378e0a55). rdar://116054889
Plaintext Ping requests not blocked by mixed-content checks (262117)
rdar://116054889
Reviewed by Alex Christensen.
Enforce mixed content checks for beacons and poings, like we do for regular
xhr/fetch.
This aligns the behavior with Chrome and Firefox.
We have to change some tests so that preloads kick in deterministically.
Preloads might not kick in if an early JS resource is already in the cache.
We therefore clear the memory cache to ensure
dump-securitypolicyviolation-and-notify-done.js gets fetched again, which will
trigger both preload and resource load.
Otherwise, we will get only one CONSOLE MESSAGE for the actual blocked load.
We also have to change some tests so that they use HTTPS and not HTTP.
*
LayoutTests/http/tests/blink/sendbeacon/beacon-cross-origin.https-expected.txt:
*
LayoutTests/http/tests/navigation/ping-attribute/anchor-cross-origin-from-https-expected.txt:
*
LayoutTests/http/tests/navigation/ping-attribute/anchor-cross-origin-from-https.html:
*
LayoutTests/http/tests/navigation/ping-attribute/area-cross-origin-from-https-expected.txt:
*
LayoutTests/http/tests/navigation/ping-attribute/area-cross-origin-from-https.html:
*
LayoutTests/http/tests/navigation/ping-attribute/resources/secure-anchor-cross-origin.html:
*
LayoutTests/http/tests/navigation/ping-attribute/secure-anchor-cross-origin-expected.txt:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-beacon-in-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-beacon-in-iframe.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-iframe-expected.txt:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-main-frame-expected.txt:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe.https-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-ping-in-iframe.https.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-iframe-expected.txt:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-main-frame-expected.txt:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-beacon.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-css.html:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-iframe.html:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-image.html:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-ping.html:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-plugin.html:
*
LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/resources/frame-with-insecure-script.html:
*
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.http-rp/opt-in/beacon.https-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/opt-in/beacon.https-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/unset/beacon.https-expected.txt:
*
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.http-rp/opt-in/beacon.https-expected.txt:
Removed.
*
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/opt-in/beacon.https-expected.txt:
Removed.
*
LayoutTests/platform/glib/imported/w3c/web-platform-tests/mixed-content/gen/top.meta/unset/beacon.https-expected.txt:
Removed.
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk1/TestExpectations:
*
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-iframe-expected.txt:
*
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-image-in-main-frame-expected.txt:
*
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-script-in-main-frame-expected.txt:
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::checkInsecureContent const):
Canonical link: https://commits.webkit.org/272448.10@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.383@webkitglib/2.42
Commit: fbc7530490e447c1d4c2c26c1c57b63838ce9762
https://github.com/WebKit/WebKit/commit/fbc7530490e447c1d4c2c26c1c57b63838ce9762
Author: Justin Michaud <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick 8179ae2db1bf. <bug>
Clean up JSC shell entitlements to fix RAMificaton.
rdar://122826926
Reviewed by Yusuke Suzuki.
In https://commits.webkit.org/272448.472@safari-7618-branch, we switched
to the new allow-jit entitlement. This broke RAMiciation runs because
the JSC binary doesn't have the
com.apple.developer.web-browser-engine.webcontent
entitlement. This patch adds it.
* Source/JavaScriptCore/Scripts/process-entitlements.sh:
Canonical link: https://commits.webkit.org/272448.538@safari-7618-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/266719.384@webkitglib/2.42
Commit: 0f07532333bba638d827f2dfac0b6a187cab1d94
https://github.com/WebKit/WebKit/commit/0f07532333bba638d827f2dfac0b6a187cab1d94
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https-expected.html
A
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https.html
A
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https.html.headers
A
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https-expected.html
A
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https.html
A
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https.html.headers
A LayoutTests/http/wpt/content-security-policy/resources/dummy.js
M Source/WebCore/html/parser/HTMLConstructionSite.cpp
Log Message:
-----------
Cherry-pick 272448.25@safari-7618-branch (d43f7eafe9c4).
https://bugs.webkit.org/show_bug.cgi?id=267241
Bug in the HTML parser makes it possible to bypass `nonce` attribute hiding
https://bugs.webkit.org/show_bug.cgi?id=267241
rdar://120056084
Reviewed by Ryosuke Niwa.
Per the HTML specification [1], the `nonce` attribute is supposed to get
hidden by
the user agent once the element gets connected to the document. This means
that we
remove the `nonce` attribute and store its value in an internal field.
The intention is that elements only expose their nonce via their `nonce`
property
to scripts, and not to side-channels like CSS attribute selectors.
The HTML specification [2] also says that when encountering a duplicate
<body> or
<html> tag, we should merge the attributes from the duplicate element to
the original
once. When this happened, we could move the `nonce` attribute from a
duplicate <body>
/ <html> to the original element and it would not get hidden since the
original element
is already connected to the document.
To address the issue, we now add special handling for the `nonce` attribute
upon merging:
1. We discard the duplicate element's `nonce` attribute if the original
element [[nonce]]
internal field is already set (meaning the element already has a nonce).
2. If the original element doesn't have a `nonce` we do merge the attribute
and then call
the logic to hide the `nonce` right away.
[1]
https://html.spec.whatwg.org/multipage/urls-and-fetching.html#nonce-attributes:include-2
[2] https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody
*
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https-expected.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/duplicate-body-hide-nonce-attribute.https.html.headers:
Added.
*
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https-expected.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/duplicate-html-hide-nonce-attribute.https.html.headers:
Added.
* LayoutTests/http/wpt/content-security-policy/resources/dummy.js: Added.
Add test coverage.
* Source/WebCore/html/parser/HTMLConstructionSite.cpp:
(WebCore::HTMLConstructionSite::mergeAttributesFromTokenIntoElement):
Canonical link: https://commits.webkit.org/272448.25@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.385@webkitglib/2.42
Commit: 55b95e47aed7628e4ca5cc25e8cb33e912c248fb
https://github.com/WebKit/WebKit/commit/55b95e47aed7628e4ca5cc25e8cb33e912c248fb
Author: Yijia Huang <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 272448.74@safari-7618-branch (7bd07231e704).
https://bugs.webkit.org/show_bug.cgi?id=267036
Should crash when deserializing JSArray object containing named property
length
https://bugs.webkit.org/show_bug.cgi?id=267036
rdar://120410983
Reviewed by Sihui Liu and Mark Lam.
`length` is treated as a special property in JSArray. There shouldn't
be any named property `length` in JSArray. So, should crash when
deserializing JSArray object containing named property `length`.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::serialize):
(WebCore::CloneDeserializer::objectStartVisitMember):
(WebCore::CloneDeserializer::objectEndVisitMember):
(WebCore::CloneDeserializer::deserialize):
Canonical link: https://commits.webkit.org/272448.74@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.386@webkitglib/2.42
Commit: 19c0dd3511d363607010db6f0fbcbe039aea0979
https://github.com/WebKit/WebKit/commit/19c0dd3511d363607010db6f0fbcbe039aea0979
Author: Erica Li <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/fast/inline/sticky-inline-box-invalidation-repaint-crash-expected.txt
A LayoutTests/fast/inline/sticky-inline-box-invalidation-repaint-crash.html
M
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt
M Source/WebCore/rendering/RenderInline.cpp
Log Message:
-----------
Cherry-pick 272448.75@safari-7618-branch (2534e02e1983).
https://bugs.webkit.org/show_bug.cgi?id=266567.
ASAN_SEGV | Hard null deref
|LayoutIntegration::BoxTree::layoutBoxForRenderer;
LayoutIntegration::LineLayout::enclosingBorderBoxRectFor;
WebCore::RenderInline::linesBoundingBox.
https://bugs.webkit.org/show_bug.cgi?id=266567.
rdar://114586645.
Reviewed by Alan Baradlay.
similar to 107979394, apply handling for repainting a freshly inserted
sticky inline box.
*
LayoutTests/fast/inline/sticky-inline-box-invalidation-repaint-crash-expected.txt:
Added.
*
LayoutTests/fast/inline/sticky-inline-box-invalidation-repaint-crash.html:
Added.
*
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt:
re-baseline for rdar://119187070.
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::linesBoundingBox const):
Canonical link: https://commits.webkit.org/272448.75@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.387@webkitglib/2.42
Commit: 0cc7e52c23d26f101da9b80374b800521bcc3971
https://github.com/WebKit/WebKit/commit/0cc7e52c23d26f101da9b80374b800521bcc3971
Author: Myah Cobbs <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
M Source/WebCore/bindings/js/SerializedScriptValue.h
Log Message:
-----------
Cherry-pick c3c2a42ade13. https://bugs.webkit.org/show_bug.cgi?id=266806
Safari's IndexedDB data may not be deserialized correctly after system
upgrades
https://bugs.webkit.org/show_bug.cgi?id=266806
rdar://120031024
Reviewed by NOBODY (OOPS!).
To fix rdar://119834827, we introduce version 12.1 to SerializeScriptValue,
which changed the terminator of the indexed
property section in array compared to version 12. To make sure deserializer
knows to deserialize version 12.1, we encode
the minor version in the highest 8 bits of version number. We keep the
lowest 24 bit as major version number for
backward compatibility (the previously stored 32-bit major version number
can be intepreted as major version with minor
version 0).
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::majorVersionFor):
(WebCore::minorVersionFor):
(WebCore::makeVersion):
(WebCore::currentVersion):
(WebCore::CloneSerializer::serialize):
(WebCore::CloneSerializer::CloneSerializer):
(WebCore::CloneDeserializer::deserializeString):
(WebCore::CloneDeserializer::deserialize):
(WebCore::CloneDeserializer::isValid const):
(WebCore::CloneDeserializer::shouldRetryWithVersionUpgrade):
(WebCore::CloneDeserializer::upgradeVersion):
(WebCore::CloneDeserializer::read):
(WebCore::CloneDeserializer::readFile):
(WebCore::CloneDeserializer::readArrayBuffer):
(WebCore::CloneDeserializer::readArrayBufferView):
(WebCore::CloneDeserializer::readImageBitmap):
(WebCore::CloneDeserializer::readTerminal):
(WebCore::CloneDeserializer::version const): Deleted.
(WebCore::SerializedScriptValue::wireFormatVersion): Deleted.
* Source/WebCore/bindings/js/SerializedScriptValue.h:
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 270272.2255@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.388@webkitglib/2.42
Commit: f6b9e4a039968158c05d83f5d23381c6ddd11842
https://github.com/WebKit/WebKit/commit/f6b9e4a039968158c05d83f5d23381c6ddd11842
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServerToContextConnection.cpp
M Source/WebCore/workers/service/server/SWServerWorker.cpp
M Source/WebCore/workers/service/server/SWServerWorker.h
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorker.cpp
M Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorker.h
M Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServer.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm
Log Message:
-----------
Cherry-pick 272448.87@safari-7618-branch (b70a943d3745).
https://bugs.webkit.org/show_bug.cgi?id=267298
Regression: Third-party service worker processes get killed when trying to
do loads
https://bugs.webkit.org/show_bug.cgi?id=267298
rdar://120587179
Reviewed by Youenn Fablet.
We recently added origin IPC message checks to make sure that WebProcesses
can
only access cookies from specific origins. Due to a bug in our service
worker
code, the network process would allow the wrong origin in the case of
third-party service workers (it would allow the client origin instead of the
top origin). As a result, the network process would kill the third-party
service worker process as soon as it would try to attempt a load. This was
occurring on
https://boingboing.net/2024/01/06/stanley-water-bottle-madness-grips-america.html
for example, with the tiktok.com service worker.
When the network process needs to launch a service worker process, it sends
an
EstablishRemoteWorkerContextConnectionToNetworkProcess IPC to the UIProcess,
with a given registrable domain. The UIProcess would use this registrable
domain to select a suitable WebProcess or launch one. When launching a new
process, the UIProcess would send an IPC to the network process telling it
this
new WebProcess is allowed to access cookies under the given registrable
domain.
Both from the process selection point of view and from the network process
cookie access point of view, we expect this registrable domain to be the top
origin's registrable domain. As a result, in the example above, the
third-party
tiktok.com service worker under boingboing.net, would be expected to use a
"boingboing.net" WebProcess and only have access to cookies under the
"boingboing.net" first party.
However, our service worker logic was using the registrable domain of the
service worker script URL instead. As a result, we would select a
"tiktok.com"
WebProcess for the service worker process, which was wrong from a site
isolation perspective (since top-level tiktok.com would share the same
process
as tiktok.com under boingboing.net). Also, the network process would allow
access to top-level tiktok.com cookies if the WebProcess requested them,
which
was wrong too.
Later on, the service worker would try to do a load. The network request
would
request use "boingboing.net" as firstParty for cookies, which is correct.
However, the network process would reject such load, since the process is
only
allowed to use "tiktok.com" as first party for cookies. It would then kill
the
service worker process for good measure since it would assume it is
compromised.
To address the issue, we now properly use the registrable domain of the top
level origin when sending the
EstablishRemoteWorkerContextConnectionToNetworkProcess
IPC for and service worker connection selection in general. I updated the
shared
worker code as well to maintain consistency.
Note that in order to write an API test for this, I had to restore the
service
worker from disk first. When the service worker is newly registered by JS,
we
would first tell the network process to allow the wrong client origin.
However,
a later IPC to tell the network process to also allow the top level origin.
As
a result, newly registered third-party service workers would not get
terminated
which is why our tests were passing. Those service worker origins were
allowed
access to cookies they shouldn't have access to though so there was a
security
issue still for them.
When restoring the service worker from disk though, we'd only send a single
IPC
to the network process telling it to allow the original of the service
worker
script URL. This allowed me to write a test and explains the service worker
processes terminations on boingboing.net.
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::addRegistrationFromStore):
(WebCore::SWServer::scheduleJob):
(WebCore::SWServer::tryInstallContextData):
(WebCore::SWServer::runServiceWorkerIfNecessary):
(WebCore::SWServer::markAllWorkersForRegistrableDomainAsTerminated):
(WebCore::SWServer::removeContextConnectionIfPossible):
(WebCore::SWServer::fireFunctionalEvent):
* Source/WebCore/workers/service/server/SWServerToContextConnection.cpp:
(WebCore::SWServerToContextConnection::terminateWhenPossible):
* Source/WebCore/workers/service/server/SWServerWorker.cpp:
(WebCore::m_lastNavigationWasAppInitiated):
(WebCore::SWServerWorker::contextConnection):
(WebCore::SWServerWorker::terminationIfPossibleTimerFired):
* Source/WebCore/workers/service/server/SWServerWorker.h:
(WebCore::SWServerWorker::topRegistrableDomain const):
(WebCore::SWServerWorker::registrableDomain const): Deleted.
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::startFetch):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:
(-[SWMessageHandlerForRestoreFromDiskTest resetExpectedMessage:]):
Canonical link: https://commits.webkit.org/272448.87@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.389@webkitglib/2.42
Commit: a7fbf3859b7e0ae965c7b8324f7d4345308c3cf5
https://github.com/WebKit/WebKit/commit/a7fbf3859b7e0ae965c7b8324f7d4345308c3cf5
Author: Darryl Parkinson <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServer.h
M Source/WebCore/workers/service/server/SWServerJobQueue.cpp
M Source/WebCore/workers/service/server/SWServerToContextConnection.cpp
M Source/WebCore/workers/service/server/SWServerWorker.cpp
M Source/WebCore/workers/service/server/SWServerWorker.h
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp
Log Message:
-----------
Cherry-pick 272448.88@safari-7618-branch (0b48a61e2e17).
https://bugs.webkit.org/show_bug.cgi?id=267412
Resolve lifetime issue of SWServerWorker
https://bugs.webkit.org/show_bug.cgi?id=267412
rdar://119605188
Reviewed by Chris Dumez.
Change the raw pointer of SWServerWorker stored in the allWorkers
HashMap to be a WeakPtr to fix a lifetime issue as it can be accessed
after object lifetime.
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::workerByID const):
(WebCore::SWServer::fireFunctionalEvent):
(WebCore::SWServer::postMessageToServiceWorkerClient):
* Source/WebCore/workers/service/server/SWServer.h:
* Source/WebCore/workers/service/server/SWServerJobQueue.cpp:
(WebCore::SWServerJobQueue::install):
* Source/WebCore/workers/service/server/SWServerRegistration.cpp:
(WebCore::SWServerRegistration::updateRegistrationState):
* Source/WebCore/workers/service/server/SWServerRegistration.h:
* Source/WebCore/workers/service/server/SWServerToContextConnection.cpp:
(WebCore::SWServerToContextConnection::scriptContextFailedToStart):
(WebCore::SWServerToContextConnection::scriptContextStarted):
(WebCore::SWServerToContextConnection::didFinishInstall):
(WebCore::SWServerToContextConnection::didFinishActivation):
(WebCore::SWServerToContextConnection::setServiceWorkerHasPendingEvents):
(WebCore::SWServerToContextConnection::workerTerminated):
(WebCore::SWServerToContextConnection::matchAll):
(WebCore::SWServerToContextConnection::findClientByVisibleIdentifier):
(WebCore::SWServerToContextConnection::claim):
(WebCore::SWServerToContextConnection::setScriptResource):
(WebCore::SWServerToContextConnection::didFailHeartBeatCheck):
(WebCore::SWServerToContextConnection::setAsInspected):
* Source/WebCore/workers/service/server/SWServerWorker.cpp:
(WebCore::SWServerWorker::allWorkers):
(WebCore::SWServerWorker::existingWorkerForIdentifier):
(): Deleted.
* Source/WebCore/workers/service/server/SWServerWorker.h:
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::postMessageToServiceWorker):
*
Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp:
(WebKit::WebSWServerToContextConnection::skipWaiting):
Canonical link: https://commits.webkit.org/272448.88@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.390@webkitglib/2.42
Commit: f06f4235db5a312f4c20e51c294ba97913c6c43a
https://github.com/WebKit/WebKit/commit/f06f4235db5a312f4c20e51c294ba97913c6c43a
Author: Alan Baradlay <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/fast/dynamic/move-inline-level-element-between-blocks-crash-expected.txt
A
LayoutTests/fast/dynamic/move-inline-level-element-between-blocks-crash.html
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.h
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick 272448.98@safari-7618-branch (77a82bb2bcde).
https://bugs.webkit.org/show_bug.cgi?id=267141
Do not repaint newly moved inline box
https://bugs.webkit.org/show_bug.cgi?id=267141
rdar://120555470
Reviewed by Antti Koivisto.
1. Repaint needs uptodate geometry information to compute the damaged area
2. Whenever we invalidate the line layout path, we lose all geometry
information so a full repaint is being issued on the very first invalidation.
(note that there may be multiple mutations happening the same time)
This patch ensures that such repaints are _not_ issued on newly inserted
content.
Since we don't keep track of whether a particular renderer has already
issued repaint, moving renders between blocks could
potentially be repainted twice; initially when they get detached and later
when they get inserted at their new position.
Repaint issued at this later stage most likely results in incorrectly
computed damage area as all relevant geometries are
relative to the former block -and in some cases it may even trigger crashes
as we don't find associated layout/display boxes in
the new block.
*
LayoutTests/fast/dynamic/move-inline-level-element-between-blocks-crash-expected.txt:
Added.
*
LayoutTests/fast/dynamic/move-inline-level-element-between-blocks-crash.html:
Added.
* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp:
(WebCore::LayoutIntegration::BoxTree::contains const):
* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.h:
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::contains const):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h:
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::invalidateLineLayoutPath):
Canonical link: https://commits.webkit.org/272448.98@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.391@webkitglib/2.42
Commit: 36fc4ede983eee626cd04a1523ad9f3986e6c776
https://github.com/WebKit/WebKit/commit/36fc4ede983eee626cd04a1523ad9f3986e6c776
Author: Ryan Reno <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part.py
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part.py
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/DocumentLoader.h
Log Message:
-----------
Cherry-pick 272448.100@safari-7618-branch (7f3ac60a98fc).
https://bugs.webkit.org/show_bug.cgi?id=264811
Content-Type x-mixed-replace can be abused to bypass CSP
https://bugs.webkit.org/show_bug.cgi?id=264811
rdar://118394343
Reviewed by John Wilander and Brent Fulgham.
When replacing the document in a multipart/x-mixed-replace response, the
DocumentLoader would reset its CSP every time a new response was received.
This change makes the CSP persistent across document replacements when
loading multipart content. Now the CSP can only become more restrictive
as new parts are received.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part.py:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part.py:
Added.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::shouldClearContentSecurityPolicyForResponse
const):
(WebCore::DocumentLoader::responseReceived):
* Source/WebCore/loader/DocumentLoader.h:
Canonical link: https://commits.webkit.org/272448.100@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.392@webkitglib/2.42
Commit: 3036344added9ec5b96d8f9ef61deb094cff87d5
https://github.com/WebKit/WebKit/commit/3036344added9ec5b96d8f9ef61deb094cff87d5
Author: Yijia Huang <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/runtime/CommonSlowPaths.h
M Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp
M Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp
M Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp
M Source/JavaScriptCore/runtime/JSFunction.cpp
M Source/JavaScriptCore/runtime/JSFunction.h
M Source/JavaScriptCore/runtime/JSFunctionInlines.h
Log Message:
-----------
Cherry-pick 272448.101@safari-7618-branch (70ca9c1f54a0).
https://bugs.webkit.org/show_bug.cgi?id=267380
[JSC] setHasModifiedLengthForBoundOrNonHostFunction and
setHasModifiedNameForBoundOrNonHostFunction shouldn't be called if it fails to
reify the property
https://bugs.webkit.org/show_bug.cgi?id=267380
rdar://118761737
Reviewed by Yusuke Suzuki.
setHasModifiedLengthForBoundOrNonHostFunction and
setHasModifiedNameForBoundOrNonHostFunction
can be called if JSFunction::put() fails to reify the property. This case
may
cause inconsistency between the AI and the runtime environment.
* Source/JavaScriptCore/runtime/JSFunction.cpp:
(JSC::JSFunction::put):
Canonical link: https://commits.webkit.org/272448.101@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.393@webkitglib/2.42
Commit: 1d0b5edaf35f228431ca8730a89201e000f402be
https://github.com/WebKit/WebKit/commit/1d0b5edaf35f228431ca8730a89201e000f402be
Author: Alexey Shvayka <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A JSTests/stress/regress-120777816.js
M Source/JavaScriptCore/builtins/ProxyHelpers.js
M Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.h
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h
M Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/runtime/ProxyObject.cpp
Log Message:
-----------
Cherry-pick 272448.103@safari-7618-branch (e3a75800fe85).
https://bugs.webkit.org/show_bug.cgi?id=267425
[JSC] get_by_id_with_this + ProxyObject can leak JSScope objects
https://bugs.webkit.org/show_bug.cgi?id=267425
<rdar://120777816>
Reviewed by Yusuke Suzuki and Justin Michaud.
According to the spec [1], `var base = { foo }; with (base) foo();` should
be called with `this`
value of `base`, which is why FunctionCallResolveNode moves resolved scope
to thisRegister().
That is arguably a bad design, and there is an effort [2] to abolish using
JSScope as `this` value.
When `this` value is accessed by JS code, it's being sanitized via ToThis
(JSScope replaced with
`undefined`), yet not in case of `super.property` access calling into
ProxyObject `get` trap,
which passes raw `this` value as receiver parameter, leaking JSScope to be
exploited.
For performance reasons, we can't call toThis() whenever
`get_by_id_with_this` is used, so this
change introduces @toThis() intrinsic specifically for ProxyObject IC
helpers, tweaks DFG to respect
`m_srcDst`, and also fixes baseline code.
Inlineability of ProxyObject IC helpers was verified to remain unaffected
(`performProxyObjectGet`
is smaller then 120 while other helpers were already exceeding inline size
limit).
[1]: https://tc39.es/ecma262/#sec-evaluatecall (step 1.b.iii)
[2]: https://bugs.webkit.org/show_bug.cgi?id=225397
* JSTests/stress/regress-120777816.js: Added.
* Source/JavaScriptCore/builtins/ProxyHelpers.js:
(linkTimeConstant.performProxyObjectGet):
(linkTimeConstant.performProxyObjectGetByVal):
(linkTimeConstant.performProxyObjectSetSloppy):
(linkTimeConstant.performProxyObjectSetStrict):
* Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.h:
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitToThis):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitToThis):
* Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_toThis):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::getThis): Deleted.
(JSC::DFG::ByteCodeParser::setThis): Deleted.
* Source/JavaScriptCore/runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performPut):
Canonical link: https://commits.webkit.org/272448.103@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.394@webkitglib/2.42
Commit: ee130771eb4549d12a921e04fc25eea75c8be165
https://github.com/WebKit/WebKit/commit/ee130771eb4549d12a921e04fc25eea75c8be165
Author: Erica Li <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash-expected.txt
A LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash.html
M
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt
M Source/WebCore/rendering/RenderTable.cpp
Log Message:
-----------
Cherry-pick 272448.104@safari-7618-branch (8737c0374652).
https://bugs.webkit.org/show_bug.cgi?id=267198
ASAN_ILL | WebCore::RenderTableSection::layoutRows;
WebCore::RenderTable::simplifiedNormalFlowLayout;
WebCore::RenderBlock::simplifiedLayout.
https://bugs.webkit.org/show_bug.cgi?id=267198
rdar://113940614
Reviewed by Alan Baradlay.
Always setChildNeedsLayout for sections to make sure normalChildNeedsLayout
is flagged,
as for pagination we need to run a full layout on child table sections even
when the initial change,
otherwise requires simplified layout only.
*
LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash-expected.txt:
Added.
* LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash.html:
Added.
*
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt:
re-baseline again, adding end of line back.
* Source/WebCore/rendering/RenderTable.cpp:
(WebCore::RenderTable::markForPaginationRelayoutIfNeeded):
Canonical link: https://commits.webkit.org/272448.104@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.395@webkitglib/2.42
Commit: 1f3d5afa3e5edb4c0ba2ded0ec049c1f7fde96e4
https://github.com/WebKit/WebKit/commit/1f3d5afa3e5edb4c0ba2ded0ec049c1f7fde96e4
Author: Nisha Jain <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A LayoutTests/dom/html/document-renderobject-null-crash-expected.txt
A LayoutTests/dom/html/document-renderobject-null-crash.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 272448.251@safari-7618-branch (9baf7178103b).
https://bugs.webkit.org/show_bug.cgi?id=267297
"NULL Object : Crash under WebCore::RenderObject::~RenderObject;
WebCore::RenderText::~RenderText; WebCore::RenderTreeBuilder::destroy"
https://bugs.webkit.org/show_bug.cgi?id=267297
rdar://119186861.
Reviewed by Alan Baradlay.
Document::caretPositionFromPoint API is using CheckPtr to get RenderObject
even though the Object is already destroyed. In order to make sure
CheckedPtr
is valid the render needs to be destroyed earlier not after. Using
updateLayoutIgnorePendingStylesheets API for uptodate renderer tree.
* LayoutTests/dom/html/document-renderobject-null-crash-expected.txt: Added
test expected file.
* LayoutTests/dom/html/document-renderobject-null-crash.html: Added test
case.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::caretPositionFromPoint): Added
updateLayoutIgnorePendingStylesheets to get updated renderer tree before using
CheckedPtr.
Canonical link: https://commits.webkit.org/272448.251@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.396@webkitglib/2.42
Commit: bdd71a8c414d917d64845e65d4944afb8d1d8d5e
https://github.com/WebKit/WebKit/commit/bdd71a8c414d917d64845e65d4944afb8d1d8d5e
Author: Nisha Jain <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A LayoutTests/fast/rendering/render-compositor-null-layer-crash-expected.txt
A LayoutTests/fast/rendering/render-compositor-null-layer-crash.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 272448.252@safari-7618-branch (a7977801dff3).
https://bugs.webkit.org/show_bug.cgi?id=265820
NULL pointer : crash under
RenderLayerCompositor::scrollableAreaForScrollingNodeID()
https://bugs.webkit.org/show_bug.cgi?id=265820
rdar://118424482.
Reviewed by Simon Fraser.
Null RenderLayer pointer in
RenderLayerCompositor::scrollableAreaForScrollingNodeID().
As the RenderLayerCompositor has a HashMap which provides a WeakPtr to
RenderLayer but the validity
of this object is not checked before using.
*
LayoutTests/fast/rendering/render-compositor-null-layer-crash-expected.txt:
Added test expected file.
* LayoutTests/fast/rendering/render-compositor-null-layer-crash.html: Added
test case.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::scrollableAreaForScrollingNodeID const):
Checked validity of WeakPtr to RenderLayer before accessing it.
Canonical link: https://commits.webkit.org/272448.252@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.397@webkitglib/2.42
Commit: aca6b63b1c883e7d09f453c486326e471a95bc79
https://github.com/WebKit/WebKit/commit/aca6b63b1c883e7d09f453c486326e471a95bc79
Author: Ryosuke Niwa <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A LayoutTests/fast/images/image-document-event-handler-crash-expected.txt
A LayoutTests/fast/images/image-document-event-handler-crash.html
M Source/WebCore/html/ImageDocument.cpp
Log Message:
-----------
Cherry-pick 272448.253@safari-7618-branch (b417dff04acd).
https://bugs.webkit.org/show_bug.cgi?id=267739
Crash in ImageEventListener::handleEvent
https://bugs.webkit.org/show_bug.cgi?id=267739
rdar://118761846
Reviewed by Chris Dumez.
Use WeakPtr instead of a raw reference.
* LayoutTests/fast/images/image-document-event-handler-crash-expected.txt:
Added.
* LayoutTests/fast/images/image-document-event-handler-crash.html: Added.
* Source/WebCore/html/ImageDocument.cpp:
(WebCore::ImageEventListener::handleEvent):
Canonical link: https://commits.webkit.org/272448.253@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.398@webkitglib/2.42
Commit: aac6fc2589667db5d2c649210a212c64d7029bbf
https://github.com/WebKit/WebKit/commit/aac6fc2589667db5d2c649210a212c64d7029bbf
Author: Yijia Huang <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M JSTests/stress/intl-collator.js
M JSTests/stress/intl-datetimeformat.js
M JSTests/stress/intl-numberformat.js
M Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp
M Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp
M Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp
Log Message:
-----------
Cherry-pick 272448.254@safari-7618-branch (5173338bb6f1).
https://bugs.webkit.org/show_bug.cgi?id=267725
[JSC] Use dynamic cast in intlCollatorFuncCompare,
intlDateTimeFormatFuncFormatDateTime, and intlNumberFormatFuncFormat
https://bugs.webkit.org/show_bug.cgi?id=267725
rdar://121029647
Reviewed by Yusuke Suzuki and Mark Lam.
We should ensure `thisValue` is the desired object. So, should use dynamic
cast instead in intlCollatorFuncCompare,
intlDateTimeFormatFuncFormatDateTime,
and intlNumberFormatFuncFormat.
* Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
Canonical link: https://commits.webkit.org/272448.254@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.399@webkitglib/2.42
Commit: 95929876ea4f97cd92ab0fd2e1cc614643203fd5
https://github.com/WebKit/WebKit/commit/95929876ea4f97cd92ab0fd2e1cc614643203fd5
Author: Nisha Jain <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Cherry-pick 272448.257@safari-7618-branch (23c6a88ad691).
https://bugs.webkit.org/show_bug.cgi?id=267656
"ASAN_SEGV | WebCore::Style::resolveForDocument;
WebCore::Document::styleForElementIgnoringPendingStylesheets;
WebCore::Element::resolveComputedStyle"
https://bugs.webkit.org/show_bug.cgi?id=267656
rdar://119187152.
Reviewed by Ryosuke Niwa.
Need to prevent attempt to load a disconnected plugin.
Not adding a new test case as could not make a reliable reproduction of
this issue.
* Source/WebCore/html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::requestObject):
Canonical link: https://commits.webkit.org/272448.257@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.400@webkitglib/2.42
Commit: a9402dfb9f706d4ea23209205760502e1df7b760
https://github.com/WebKit/WebKit/commit/a9402dfb9f706d4ea23209205760502e1df7b760
Author: Yijia Huang <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A JSTests/stress/error-instance.js
M Source/JavaScriptCore/runtime/ErrorInstance.cpp
Log Message:
-----------
Cherry-pick 272448.260@safari-7618-branch (ade92866440e).
https://bugs.webkit.org/show_bug.cgi?id=267785
[JSC] Fix Re-entrancy in ErrorInstance::computeErrorInfo
https://bugs.webkit.org/show_bug.cgi?id=267785
rdar://121098660
Reviewed by Yusuke Suzuki.
ErrorInstance::computeErrorInfo computes stack trace string, which may
trigger GC and re-enter to this function with the same ErrorInstance
while computing the stack string. We should defer GC after stacking trace
string is materialized.
* JSTests/stress/error-instance.js: Added.
(main.const.error):
(main):
* Source/JavaScriptCore/runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::computeErrorInfo):
Canonical link: https://commits.webkit.org/272448.260@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.401@webkitglib/2.42
Commit: 43cc61f5cc7c6e4acaa4e472e98481fe07f8f4e9
https://github.com/WebKit/WebKit/commit/43cc61f5cc7c6e4acaa4e472e98481fe07f8f4e9
Author: Michael Saboff <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M JSTests/stress/arrow-function-captured-arguments-aliased.js
M Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp
Log Message:
-----------
Cherry-pick 272448.339@safari-7618-branch (66df5c618c1c).
https://bugs.webkit.org/show_bug.cgi?id=267946
ASSERTION FAILED: watchpoints (./runtime/ScopedArgumentsTable.cpp(130))
rdar://121446658
https://bugs.webkit.org/show_bug.cgi?id=267946
Reviewed by Alexey Shvayka.
Insatead of using an ASSERT that we have a valid WatchpointSet in
ScopedArgumentsTable::trySetWatchpointSet(), we can just
exit early if the passed in WatchpointSet is null. This can happen if the
JIT is not enabled.
Updated the test to run both with and wothout the JIT.
* JSTests/stress/arrow-function-captured-arguments-aliased.js:
* Source/JavaScriptCore/runtime/ScopedArgumentsTable.cpp:
(JSC::ScopedArgumentsTable::trySetWatchpointSet):
Canonical link: https://commits.webkit.org/272448.339@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.402@webkitglib/2.42
Commit: d41dedddc64c4778cd12e4c976a3235c32fd9d17
https://github.com/WebKit/WebKit/commit/d41dedddc64c4778cd12e4c976a3235c32fd9d17
Author: Mark Lam <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A
LayoutTests/js/structuredClone/structured-clone-of-CachedString-in-map-expected.txt
A
LayoutTests/js/structuredClone/structured-clone-of-CachedString-in-map.html
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 272448.347@safari-7618-branch (5546b2ee36b5).
https://bugs.webkit.org/show_bug.cgi?id=267971
CachedString::m_jsString is not protected from GC in CloneDeserializer.
https://bugs.webkit.org/show_bug.cgi?id=267971
rdar://120531481
Reviewed by Chris Dumez.
The fix is simply to protect it with the m_keepAliveBuffer. Also moved the
m_keepAliveBuffer from
CloneSerializer to CloneBase. Previously, I thought that only the
serializer needs it. Now, we
have a case where the deserializer does too.
*
LayoutTests/js/structuredClone/structured-clone-of-CachedString-in-map-expected.txt:
Added.
*
LayoutTests/js/structuredClone/structured-clone-of-CachedString-in-map.html:
Added.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::CachedString::jsString):
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/272448.347@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.403@webkitglib/2.42
Commit: 97c9cb71af89c617128606aeef7833e58a2afc9c
https://github.com/WebKit/WebKit/commit/97c9cb71af89c617128606aeef7833e58a2afc9c
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Cherry-pick 272448.355@safari-7618-branch (99b063d917a4).
https://bugs.webkit.org/show_bug.cgi?id=268010
Regression(267815.354@safari-7617-branch) ASSERTION FAILED:
ownerElement.document().frame() in the tests
https://bugs.webkit.org/show_bug.cgi?id=268010
rdar://121528243
Reviewed by Ryosuke Niwa and Geoffrey Garen.
In 267815.354@safari-7617-branch, we updated
HTMLPlugInImageElement::requestObject()
to call SubframeLoader::requestObject() asynchronously. Previously, when we
called
SubframeLoader::requestObject() the frame owner element's document would
still be
connected (i.e. have a frame) and it was enforced by an assertion both in
HTMLPlugInImageElement::requestObject() and SubframeLoader::requestObject().
After my change in 267815.354@safari-7617-branch, the assertion in
SubframeLoader::requestObject() would sometimes fail as this code now runs
asynchronously and the state of the DOM tree may have changed in between.
To address the issue, check if the document still have a frame when the
async
lambda runs and return early if it doesn't. There is no point in loading a
subframe
in a document that was detached.
* Source/WebCore/html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::requestObject):
Canonical link: https://commits.webkit.org/272448.355@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.404@webkitglib/2.42
Commit: f257018988fcb3c5771df8c6359d0af5febafbbd
https://github.com/WebKit/WebKit/commit/f257018988fcb3c5771df8c6359d0af5febafbbd
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/editing/TextManipulationController.cpp
Log Message:
-----------
Cherry-pick 272448.385@safari-7618-branch (2d3dc03ecbbc).
https://bugs.webkit.org/show_bug.cgi?id=268235
Bad cast in TextManipulationController::scheduleObservationUpdate()
https://bugs.webkit.org/show_bug.cgi?id=268235
rdar://121646850
Reviewed by Wenson Hsieh.
Convert the downcast<>() into a dynamicDowncast<>() since the common
ancestor
is not guaranteed to be an Element.
I have not been able to reproduce but it is happening in the wild.
* Source/WebCore/editing/TextManipulationController.cpp:
(WebCore::TextManipulationController::scheduleObservationUpdate):
Canonical link: https://commits.webkit.org/272448.385@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.405@webkitglib/2.42
Commit: ecd593fbc4bdccb83fa45e726cfabdec11867297
https://github.com/WebKit/WebKit/commit/ecd593fbc4bdccb83fa45e726cfabdec11867297
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKProcessPool.mm
M Source/WebKit/UIProcess/API/Cocoa/WKProcessPoolPrivate.h
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp
M
Source/WebKit/WebProcess/Storage/WebSharedWorkerContextManagerConnection.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm
Log Message:
-----------
Cherry-pick 272448.386@safari-7618-branch (dd435ec50671).
https://bugs.webkit.org/show_bug.cgi?id=268183
Remote worker processes may not obey the lockdown mode setting
https://bugs.webkit.org/show_bug.cgi?id=268183
rdar://121617300
Reviewed by Youenn Fablet.
Make sure we carry over the requesting process' lockdown mode state to the
newly created process when we decide to launch a remote worker process.
Also make sure that the settings that are meant to be disabled in lockdown
mode also get disabled in the remote worker contexts, not just in
page/window
contexts.
* Source/WebKit/UIProcess/API/Cocoa/WKProcessPool.mm:
(-[WKProcessPool _isJITDisabledInAllServiceWorkerProcesses:]):
* Source/WebKit/UIProcess/API/Cocoa/WKProcessPoolPrivate.h:
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::establishRemoteWorkerContextConnectionToNetworkProcess):
(WebKit::WebProcessPool::isJITDisabledInAllServiceWorkerProcesses const):
* Source/WebKit/UIProcess/WebProcessPool.h:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::createForRemoteWorkers):
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:
Canonical link: https://commits.webkit.org/272448.386@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.406@webkitglib/2.42
Commit: b7cfc9afccda8e123bdee2e224baed068a8cefbb
https://github.com/WebKit/WebKit/commit/b7cfc9afccda8e123bdee2e224baed068a8cefbb
Author: Erica Li <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
A LayoutTests/media/audio-remove-playback-crash-expected.txt
A LayoutTests/media/audio-remove-playback-crash.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 272448.387@safari-7618-branch (303478e273bd).
https://bugs.webkit.org/show_bug.cgi?id=268183
ASAN_ILL | WebCore::Document::removePlaybackTargetPickerClient.
rdar://120661908
Reviewed by Chris Dumez.
Unable to ref the page from removePlaybackTargetPickerClient as it may have
started destruction.
* LayoutTests/media/audio-remove-playback-crash-expected.txt: Added.
* LayoutTests/media/audio-remove-playback-crash.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::removePlaybackTargetPickerClient):
Canonical link: https://commits.webkit.org/272448.387@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.407@webkitglib/2.42
Commit: 6571d521860d4e4f8327f55f5c67923e1737e014
https://github.com/WebKit/WebKit/commit/6571d521860d4e4f8327f55f5c67923e1737e014
Author: Abrar Rahman Protyasha <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm
Log Message:
-----------
Cherry-pick 272448.388@safari-7618-branch (7047e8e918da).
https://bugs.webkit.org/show_bug.cgi?id=268198
[macOS] Pointer Lock should disengage when client windows present a sheet
https://bugs.webkit.org/show_bug.cgi?id=268198
rdar://121694233
Reviewed by Aditya Keerthi.
The Pointer Lock API is susceptible to abuse by nefarious webpages since
they can (programmatically or otherwise) make client windows show alerts
or permission granting sheets while pointer lock is engaged. Since our
current implementation of pointer lock stays engaged even when the
client window presents a sheet, it leaves the user in a compromised
state where they both don't know the location of the mouse cursor and
don't have a way to exit the pointer lock state (since the client window
where pointer lock is engaged is no longer focused or the key window).
This patch addresses this vulnerability by registering observers for the
NSWindowWillBeginSheetNotification notification on the WebView's current
window, and then requesting for pointer lock to be disengaged whenever
we receive a notification that said window will begin presenting a
sheet.
Test case added in WebKit.ClientDisplaysAlertSheetWhilePointerLockActive
that asserts we successfully exit pointer lock when a client window
presents an alert sheet. It also tests that we can successfully re-enter
pointer lock afterwards.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillBeginSheet:]):
(WebKit::WebViewImpl::windowWillBeginSheet):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm:
(-[PointerLockDelegate resetState]):
(-[PointerLockDelegate waitForPointerLockEngaged]):
(-[PointerLockDelegate waitForPointerLockLost]):
(-[PointerLockDelegate _webViewDidRequestPointerLock:completionHandler:]):
(-[PointerLockDelegate _webViewDidLosePointerLock:]):
Canonical link: https://commits.webkit.org/272448.388@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.408@webkitglib/2.42
Commit: ad9e04761debaec88c34bcdb15bae9dc254cbc8f
https://github.com/WebKit/WebKit/commit/ad9e04761debaec88c34bcdb15bae9dc254cbc8f
Author: Chris Dumez <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
Log Message:
-----------
Cherry-pick 272448.421@safari-7618-branch (25c11453b693).
https://bugs.webkit.org/show_bug.cgi?id=268405
Bad cast under CachedResourceLoader::preload()
https://bugs.webkit.org/show_bug.cgi?id=268405
rdar://121745788
Reviewed by Brent Fulgham.
In CachedResourceLoader::preload() we were calling requestResource(type)
to get a resource. Then if the type we requested was `FontResource`, we
assumed the the CachedResource returned was a CachedFont and would cast
to that type. However, this cast ends up being incorrect in some cases.
I suspect this could happen when requesting resources with the same URL
but different types.
To address the issue, we now check the actual type of the returned
CachedResource before casting it.
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::preload):
Canonical link: https://commits.webkit.org/272448.421@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.409@webkitglib/2.42
Commit: 4e1fab505e55ad101495bd77b4f8ca280c98b587
https://github.com/WebKit/WebKit/commit/4e1fab505e55ad101495bd77b4f8ca280c98b587
Author: Michael Saboff <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/runtime/ScopedArguments.h
M Source/JavaScriptCore/runtime/SymbolTable.cpp
M Source/JavaScriptCore/runtime/SymbolTable.h
Log Message:
-----------
Cherry-pick 272448.422@safari-7618-branch (5bc92c9d5253).
https://bugs.webkit.org/show_bug.cgi?id=268409
REGRESSION: JavaScriptCore: JSC::ScopedArguments::setIndexQuickly
https://bugs.webkit.org/show_bug.cgi?id=268409
rdar://121748005
Reviewed by Yusuke Suzuki.
A code inspection of the symbol table and scoped arguments code revealed
that SymbolTable::cloneScopePart() doesn't
properly copy the ScopedArgumentsTable from the source. Since
ScopedArguments point to the WatchpointSets in the
related SymbolTable, we need to create new WatchpointSets in the cloned
SymbolTable and have the ScopedArguments
point to the related new WatchpointSets.
This is a speculative fix.
* Source/JavaScriptCore/runtime/ScopedArguments.h:
* Source/JavaScriptCore/runtime/SymbolTable.cpp:
(JSC::SymbolTable::cloneScopePart):
(JSC::SymbolTable::hasScopedWatchpointSet):
* Source/JavaScriptCore/runtime/SymbolTable.h:
Canonical link: https://commits.webkit.org/272448.422@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.410@webkitglib/2.42
Commit: 48ce7259c86842e335a2609b298da63aa0124c98
https://github.com/WebKit/WebKit/commit/48ce7259c86842e335a2609b298da63aa0124c98
Author: Yijia Huang <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/JavaScriptCore/runtime/ErrorInstance.cpp
Log Message:
-----------
Cherry-pick 272448.442@safari-7618-branch (58204e87a044).
https://bugs.webkit.org/show_bug.cgi?id=268489
[JSC] Use DeferGCForAWhile instead of DeferGC in computeErrorInfo
https://bugs.webkit.org/show_bug.cgi?id=268489
rdar://121906810
Reviewed by Mark Lam, Yusuke Suzuki and Justin Michaud.
ErrorInstance::computeErrorInfo can be called from GC's Heap::runEndPhase.
In the case, we should use DeferGCForAWhile instead of DeferGC since it
can trigger another GC in its destruction.
* Source/JavaScriptCore/runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::computeErrorInfo):
Canonical link: https://commits.webkit.org/272448.442@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.411@webkitglib/2.42
Commit: f42e9802a3d8000e372ebb063e3928524620705b
https://github.com/WebKit/WebKit/commit/f42e9802a3d8000e372ebb063e3928524620705b
Author: Jean-Yves Avenard <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.messages.in
Log Message:
-----------
Cherry-pick 272448.445@safari-7618-branch (b60b2da0516d). rdar://107918233
Block "setMediaOverridesForTesting" media IPC endpoints when not testing
rdar://107918233
Reviewed by Youenn Fablet.
This is a continuation of 260935@main, adding the
setMediaOverridesForTesting to the list
of blocked IPC endpoints.
All involved tests already contains the required keywords.
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.messages.in:
Canonical link: https://commits.webkit.org/272448.445@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.412@webkitglib/2.42
Commit: 5e86ad70d36710a621fd169881bcd281f227ded3
https://github.com/WebKit/WebKit/commit/5e86ad70d36710a621fd169881bcd281f227ded3
Author: Alan Baradlay <[email protected]>
Date: 2024-03-15 (Fri, 15 Mar 2024)
Changed paths:
M Source/WebCore/rendering/RenderInline.cpp
Log Message:
-----------
Cherry-pick 272448.456@safari-7618-branch (66b364de9dfc).
https://bugs.webkit.org/show_bug.cgi?id=268525
Inline box may not be present in the enclosing formatting context
https://bugs.webkit.org/show_bug.cgi?id=268525
rdar://119921061
Reviewed by Antti Koivisto.
Speculative fix when the (potentially damaged) inline box is not present in
the enclosing formatting context.
This may happen when RenderInline::linesBoundingBox is called on a dirty
tree after moving an inline box (<span>)
from a block to an other (but before clearing the tree by running layout).
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::linesBoundingBox const):
Canonical link: https://commits.webkit.org/272448.456@safari-7618-branch
Canonical link: https://commits.webkit.org/266719.413@webkitglib/2.42
Compare: https://github.com/WebKit/WebKit/compare/23dd34655851...5e86ad70d367
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
