[webkit-changes] [WebKit/WebKit] 38ee2f: Cherry-pick 272448.625 at safari-7618-branch (800c12a...
Adrian Perez
noreply at github.com
Wed May 15 00:51:12 PDT 2024
Branch: refs/heads/webkitglib/2.44
Home: https://github.com/WebKit/WebKit
Commit: 38ee2f2a6eaec6aed04443a1b1cbfa8c6c06b35a
https://github.com/WebKit/WebKit/commit/38ee2f2a6eaec6aed04443a1b1cbfa8c6c06b35a
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/JavaScriptCore/API/JSStringRef.cpp
M Source/JavaScriptCore/API/tests/testapi.c
M Source/WTF/wtf/unicode/UTF8Conversion.cpp
Log Message:
-----------
Cherry-pick 272448.625 at safari-7618-branch (800c12a28dea). rdar://122388595
JSStringGetUTF8CString writes beyond the provided buffer size
rdar://122388595
Reviewed by Yusuke Suzuki.
U8_APPEND only checks the capacity in the non-ascii case,
so we should make sure we always check.
* Source/WTF/wtf/unicode/UTF8Conversion.cpp:
(WTF::Unicode::convertLatin1ToUTF8):
(WTF::Unicode::convertUTF16ToUTF8):
* Source/WebCore/dom/TextEncoder.cpp:
(WebCore::TextEncoder::encodeInto):
Canonical link: https://commits.webkit.org/272448.625@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.215@webkitglib/2.44
Commit: b5701eb0fe870f8800f146ffbdad35497b4a2e50
https://github.com/WebKit/WebKit/commit/b5701eb0fe870f8800f146ffbdad35497b4a2e50
Author: Nicole Rosario <nicole_rosario at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/css-grid-layout/css-grid-template-rows-invalid-length-expected.txt
A LayoutTests/fast/css-grid-layout/css-grid-template-rows-invalid-length.html
M Source/WebCore/style/StyleBuilderConverter.h
Log Message:
-----------
Cherry-pick 272448.626 at safari-7618-branch (0b6e28662a19). https://bugs.webkit.org/show_bug.cgi?id=269856
Added default length to createGridTrackBreadth() when length is undefined
https://bugs.webkit.org/show_bug.cgi?id=269856
rdar://119619013
Reviewed by Sammy Gill.
`convertToLength` returned length undefined to `createGridTrackBreadth`
which causes an issue when creating GridLength. Added check to see if
length is undefined and if so returned a default length = 0 instead
* Source/WebCore/style/StyleBuilderConverter.h:
(WebCore::Style::BuilderConverter::createGridTrackBreadth):
Canonical link: https://commits.webkit.org/272448.626@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.216@webkitglib/2.44
Commit: 5574e48233cdb417c50695039824e6ff0947a2d1
https://github.com/WebKit/WebKit/commit/5574e48233cdb417c50695039824e6ff0947a2d1
Author: Matthieu Dubet <m_dubet at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair-expected.txt
A LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair.html
M Source/WebCore/css/CSSValuePair.cpp
M Source/WebCore/css/CSSValuePair.h
M Source/WebCore/css/typedom/StylePropertyMap.cpp
M Source/WebCore/style/StyleBuilderConverter.h
Log Message:
-----------
Cherry-pick 272448.627 at safari-7618-branch (51293a58e9dd). rdar://115346002
[CSS] Fix bug when using a coalesced CSSValuePair with Typed OM
rdar://115346002
Reviewed by Chris Dumez.
We use the CSSParser and the serialization of CSSValue to validate the input of Typed OM set().
Unfortunately, sometimes a CSSValuePair serializes to a single value while it
actually contains two values: this confuses the StyleBuilder.
If the pair has the same values twice "10px 10px", it serializes to only "10px",
thus pass our string-based check (inside setProperty), but then crash when the actual value is a
pair of length instead of a simple length.
The more frequent case when the two values are distincts, such as "10px 30px", is
already prevented by the string-based check.
A proper fix would be to have validation method which doesn't work
on the serialized string value but on the actual typed CSSValue.
For the moment, we avoid crashing and warn the user with an error.
* LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair-expected.txt: Added.
* LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair.html: Added.
* Source/WebCore/css/CSSValuePair.cpp:
(WebCore::CSSValuePair::canBeCoalesced const):
* Source/WebCore/css/CSSValuePair.h:
* Source/WebCore/css/typedom/StylePropertyMap.cpp:
(WebCore::StylePropertyMap::set):
* Source/WebCore/style/StyleBuilderConverter.h:
(WebCore::Style::BuilderConverter::convertLengthSizing):
Canonical link: https://commits.webkit.org/272448.627@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.217@webkitglib/2.44
Commit: cac405a2378967ea4801adb6f162d27bdbc52678
https://github.com/WebKit/WebKit/commit/cac405a2378967ea4801adb6f162d27bdbc52678
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/decouple-calllinkinfo-from-access-case.js
M Source/JavaScriptCore/bytecode/AccessCase.cpp
M Source/JavaScriptCore/bytecode/AccessCase.h
M Source/JavaScriptCore/bytecode/GetByStatus.cpp
M Source/JavaScriptCore/bytecode/GetterSetterAccessCase.cpp
M Source/JavaScriptCore/bytecode/GetterSetterAccessCase.h
M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp
M Source/JavaScriptCore/bytecode/InlineCacheCompiler.h
M Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.cpp
M Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.h
M Source/JavaScriptCore/bytecode/PutByStatus.cpp
M Source/JavaScriptCore/bytecode/StructureStubInfo.cpp
M Source/JavaScriptCore/bytecode/StructureStubInfo.h
M Source/JavaScriptCore/jit/GCAwareJITStubRoutine.cpp
M Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h
M Source/JavaScriptCore/jit/JITStubRoutine.cpp
M Source/JavaScriptCore/jit/JITStubRoutine.h
Log Message:
-----------
Cherry-pick 272448.633 at safari-7618-branch (f25738c69a33). https://bugs.webkit.org/show_bug.cgi?id=268221
[JSC] AccessCase should not hold CallLinkInfo*
https://bugs.webkit.org/show_bug.cgi?id=268221
rdar://121733122
Reviewed by Justin Michaud.
AccessCase holds CallLinkInfo*. But when the underlying JITStubRoutine gets destroyed, this becomes invalid.
Previously, it does not matter since we always destroy CodeBlock first (synchronously), and then we clean up JITStubRoutine.
So there were strict ordering. But now CodeBlock destruction can get delayed.
But fundamentally speaking, having CallLinkInfo* in AccessCase is not right. This is compiled code's data structure and
AccessCase should be just a data for IC feedback.
In this patch we decouple CallLinkInfo* from AccessCase. CallLinkInfo's lifetime should be correctly managed by visitWeak, so,
we add visitWeak iteration in MarkingGCAwareJITStubRoutine. Then we can remove CallLinkInfo from AccessCase.
* JSTests/stress/decouple-calllinkinfo-from-access-case.js: Added.
(F7):
(f25):
(f33):
(C20.prototype.valueOf):
(C20):
(f27):
* Source/JavaScriptCore/bytecode/AccessCase.cpp:
(JSC::AccessCase::forEachDependentCell const):
(JSC::AccessCase::doesCalls const):
(JSC::AccessCase::visitWeak const):
(JSC::AccessCase::collectDependentCells const):
* Source/JavaScriptCore/bytecode/AccessCase.h:
* Source/JavaScriptCore/bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
* Source/JavaScriptCore/bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::dumpImpl const):
* Source/JavaScriptCore/bytecode/GetterSetterAccessCase.h:
* Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
(JSC::InlineCacheCompiler::generateWithGuard):
(JSC::InlineCacheCompiler::generate):
(JSC::InlineCacheCompiler::generateImpl):
(JSC::InlineCacheCompiler::emitProxyObjectAccess):
(JSC::InlineCacheCompiler::regenerate):
(JSC::InlineCacheHandler::callLinkInfoAt):
(JSC::InlineCacheHandler::visitWeak const):
* Source/JavaScriptCore/bytecode/InlineCacheCompiler.h:
* Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.cpp:
(JSC::ProxyObjectAccessCase::dumpImpl const):
* Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.h:
* Source/JavaScriptCore/bytecode/PutByStatus.cpp:
(JSC::PutByStatus::computeForStubInfo):
* Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::callLinkInfoAt):
* Source/JavaScriptCore/bytecode/StructureStubInfo.h:
* Source/JavaScriptCore/jit/GCAwareJITStubRoutine.cpp:
(JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
(JSC::MarkingGCAwareJITStubRoutine::visitWeakImpl):
(JSC::MarkingGCAwareJITStubRoutine::callLinkInfoAtImpl):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
(JSC::createICJITStubRoutine):
* Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h:
* Source/JavaScriptCore/jit/JITStubRoutine.cpp:
(JSC::JITStubRoutine::callLinkInfoAt):
* Source/JavaScriptCore/jit/JITStubRoutine.h:
(JSC::JITStubRoutine::callLinkInfoAtImpl):
Canonical link: https://commits.webkit.org/272448.633@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.218@webkitglib/2.44
Commit: 1dcc3a85c4b4cf5b7a45c299e95c6452f4f691ab
https://github.com/WebKit/WebKit/commit/1dcc3a85c4b4cf5b7a45c299e95c6452f4f691ab
Author: Claudio Saavedra <csaavedra at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/block/multicolumn-with-outline-auto-expected.txt
A LayoutTests/fast/block/multicolumn-with-outline-auto.html
M Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
M Source/WebCore/rendering/updating/RenderTreeBuilder.h
M Source/WebCore/rendering/updating/RenderTreeBuilderBlock.cpp
M Source/WebCore/rendering/updating/RenderTreeBuilderBlock.h
M Source/WebCore/rendering/updating/RenderTreeBuilderMultiColumn.cpp
Log Message:
-----------
Cherry-pick 274097.6 at webkit-2024.2-embargoed (446b237f7e06). https://bugs.webkit.org/show_bug.cgi?id=263180
Prevent selection repaint in the middle of multicolumn flow destruction
https://bugs.webkit.org/show_bug.cgi?id=263180
Reviewed by Alan Baradlay.
During multicolumn fragmented flow destruction, spanners are moved back
to their original DOM position in the tree. This is done through calls
to RenderTreeBuilderBlock::Block::detach(RenderBlockFlow&), which also
calls the more general RenderBlock ::detach() method for each spanner.
The former method results in the destruction of the spanner placeholders
and the merging of the necessary multicolumn sets, but this is not done
immediately, so the tree is temporarily inconsistent, before the
RenderBlock detach() method is called.
RenderTreeBuilderBlock::Block::detach(RenderBlock&), however,
might inadvertely end up triggering a repaint of the selection that the
tree is not ready for. I assume that this is an oversight from the possibility
that this method gets called during RenderBlockFlow detachment. This repaint
happens because RenderTreeBuilder::detachFromRenderElement() clears the
selection if the child being detached is to be destroyed. As
WillBeDestroyed::Yes is the default value in the definition of
detachFromRenderElement(), this is assumed to be the case, even when
that's not what happens during fragmented flow destruction.
The problem with this is that the selection repaint will eventually find itself
needing a consistent tree, and the fact that multicolumn sets are not merged
yet and there are spanners without a placehoder will break assumptions made
in RenderObject::propagateRepaintToParentWithOutlineAutoIfNeeded().
Fix this by making it possible for both detach() methods to propagate
WillBeDestroyed, with a default value of WillBeDestroyed::Yes to preserve
current behavior everywhere, but explicitly passing WillBeDestroyed::No
during fragmented flow destruction when detaching spanners, as this is what
is actually happening. This prevents the selection repaint from happening
before the tree is in a consistent state.
* LayoutTests/fast/block/multicolumn-with-outline-auto-expected.txt: Added.
* LayoutTests/fast/block/multicolumn-with-outline-auto.html: Added.
* Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:
(WebCore::RenderTreeBuilder::detach):
* Source/WebCore/rendering/updating/RenderTreeBuilder.h:
* Source/WebCore/rendering/updating/RenderTreeBuilderBlock.cpp:
(WebCore::RenderTreeBuilder::Block::detach):
* Source/WebCore/rendering/updating/RenderTreeBuilderBlock.h:
* Source/WebCore/rendering/updating/RenderTreeBuilderMultiColumn.cpp:
(WebCore::RenderTreeBuilder::MultiColumn::destroyFragmentedFlow):
Canonical link: https://commits.webkit.org/274097.6@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.648@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.219@webkitglib/2.44
Commit: 7ef599897147aca2433bea7a21e6f9bff2c5230e
https://github.com/WebKit/WebKit/commit/7ef599897147aca2433bea7a21e6f9bff2c5230e
Author: Mikhail R. Gadelha <mikhail at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/wasm/stress/wasm-unreachable-br-block.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 274097.7 at webkit-2024.2-embargoed (ab8e4a4470bb). https://bugs.webkit.org/show_bug.cgi?id=265425
WASM unreachable code validation is broken https://bugs.webkit.org/show_bug.cgi?id=265425
Reviewed by Keith Miller.
This patch fixes an assertion failure in the unreachable code parser
when the target of a br instruction is a block that was not added into
the control stack.
The code that checks the br target now takes into account the number of
unreachable blocks, if the br instruction is also unreachable. This is
similar to the solution employed by parseDelegateTarget and should
support cases when block, if, try, and loop were not added to the control
stack.
* JSTests/wasm/stress/wasm-unreachable-br-block.js: Added.
(async test):
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseBranchTarget):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
Canonical link: https://commits.webkit.org/274097.7@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.649@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.220@webkitglib/2.44
Commit: 9020818f54ed5fbc3ad6bb4a25407dfce6981bcc
https://github.com/WebKit/WebKit/commit/9020818f54ed5fbc3ad6bb4a25407dfce6981bcc
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/css/repeating-conic-gradient-small-range-expected.txt
A LayoutTests/fast/css/repeating-conic-gradient-small-range.html
A LayoutTests/fast/css/repeating-linear-gradient-small-range-expected.txt
A LayoutTests/fast/css/repeating-linear-gradient-small-range.html
A LayoutTests/fast/css/repeating-radial-gradient-small-range-expected.txt
A LayoutTests/fast/css/repeating-radial-gradient-small-range.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/rendering/style/StyleGradientImage.cpp
Log Message:
-----------
Cherry-pick 274097.8 at webkit-2024.2-embargoed (efd994a148b6). https://bugs.webkit.org/show_bug.cgi?id=264639
ASAN_ILL | WTF::Vector::expandCapacity; WTF::Vector::expandCapacity; WebCore::StyleGradientImage::computeStops
https://bugs.webkit.org/show_bug.cgi?id=264639
Reviewed by Antti Koivisto.
When working with repeating gradients, more care should be put into limiting the
amount of stops that can be additionally generated. If the original gradient
range is already too small, the extra stops are not generated. Once the number
of additional stops is calculated, the generation proceeds only if that number
is below some reasonable limit. That generation is also improved slightly by
creating a separate Vector of gradient stops that then simply replaces the
original one.
* LayoutTests/fast/css/repeating-conic-gradient-small-range-expected.txt: Added.
* LayoutTests/fast/css/repeating-conic-gradient-small-range.html: Added.
* LayoutTests/fast/css/repeating-linear-gradient-small-range-expected.txt: Added.
* LayoutTests/fast/css/repeating-linear-gradient-small-range.html: Added.
* LayoutTests/fast/css/repeating-radial-gradient-small-range-expected.txt: Added.
* LayoutTests/fast/css/repeating-radial-gradient-small-range.html: Added.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/rendering/style/StyleGradientImage.cpp:
(WebCore::StyleGradientImage::computeStops const):
Canonical link: https://commits.webkit.org/274097.8@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.650@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.221@webkitglib/2.44
Commit: 9655eabf8a574dd9eff51129c356f5bd1988bfa8
https://github.com/WebKit/WebKit/commit/9655eabf8a574dd9eff51129c356f5bd1988bfa8
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/dfg-ai-direct-get-by-id-attribute-change-transition.js
M Source/JavaScriptCore/bytecode/PutByStatus.cpp
M Source/JavaScriptCore/runtime/Structure.cpp
M Source/JavaScriptCore/runtime/Structure.h
Log Message:
-----------
Cherry-pick 272448.651 at safari-7618-branch (4e48bdad7045). https://bugs.webkit.org/show_bug.cgi?id=270265
[JSC] AI should observe attribute change transitions for PutByIdDirect in DFG compilation
https://bugs.webkit.org/show_bug.cgi?id=270265
rdar://122515736
Reviewed by Yusuke Suzuki.
Since DirectPutById can trigger and cache attribute change transitions,
the AI should observe these kinds of transitions when computing for
GetByStatus in the DFG compilation.
* JSTests/stress/dfg-ai-attribute-change-transition-1.js: Added.
(returnObject):
(Opt):
(createObjectA):
(createObjectB):
(initialize):
* JSTests/stress/dfg-ai-attribute-change-transition-2.js: Added.
(returnObject):
(Opt):
(createObject):
(getStructureID):
(main):
* Source/JavaScriptCore/bytecode/PutByStatus.cpp:
(JSC::PutByStatus::computeFor):
* Source/JavaScriptCore/runtime/Structure.cpp:
(JSC::Structure::attributeChangeTransitionToExistingStructureImpl):
(JSC::Structure::attributeChangeTransitionToExistingStructure):
(JSC::Structure::attributeChangeTransitionToExistingStructureConcurrently):
* Source/JavaScriptCore/runtime/Structure.h:
Canonical link: https://commits.webkit.org/272448.651@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.222@webkitglib/2.44
Commit: 56df757f15f6775393d617ff1dc07981263a343b
https://github.com/WebKit/WebKit/commit/56df757f15f6775393d617ff1dc07981263a343b
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/hoist-get-wasm-exports.js
M Source/JavaScriptCore/dfg/DFGSafeToExecute.h
Log Message:
-----------
Cherry-pick 272448.653 at safari-7618-branch (f6e2c3bb0a72). https://bugs.webkit.org/show_bug.cgi?id=270259
GetWebAssemblyInstanceExports nodes should not be blindly hoisted
https://bugs.webkit.org/show_bug.cgi?id=270259
rdar://123617167
Reviewed by Alexey Shvayka.
GetWebAssemblyInstanceExports nodes should not be blindly hoisted above
their structure check.
```
case WebAssemblyInstanceExportsIntrinsic:
...
addToGraph(CheckStructure, OpInfo(m_graph.addStructureSet(variant.structureSet())), thisNode);
set(result, addToGraph(GetWebAssemblyInstanceExports, Edge(thisNode, KnownCellUse)));
```
Similar to GetByOffset, we should only hoist this node if we have proven
that the child has the structure of a WebAssembly Instance.
* JSTests/stress/hoist-get-wasm-exports.js: Added.
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
Canonical link: https://commits.webkit.org/272448.653@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.223@webkitglib/2.44
Commit: 6f6c34c057f034796f60ebc0fd7443f2fde24704
https://github.com/WebKit/WebKit/commit/6f6c34c057f034796f60ebc0fd7443f2fde24704
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/en.lproj/Localizable.strings
M Source/WebCore/html/HTMLAnchorElement.cpp
M Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm
M Source/WebKit/UIProcess/SystemPreviewController.h
Log Message:
-----------
Cherry-pick 272448.672 at safari-7618-branch (6b6d3d3e61f6). <radar://122802255>
Interactionless USDZ Popups in Vision Pro
<radar://122802255>
Reviewed by Tim Horton.
Show a pop-up asking the user to confirm they want to
quick look preview a USDZ file in WebKit.
Add a delay if the page constantly tries to open one such
file otherwise it can be difficult to exit out of the page.
* Source/WebCore/en.lproj/Localizable.strings:
* Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
* Source/WebKit/UIProcess/SystemPreviewController.h:
* Source/WebCore/html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::handleClick):
Canonical link: https://commits.webkit.org/272448.672@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.224@webkitglib/2.44
Commit: 5b0417e4484c6f4eb76e90da35d1ad1743ae07b5
https://github.com/WebKit/WebKit/commit/5b0417e4484c6f4eb76e90da35d1ad1743ae07b5
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp
Log Message:
-----------
Cherry-pick 272448.684 at safari-7618-branch (cd62341b1dda). https://bugs.webkit.org/show_bug.cgi?id=270139
Web Inspector: Crash in Inspector::InspectorDebuggerAgent::didScheduleAsyncCall on knowyourmeme.com
https://bugs.webkit.org/show_bug.cgi?id=270139
rdar://123667952
Reviewed by Pascoe.
Avoid reading past the end of `m_pendingAsyncCalls`.
* Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
Canonical link: https://commits.webkit.org/272448.684@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.225@webkitglib/2.44
Commit: 15af2b30552cb3b2364242b336431759cde389fe
https://github.com/WebKit/WebKit/commit/15af2b30552cb3b2364242b336431759cde389fe
Author: Chris Dumez <cdumez at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
Log Message:
-----------
Cherry-pick 272448.685 at safari-7618-branch (028628cff473). https://bugs.webkit.org/show_bug.cgi?id=261611
Calling evaluateJavaScript enables back-button hijacking
https://bugs.webkit.org/show_bug.cgi?id=261611
rdar://115561250
Reviewed by Ben Nham.
In 253405 at main, I updated our back/forward list hijacking prevention logic by
treating history items added by JS (e.g. via 'history.pushState()`) as having
a user gesture if a user gesture had occurred in the last 10 seconds. This was
needed for backward compatibility with some legit sites.
The issue now is that if the client app has called evaluateJavaScript on the
WKWebView in the last 10 seconds, the JS will be able to hijack the back/forward
list again.
In 265168 at main, we did some hardening so that the transient activation gets
consumed after the evaluateJavaScript call has completed. However, it didn't
fix the back/forward list hijacking prevention logic because it relies on
user gesture and not transient activation.
To address the issue, I updated out back/forward list hijacking prevention logic
to rely on transient user activation rather than whether or not there was a
user gesture in the last 10 minutes.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::hasRecentUserInteractionForNavigationFromJS const):
* Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm:
(TEST):
Canonical link: https://commits.webkit.org/272448.685@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.226@webkitglib/2.44
Commit: 94adce30d4b5e29cac6649763c4e3551cd7f3b5c
https://github.com/WebKit/WebKit/commit/94adce30d4b5e29cac6649763c4e3551cd7f3b5c
Author: Rob Buis <rbuis at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash-expected.txt
A LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash.html
M Source/WebCore/html/HTMLPlugInImageElement.cpp
Log Message:
-----------
Cherry-pick 274097.9 at webkit-2024.2-embargoed (f81d56c47751). https://bugs.webkit.org/show_bug.cgi?id=268769
HTMLPlugInImageElement: verify that element is in same document before requesting a load
https://bugs.webkit.org/show_bug.cgi?id=268769
Reviewed by Ryosuke Niwa.
The testcase shows a scenario where a plugin is set up to start loading the plugin contents
from an event loop, however before the event loop is started the rest of the script will run, which
moves the plugin to a different document, thus hitting an ASSERT in WebFrame::createSubframe when the load
is performed. Protect against this by returning early when this situation is detected in the event loop.
* LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash-expected.txt: Added.
* LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash.html: Added.
* Source/WebCore/html/HTMLPlugInImageElement.cpp:
(WebCore::HTMLPlugInImageElement::requestObject):
Canonical link: https://commits.webkit.org/274097.9@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.695@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.227@webkitglib/2.44
Commit: fc7fbeae9b3d19a23379e1b608c40d329623e644
https://github.com/WebKit/WebKit/commit/fc7fbeae9b3d19a23379e1b608c40d329623e644
Author: Mikhail R. Gadelha <mikhail at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/dom/set-attribute-and-normalize-in-event-expected.txt
A LayoutTests/fast/dom/set-attribute-and-normalize-in-event.html
M Source/WebCore/dom/ContainerNode.cpp
Log Message:
-----------
Cherry-pick 274097.10 at webkit-2024.2-embargoed (65b1fae34533). https://bugs.webkit.org/show_bug.cgi?id=268765
Use RefPtr local variable for nextChild in insertChildrenBeforeWithoutPreInsertionValidityCheck
https://bugs.webkit.org/show_bug.cgi?id=268765
Reviewed by Ryosuke Niwa and Chris Dumez.
This patch adds a RefPtr to hold a reference to nextChild so that the
pointer stay valid through the scope of the function.
In the test case, the removeChild() call (from the before() call in the js
script) triggers a DOMSubtreeModified event, which eventually calls normalize.
The normalize() call can destroy text elements when normalizing the content of
the node if there is no one holding the reference to that node, so holding
nextChild in a RefPtr prevents us from reading an invalid pointer.
* LayoutTests/fast/dom/set-attribute-and-normalize-in-event-expected.txt: Added.
* LayoutTests/fast/dom/set-attribute-and-normalize-in-event.html: Added.
* Source/WebCore/dom/ContainerNode.cpp:
(WebCore::ContainerNode::insertChildrenBeforeWithoutPreInsertionValidityCheck):
Canonical link: https://commits.webkit.org/274097.10@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.696@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.228@webkitglib/2.44
Commit: 7b3640219893e6de5b3f91d7a19c800d03396ba1
https://github.com/WebKit/WebKit/commit/7b3640219893e6de5b3f91d7a19c800d03396ba1
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/ecs-store-with-loop.js
M Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp
M Source/JavaScriptCore/b3/testb3.h
M Source/JavaScriptCore/b3/testb3_3.cpp
Log Message:
-----------
Cherry-pick 272448.698 at safari-7618-branch (e6aa0aa96d51). https://bugs.webkit.org/show_bug.cgi?id=265426
[JSC] B3::EliminateCommonSubexpression shouldn't remove reads info after processing each block
https://bugs.webkit.org/show_bug.cgi?id=265426
rdar://118832222
Reviewed by Yusuke Suzuki.
Eliminate common subexpressions in B3 is used to remove redundant B3 nodes.
Current algorithm removes block reads info after processing each block. This is wrong
since some B3 nodes may be deleted erroneously due to the missing reads info from
the processed blocks. To fix this issue, we should update block reads info after
processing each node.
* JSTests/stress/ecs-store-with-loop.js: Added.
(foo):
(main):
* Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp:
* Source/JavaScriptCore/b3/testb3.h:
* Source/JavaScriptCore/b3/testb3_3.cpp:
(testCSEStoreWithLoop):
(addShrTests):
Canonical link: https://commits.webkit.org/272448.698@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.229@webkitglib/2.44
Commit: ca6f2c7353099c87b8aa521d6c96b3a0077963f2
https://github.com/WebKit/WebKit/commit/ca6f2c7353099c87b8aa521d6c96b3a0077963f2
Author: Keith Miller <keith_miller at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/bound-constructor-change-prototype-clears-cache.js
A JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js
M Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h
M Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp
M Source/JavaScriptCore/runtime/FunctionRareData.h
M Source/JavaScriptCore/runtime/InternalFunction.cpp
M Source/JavaScriptCore/runtime/JSFunction.cpp
M Source/JavaScriptCore/runtime/JSFunction.h
M Source/JavaScriptCore/runtime/JSFunctionInlines.h
Log Message:
-----------
Cherry-pick 272448.699 at safari-7618-branch (96283e8a5f10). https://bugs.webkit.org/show_bug.cgi?id=270302
Changing a JSFunction's prototype property should clear allocation caches
https://bugs.webkit.org/show_bug.cgi?id=270302
rdar://121657868
Reviewed by Alexey Shvayka and Yusuke Suzuki.
Right now we only clear the allocation watchpoint if a JSFunction `mayHaveNonReifiedPrototype()` when setting
the .prototype property. This is semantically incorrect in the case of `new.target` bound functions because we will cache
the wrong value.
This patch makes it so we always file the allocation profile watchpoint when turning either of the allocation profiles.
When turning the ObjectAllocationProfile (used by op_create_this) we assert the watchpoint has already been fired as it
should've already happened when the new .prototype value was set. When turning the InternalFunctionAllocationProfile (used
by createSubclassStructure when subclassing InternalFunction/Reflect.construct) its possible to pass the same JSFunction
to two different InternalFunctions, which will turn the profile.
* JSTests/stress/bound-constructor-change-prototype-clears-cache.js: Added.
(empty):
(test1.const.newTarget):
(test1):
(test2.const.newTarget):
(test2.Opt):
(test2):
(test3.const.newTarget):
(main):
* JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js: Added.
(opt):
(main.target):
(main):
* Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
* Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h:
(JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
* Source/JavaScriptCore/dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
(JSC::createInternalFieldObject):
* Source/JavaScriptCore/runtime/FunctionRareData.h:
* Source/JavaScriptCore/runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* Source/JavaScriptCore/runtime/JSFunction.cpp:
(JSC::JSFunction::prototypeForConstruction):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* Source/JavaScriptCore/runtime/JSFunction.h:
* Source/JavaScriptCore/runtime/JSFunctionInlines.h:
(JSC::JSFunction::canUseAllocationProfiles):
(JSC::JSFunction::ensureRareDataAndObjectAllocationProfile):
(JSC::JSFunction::canUseAllocationProfile): Deleted.
(JSC::JSFunction::ensureRareDataAndAllocationProfile): Deleted.
Canonical link: https://commits.webkit.org/272448.699@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.230@webkitglib/2.44
Commit: 90134643e6487378454d12e0656e7b7aa9962966
https://github.com/WebKit/WebKit/commit/90134643e6487378454d12e0656e7b7aa9962966
Author: Darryl Parkinson <d_parkinson at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/workers/service/server/SWServerWorker.cpp
M Source/WebCore/workers/service/server/SWServerWorker.h
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h
Log Message:
-----------
Cherry-pick 272448.701 at safari-7618-branch (be630dbb12c9). https://bugs.webkit.org/show_bug.cgi?id=270302
Ensure that the SWServerWorker is in the correct state before finishing installation
rdar://121429889
Reviewed by Youenn Fablet.
Ensure that the SWServerWorker is in the expected state and bail if this method is triggered on a SWServerWorker in a different state. This method is callable over CoreIPC passing a ServiceWorkerIdentifier. Passing the ID of a service worker in any other state will reach the RELEASE_ASSERT
* Source/WebCore/workers/service/server/SWServerWorker.cpp:
(WebCore::SWServerWorker::didFinishInstall):
Canonical link: https://commits.webkit.org/272448.701@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.231@webkitglib/2.44
Commit: 48631228bef3c06358719a7522ec29c43198b643
https://github.com/WebKit/WebKit/commit/48631228bef3c06358719a7522ec29c43198b643
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window-expected.txt
A LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window.html
M Source/WebKit/UIProcess/Cocoa/WKContactPicker.h
M Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm
M Source/WebKit/UIProcess/ios/WKContentView.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 272448.703 at safari-7618-branch (a3524e350ec9). https://bugs.webkit.org/show_bug.cgi?id=265602
[iOS] File picker dialog remains after opening a new tab in 3rd-party browsers
https://bugs.webkit.org/show_bug.cgi?id=265602
rdar://119001046
Reviewed by Abrar Rahman Protyasha.
The file upload panel does not dismiss itself after a new tab is opened, and can
end up displayed over a site that's unrelated to the one requesting the upload.
The panel itself is a modal view controller that is presented from an appropriate
view controller containing the `WKWebView`. Safari has explicit logic to dismiss
presented modal view controllers on tab switch, but it is not reasonable to expect
other clients to guarantee this behavior.
Fix by dismissing all pickers if the `WKWebView` is removed from the hierarchy.
* LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window-expected.txt: Added.
* LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window.html: Added.
* Source/WebKit/UIProcess/Cocoa/WKContactPicker.h:
* Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm:
(-[WKContactPicker dismiss]):
Add a new hook to dismiss the contact picker.
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView willMoveToWindow:]):
If the content view has moved to a `nil` window, it has been removed from the
view hierarchy, and presented pickers should be dismissed.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView cleanUpInteraction]):
Factor out logic into `-[WKContentView dismissPickers]`.
(-[WKContentView dismissPickers]):
Dismiss all pickers that the content view is aware of.
Canonical link: https://commits.webkit.org/272448.703@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.232@webkitglib/2.44
Commit: 2f99dbcc1ef622fc11f18fb4b46926ddd96fa87c
https://github.com/WebKit/WebKit/commit/2f99dbcc1ef622fc11f18fb4b46926ddd96fa87c
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.h
M Source/WebCore/Modules/webaudio/AudioBuffer.cpp
M Source/WebCore/Modules/webaudio/AudioBuffer.h
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h
M Source/WebCore/Modules/webaudio/AudioNode.h
M Source/WebCore/Modules/webaudio/AudioNodeOutput.cpp
M Source/WebCore/Modules/webaudio/AudioNodeOutput.h
M Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp
M Source/WebCore/Modules/webaudio/BaseAudioContext.h
M Source/WebCore/Modules/webaudio/DynamicsCompressorNode.h
M Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
M Source/WebCore/Modules/webaudio/OfflineAudioContext.h
M Source/WebCore/Modules/webaudio/OscillatorNode.h
M Source/WebCore/platform/audio/AudioUtilities.cpp
M Source/WebCore/platform/audio/AudioUtilities.h
M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/audio-fingerprinting.html
Log Message:
-----------
Cherry-pick 272448.707 at safari-7618-branch (3c7dd1781475). https://bugs.webkit.org/show_bug.cgi?id=270767
AudioBuffer noise injection in Private Browsing can be negated using a looping audio buffer source
https://bugs.webkit.org/show_bug.cgi?id=270767
rdar://124156971
Reviewed by Chris Dumez, Charlie Wolfe and Matthew Finkel.
Implement several mitigations to make it impractical to reverse noise injection by looping a single
audio sample many times in a single audio buffer and averaging the results.
1. Adjust noise injection to use normally-distributed noise, instead of a uniform random
distribution. This raises the bar for "averaging-style" attacks, which can currently converge on
a stable result by averaging the min/max values in the random distribution. A similar attack
will now require more iterations to converge on the original value.
2. Store previously-generated random values while applying noise, and reapply these random values
to the values that are encountered repeatedly. This ensures that an attacker does not gain more
information about the original value, by causing it to be computed repeatedly in the same audio
buffer.
3. Instead of uniformly applying a fixed noise level (0.001) for all readback using
`OfflineAudioContext`, allow certain node types that are known to expose hardware or OS
differences (i.e. `DynamicsCompressorNode` and `OscillatorNode`) to increase the amount of
injected noise beyond the baseline of 0.1%. `AudioBufferSourceNode`, in particular, will amplify
the noise level more, depending on the number of times the audio buffer is looped.
* Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.h:
* Source/WebCore/Modules/webaudio/AudioBuffer.cpp:
(WebCore::AudioBuffer::releaseMemory):
Replace the single boolean flag (`m_needsAdditionalNoise`) with a `m_noiseInjectionMultiplier`,
which indicates the magnitude of noise injection (the standard deviation of the normal distribution
used to inject noise).
(WebCore::AudioBuffer::copyToChannel):
(WebCore::AudioBuffer::zero):
(WebCore::AudioBuffer::copyTo const):
(WebCore::AudioBuffer::applyNoiseIfNeeded):
* Source/WebCore/Modules/webaudio/AudioBuffer.h:
(WebCore::AudioBuffer::increaseNoiseInjectionMultiplier):
(WebCore::AudioBuffer::noiseInjectionMultiplier const):
(WebCore::AudioBuffer::setNeedsAdditionalNoise): Deleted.
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
(WebCore::AudioBufferSourceNode::noiseInjectionMultiplier const):
Increase the noise injection level for an audio buffer, if it's downstream from an
`AudioBufferSourceNode` that loops many times. For an audio buffer source that loops more than 200
times, this boosts the existing noise level for the audio buffer by a factor of 0.005 per loop,
leading to a massive amount of noise in the case where a tiny sample is looped back-to-back in a
large buffer.
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h:
* Source/WebCore/Modules/webaudio/AudioNode.h:
(WebCore::AudioNode::noiseInjectionMultiplier const):
Add a subclassing hook that allows each `AudioNode` subclass to inject additional noise when reading
back the final `AudioBuffer`. This allows us to selectively increase the amount of injected noise
when using specific types of audio nodes, which are known to expose larger differences w.r.t. the
underlying OS or CPU architecture.
* Source/WebCore/Modules/webaudio/AudioNodeOutput.cpp:
(WebCore::AudioNodeOutput::forEachInputNode const):
Add a helper method to iterate over each input node (i.e. the next destination in the processing
graph) that's attached to this output. Note that this must be called from underneath the context's
graph lock.
* Source/WebCore/Modules/webaudio/AudioNodeOutput.h:
* Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp:
(WebCore::AudioWorkletNode::process):
Increase the noise level when passing raw data into worklets, to adjust for the new normally-
distributed noise injection.
* Source/WebCore/Modules/webaudio/BaseAudioContext.h:
(WebCore::BaseAudioContext::referencedSourceNodes const):
Add a helper method to iterate over all source nodes in the audio context; must be called only when
the context's graph lock is held.
* Source/WebCore/Modules/webaudio/DynamicsCompressorNode.h:
Add additional buffer readback noise when using certain audio node types.
* Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp:
(WebCore::OfflineAudioContext::OfflineAudioContext):
(WebCore::OfflineAudioContext::lazyInitialize):
(WebCore::OfflineAudioContext::increaseNoiseMultiplierIfNeeded):
Upon initialization, traverse the audio processing graph in search for audio nodes that warrant
additional noise injection, and accumulate this extra noise on the target buffer.
* Source/WebCore/Modules/webaudio/OfflineAudioContext.h:
* Source/WebCore/Modules/webaudio/OscillatorNode.h:
* Source/WebCore/platform/audio/AudioUtilities.cpp:
(WebCore::AudioUtilities::applyNoise):
Switch to normally-distributed noise injection, rather than uniformally random noise. Additionally,
ensure that if a value appears again in the same buffer, it'll use the same, previously computed
noise multiplier value instead of a newly generated random value.
* Source/WebCore/platform/audio/AudioUtilities.h:
* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
(TestWebKitAPI::TEST):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/audio-fingerprinting.html:
Add a new test case to exercise these mitigations.
Canonical link: https://commits.webkit.org/272448.707@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.233@webkitglib/2.44
Commit: 81da5ef39552f1460189deafc42663ad5def64a4
https://github.com/WebKit/WebKit/commit/81da5ef39552f1460189deafc42663ad5def64a4
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/getter-setter-ai.js
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/runtime/Operations.cpp
Log Message:
-----------
Cherry-pick 272448.708 at safari-7618-branch (b42cc4168b71). https://bugs.webkit.org/show_bug.cgi?id=270659
Difference in semantics between jsTypeStringForValueWithConcurrency and buildTypeOf
https://bugs.webkit.org/show_bug.cgi?id=270659
rdar://124116542
Reviewed by Yusuke Suzuki.
Consider the given test case:
Object1: 0x30000bba0 %DL (should never getByOffset p3 of this, it is a GetterSetter)
Object2: 0x30000bc10 %DS (p3 is fine)
Before LICM:
32 0 40: D at 26:<!0:-> FilterGetByStatus(Check:Untyped:D at 7, MustGen, (Simple, <id='uid:(p1)', [0x30000bc10:[0xbc10/48144, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)], 0x30000bba0:[0xbba0/48032, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)]], [], offset = 64>, seenInJIT = true), W:SideState, bc#4, ExitValid)
33 0 40: D at 15:<!0:-> AssertNotEmpty(Check:Untyped:D at 7, MustGen, W:SideState, Exits, bc#4, ExitValid)
34 0 40: D at 28:<!0:-> CheckStructure(Cell:D at 7, MustGen, [%DS:Function, %DL:Function], R:JSCell_structureID, Exits, bc#4, ExitValid)
35 0 40: D at 29:< 2:-> GetButterfly(Cell:D at 7, Storage|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Other, R:JSObject_butterfly, bc#4, ExitValid)
36 0 40: D at 30:< 1:-> GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureInt, Int32, id0{p1}, 64, R:NamedProperties(0), bc#4, ExitValid) predicting Int32
... branching
6 7 40: D at 87:<!0:-> FilterGetByStatus(Check:Untyped:D at 7, MustGen, (Simple, <id='uid:(p3)', [0x30000bc10:[0xbc10/48144, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)]], [], offset = 66>, seenInJIT = true), W:SideState, bc#45, ExitValid)
7 7 40: D at 89:<!0:-> CheckStructure(Cell:D at 7, MustGen, [%DS:Function], R:JSCell_structureID, Exits, bc#45, ExitValid)
8 7 40: D at 91:< 2:-> GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, BoolInt32, id3{p3}, 66, R:NamedProperties(3), bc#45, ExitValid) predicting BoolInt32
11 7 40: D at 94:< 2:-> TypeOf(Check:Untyped:Kill:D at 91, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Exits, bc#51, ExitValid)
Note that we never get p3 of DL
After LICM blind hoist:
34 0 41: D at 28:<!0:-> CheckStructure(Cell:D at 7, MustGen, [%DS:Function, %DL:Function], R:JSCell_structureID, Exits, bc#4, ExitValid)
35 0 41: D at 29:< 2:-> GetButterfly(Cell:D at 7, Storage|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Other, R:JSObject_butterfly, bc#4, ExitValid)
36 0 41: D at 30:< 1:-> GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureInt, Int32, id0{p1}, 64, R:NamedProperties(0), bc#4, ExitValid) predicting Int32
44 0 41: D at 48:<!0:-> CheckIsConstant(Cell:D at 7, MustGen, <0x13908f140, Function>, object1#B5FU55/<nogen>:[0x13909da00], Exits, bc#25, exit: bc#17, ExitValid, WasHoisted)
45 0 41: D at 91:< 2:-> GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, BoolInt32, id3{p3}, 66, R:NamedProperties(3), bc#45, exit: bc#17, ExitValid) predicting BoolInt32
46 0 41: D at 94:< 2:-> TypeOf(Check:Untyped:Kill:D at 91, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Exits, bc#51, exit: bc#17, ExitValid, WasHoisted)
The GetByOffset is hoisted without its guarding CheckStructure, and it accesses p3 unexpectedly. SafeToExecute says it is
safe because it won't crash or produce a malformed JSValue. Honestly, fair.
This patch fixes the semantic difference between AI and runtime for GetterSetter objects.
Stopping the GetterSetter from being hoisted may be too costly and restrictive, and it
doesn't get leaked anyway.
The string result (which was [object] but is now [symbol]) doesn't really matter, it should
never leak to user code anyway. Even if it does, it is just a string.
* JSTests/stress/getter-setter-ai.js: Added.
(opt):
(watchP3.cache):
(watchP3):
(main.let.object1):
(main.let.object2):
(main):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/runtime/Operations.cpp:
(JSC::jsTypeStringForValueWithConcurrency):
Canonical link: https://commits.webkit.org/272448.708@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.234@webkitglib/2.44
Commit: 21a806bc90ab33ac3d588e10fc0313d9971a2551
https://github.com/WebKit/WebKit/commit/21a806bc90ab33ac3d588e10fc0313d9971a2551
Author: Alex Christensen <achristensen at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 272448.733 at safari-7618-branch (7d7e9c948a3b). https://bugs.webkit.org/show_bug.cgi?id=270949
Verify range of ArrayBuffer when deserializing an ArrayBufferView
https://bugs.webkit.org/show_bug.cgi?id=270949
rdar://123906915
Reviewed by Chris Dumez.
byteOffset and length come from an untrusted source, and if out of bounds they
can lead to arbitrary reads. If they are out of bounds, fail to deserialize.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::readArrayBufferViewImpl):
Canonical link: https://commits.webkit.org/272448.733@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.235@webkitglib/2.44
Commit: 86af20805f934d22c283a6158510210b38bd128f
https://github.com/WebKit/WebKit/commit/86af20805f934d22c283a6158510210b38bd128f
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp
Log Message:
-----------
Cherry-pick 272448.773 at safari-7618-branch (052845bc6c5c). https://bugs.webkit.org/show_bug.cgi?id=271395
[UIProcess] Unsafe downcast in ScrollingTreeStickyNode::computeLayerPosition leading to type confusion.
https://bugs.webkit.org/show_bug.cgi?id=271395
rdar://125084284
Reviewed by Chris Dumez.
Fix various places in scrolling tree-related code where we do unchecked `downcast<>`s of
scrolling tree types.
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::frameViewVisualViewportChanged):
(WebCore::AsyncScrollingCoordinator::setViewportConstraintedNodeConstraints):
* Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp:
(WebCore::ScrollingStateOverflowScrollProxyNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp:
(WebCore::ScrollingStateStickyNode::computeLayerPosition const):
* Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp:
(WebCore::ScrollingTreeOverflowScrollProxyNode::dumpProperties const):
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp:
(WebCore::ScrollingTreeStickyNode::computeLayerPosition const):
Canonical link: https://commits.webkit.org/272448.773@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.236@webkitglib/2.44
Commit: ad2702925dfa9f5b690742dee324665a65aa88b3
https://github.com/WebKit/WebKit/commit/ad2702925dfa9f5b690742dee324665a65aa88b3
Author: Chris Dumez <cdumez at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/WaveShaperNode.cpp
M Source/WebCore/Modules/webaudio/WaveShaperNode.h
Log Message:
-----------
Cherry-pick 272448.781 at safari-7618-branch (bc1031419c11). https://bugs.webkit.org/show_bug.cgi?id=271654
Use-after-free in WebCore::WaveShaperDSPKernel::processCurve()
https://bugs.webkit.org/show_bug.cgi?id=271654
rdar://123631199
Reviewed by Jer Noble.
Make sure WaveShaperNode::curveForBindings() clones our internal array
before returning it to JS. This is important so that the JS cannot
modify our internal array on the main thread while the audio thread is
using it for rendering.
* Source/WebCore/Modules/webaudio/WaveShaperNode.cpp:
(WebCore::WaveShaperNode::curveForBindings):
* Source/WebCore/Modules/webaudio/WaveShaperNode.h:
Canonical link: https://commits.webkit.org/272448.781@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.237@webkitglib/2.44
Commit: 9aa9b7096ce0f2670f25c3a19e4c0460df379970
https://github.com/WebKit/WebKit/commit/9aa9b7096ce0f2670f25c3a19e4c0460df379970
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/fast/css/line-break-fixed-position-container-expected.txt
A LayoutTests/fast/css/line-break-fixed-position-container.html
M Source/WebCore/rendering/RenderObject.cpp
Log Message:
-----------
Cherry-pick 274097.12 at webkit-2024.2-embargoed (5bd3a1c2b0ac). https://bugs.webkit.org/show_bug.cgi?id=264631
Special case treatment of out-of-flow RenderLineBreak
https://bugs.webkit.org/show_bug.cgi?id=264631
rdar://114719845
Reviewed by Alan Baradlay.
Out-of-flow RenderLineBreaks have problems when relying on default out-of-flow support of the render
tree, see https://bugs.webkit.org/show_bug.cgi?id=270977.
To fix the problem we change containerForElement and containingBlock to treat RenderLineBreak that are out-of-flow as
if they have position: static.
* LayoutTests/fast/css/line-break-fixed-position-container-expected.txt: Added.
* LayoutTests/fast/css/line-break-fixed-position-container.html: Added.
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::containingBlock const):
(WebCore::containerForElement):
Canonical link: https://commits.webkit.org/274097.12@webkit-2024.2-embargoed
Canonical link: https://commits.webkit.org/272448.783@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.238@webkitglib/2.44
Commit: 538c80da087b299c0ab548e9c93acbeb7c73997b
https://github.com/WebKit/WebKit/commit/538c80da087b299c0ab548e9c93acbeb7c73997b
Author: Justin Michaud <justin at justinmichaud.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/get-by-val-hoist-above-structure-2.js
A JSTests/stress/get-by-val-hoist-above-structure.js
M Source/JavaScriptCore/dfg/DFGBasicBlock.h
M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
M Source/JavaScriptCore/dfg/DFGInPlaceAbstractState.cpp
M Source/JavaScriptCore/dfg/DFGInPlaceAbstractState.h
Log Message:
-----------
Cherry-pick 272448.796 at safari-7618-branch (8d5ba1eecf30). https://bugs.webkit.org/show_bug.cgi?id=271435
DFG Constant Folding phase can see inconsistent view of world, causing LICM to miscompile
https://bugs.webkit.org/show_bug.cgi?id=271435
rdar://124506508
Reviewed by Yusuke Suzuki.
Consider the following example:
============================================================================================================
FIRST SLEEP (before performCFA)
D at 80:< 10:-> JSConstant(JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Final, Weak:Object: 0x13a0e8140 with butterfly 0x0(base=0xfffffffffffffff8) (Structure %AJ:Object), StructureID: 40640, bc#0, ExitValid)
D at 126:<!0:-> FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(x)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], [], offset = 0>, seenInJIT = true), W:SideState, bc#112, ExitValid)
D at 128:<!0:-> CheckStructure(Cell:D at 80, MustGen, [%AJ:Object], R:JSCell_structureID, Exits, bc#112, ExitValid)
D at 133:<!0:-> FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(toJSON),cell:(String (atomic),8Bit:(1),length:(6): toJSON, StructureID: 16976)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], [], offset = 1>, seenInJIT = true), W:SideState, bc#118, ExitValid)
D at 136:< 4:-> GetByOffset(KnownCell:D at 80, KnownCell:D at 80, JS|PureNum|NeedsNaNOrInfinity|UseAsOther|ReallyWantsInt, BoolInt32, id6{toJSON}, 1, R:NamedProperties(6), bc#118, ExitValid) predicting BoolInt32
D at 138:<!0:-> Check(Check:Int32:D at 136, MustGen, Exits, bc#118, exit: bc#124, ExitValid)
D at 140:<!0:-> Branch(Boolean:D at 35, MustGen, T:#9/w:10.000000, F:#12/w:10.000000, W:SideState, bc#124, ExitValid)
D at 4:< 1:-> GetButterfly(Cell:D at 104, Storage|PureInt, R:JSObject_butterfly, bc#127, ExitValid)
D at 1:<!1:-> CheckInBounds(Int32:D at 136, KnownInt32:D at 151, JS|MustGen|PureInt, Int32, Exits, bc#127, ExitValid)
D at 143:< 3:-> GetByVal(KnownCell:D at 104, Int32:Kill:D at 136, Check:Untyped:Kill:D at 4, Check:Untyped:Kill:D at 1, JS|VarArgs|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Contiguous+OriginalCopyOnWriteArray+InBoundsSaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedContiguousProperties, Exits, bc#127, ExitValid) predicting StringIdent
%AJ:Object = 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]
Execution:
AI GetByOffset D at 136 AI says (BoolInt32, Int32: 0, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x0(base=0xfffffffffffffff8) (Structure 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]), StructureID: 40640, 1:StructuresAreWatched) state StructuresAreWatched
AI CheckInBounds D at 1 AI says left Int32:D at 136 is Int32: 0
SECOND SLEEP (after performCFA, before performConstantFolding)
Note that the jsconstant has a structure transition at this point.
D at 80:< 10:-> JSConstant(JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Final, Weak:Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002380) (Structure %AR:Object), StructureID: 40976, bc#0, ExitValid)
D at 126:<!0:-> FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(x)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], [], offset = 0>, seenInJIT = true), W:SideState, bc#112, ExitValid)
D at 128:<!0:-> CheckStructure(Cell:D at 80, MustGen, [%AR:Object], R:JSCell_structureID, Exits, bc#112, ExitValid)
D at 133:<!0:-> FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(toJSON),cell:(String (atomic),8Bit:(1),length:(6): toJSON, StructureID: 16976)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], [], offset = 1>, seenInJIT = true), W:SideState, bc#118, ExitValid)
D at 136:< 4:-> GetByOffset(KnownCell:D at 80, KnownCell:D at 80, JS|PureNum|NeedsNaNOrInfinity|UseAsOther|ReallyWantsInt, BoolInt32, id6{toJSON}, 1, R:NamedProperties(6), bc#118, ExitValid) predicting BoolInt32
D at 4:< 1:-> GetButterfly(Cell:D at 104, Storage|PureInt, R:JSObject_butterfly, bc#127, ExitValid)
D at 1:<!1:-> CheckInBounds(Int32:D at 136, KnownInt32:D at 151, JS|MustGen|PureInt, Int32, Exits, bc#127, ExitValid)
D at 143:< 3:-> GetByVal(KnownCell:D at 104, Int32:Kill:D at 136, Check:Untyped:Kill:D at 4, Check:Untyped:Kill:D at 1, JS|VarArgs|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Contiguous+OriginalCopyOnWriteArray+InBoundsSaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedContiguousProperties, Exits, bc#127, ExitValid) predicting StringIdent
%AR:Object = 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]
%B6:Object = 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]
Execution:
AI GetByOffset D at 136 AI says (HeapTop, TOP, TOP, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002360) (Structure 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]), StructureID: 40976, 1:StructuresAreWatched) state StructuresAreWatched
GetByOffset D at 136 AI says (HeapTop, TOP, TOP, 1:StructuresAreWatched)
CheckInBounds D at 1 AI says left Int32:D at 136 is Int32: 0
AI GetByOffset D at 136 AI says (HeapTop, TOP, TOP, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002360) (Structure 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]), StructureID: 40976, 1:StructuresAreWatched) state StructuresAreWatched
SLEEP DONE
============================================================================================================
The constant folding phase chooses to fold the CheckInBounds, but not the GetByOffset. At this point, this is still correct (although sub-optimal).
1) Why does AI disagree in these two places?
The constant folding phase doesn't re-run AI. It runs it from top to bottom on certain blocks only.
In this example, The CheckInBounds AI proof is read directly from the block, but the GetByOffset
has its value computed.
1) Why can the JSConstant's structure change without triggering a watchpoint?
The constant remains constant. We never used the fact that that it had a certain
structure anywhere, our proofs stem from the fact that we have a CheckStructure.
1) Why does the re-run AI pass in performConstantFolding not predict the GetByOffset to be constant?
The structure change causes GetPropertyConcurrently to fail to get the value concurrently.
We must assume that it is always safe to produce a more conservative result in this phase.
Note though that if the phase returned the same value as the first time around, that would still have been
correct! The answer to this question didn't change, we just lost the ability to compute it.
============================================================================================================
Why this is a problem
This is a classic example of a broad class of bugs affecting the JIT. Different passes can see different values as the mutator
changes the object graph, even for the same pass. Normally this is fine, because the compiler is always narrowing its assumptions.
Specifically, with each pass we assume more and more detailed things about the code, and guard against these assumptions
being wrong either with watchpoints or runtime checks.
In this example, we see that we CheckStructure. Then, as a result, we can elide nodes that are dominated by that check (like the
GetByOffset or the CheckInBounds). As long as we never loosen that assumption again, we are fine.
In this example, our CFA pass assumes that the GetByOffset is constant. The Constant Folding phase then assumes sometimes that it is constant,
and sometimes that it is not. This puts us in opposition to another principle, that is the idea that we should always
be able to answer any question asked of us conservatively and be safe. Up until this point, both of these ideas are holding true.
Unfortunately, we also need LICM. LICM needs to run after many assumptions have already been made, and it dramatically loosens
assumptions. In this example, LICM comes along and hoists the GetByVal(GetByOffset()) above the CheckStructure.
If we had indeed constant folded the GetByOffset too, we would be fine to do.
We should always be able to avoid constant folding safely.
LICM should be able to hoist constant values safely.
============================================================================================================
How to fix this generally
1) If AI says something is constant, just make it constant then.
This is the simplest solution, and should just work. This makes sure that what AI says is true, even if LICM moves stuff around.
This would require some re-work of the AI phase though.
1) LCIM should see that this isn't safe to move
The effects here are super specific. If LICM asked the question "If I move this, is this still safe to execute?" it would
have answered "no" in this case (without the structure check). Of course, if we hadn't removed the CheckInBounds, the answer
would be "yes," which is also fine.
One could imagine that this analysis would be pretty difficult.
1) Always run the constant folder on each block.
```
// This method is evil - it causes a huge maintenance headache and there is a gross amount of
// code devoted to it. It would be much nicer to just always run the constant folder on each
// block. But, the last time we did it, it was a 1% SunSpider regression:
// https://bugs.webkit.org/show_bug.cgi?id=133947
// So, we should probably keep this method.
void setShouldTryConstantFolding(bool tryConstantFolding) { m_shouldTryConstantFolding = tryConstantFolding; }
```
This would fix the issue though, as a failure to prove something at any point in time would not permit
that proof to be used later on.
This patch chooses the third option.
This appears to be perf-neutral on modern hardware on JS2/3 and SP2/3.
* JSTests/stress/get-by-val-hoist-above-structure.js: Added.
(opt):
(createObjectOfS1):
(createObjectOfS2):
(main):
* Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
Canonical link: https://commits.webkit.org/272448.796@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.239@webkitglib/2.44
Commit: b541497ce00e7fa11bbaa3e06aee0d3e6de2bc63
https://github.com/WebKit/WebKit/commit/b541497ce00e7fa11bbaa3e06aee0d3e6de2bc63
Author: Justin Michaud <justin at justinmichaud.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A JSTests/stress/sbfx-offset-overflow.js
M Source/JavaScriptCore/b3/B3LowerToAir.cpp
Log Message:
-----------
Cherry-pick 272448.797 at safari-7618-branch (d7ad67d3fe10). https://bugs.webkit.org/show_bug.cgi?id=271491
SBFX should not allow imm overflow
https://bugs.webkit.org/show_bug.cgi?id=271491
rdar://125127373
Reviewed by Yusuke Suzuki.
These isel patterns should be a bit more careful with overflow.
* JSTests/stress/sbfx-offset-overflow.js: Added.
(foo):
* Source/JavaScriptCore/b3/B3LowerToAir.cpp:
Canonical link: https://commits.webkit.org/272448.797@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.240@webkitglib/2.44
Commit: 9b1e21b56b92db047d2a1d587bee2bebe7bc5b32
https://github.com/WebKit/WebKit/commit/9b1e21b56b92db047d2a1d587bee2bebe7bc5b32
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h
M Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestGraphicsContextGLCocoa.mm
Log Message:
-----------
Cherry-pick 272448.803 at safari-7618-branch (89ee93bd2ea4). https://bugs.webkit.org/show_bug.cgi?id=271634
GraphicsContextGLANGLE does not validate clearBuffers value length
https://bugs.webkit.org/show_bug.cgi?id=271634
rdar://125222153
Reviewed by Dan Glastonbury.
Avoid passing too long or small arrays as GL_clearBuffer*v values.
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:
(WebCore::GraphicsContextGLANGLE::clearBufferiv):
(WebCore::GraphicsContextGLANGLE::clearBufferuiv):
(WebCore::GraphicsContextGLANGLE::clearBufferfv):
(WebCore::GraphicsContextGLANGLE::validateClearBufferv):
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h:
* Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestGraphicsContextGLCocoa.mm:
(TestWebKitAPI::TEST_F):
Canonical link: https://commits.webkit.org/272448.803@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.241@webkitglib/2.44
Commit: 605bed709013ec8202b994f836c78597da139e41
https://github.com/WebKit/WebKit/commit/605bed709013ec8202b994f836c78597da139e41
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/ipc/dirty-region-overflow-expected.txt
A LayoutTests/ipc/dirty-region-overflow.html
M Source/WebCore/platform/graphics/Region.cpp
M Source/WebCore/platform/graphics/Region.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 272448.816 at safari-7618-branch (63e5787d715c). https://bugs.webkit.org/show_bug.cgi?id=271741
Add IPC validation for `WebCore::Region::Shape`
https://bugs.webkit.org/show_bug.cgi?id=271741
rdar://125348548
Reviewed by Matt Woodrow.
* LayoutTests/ipc/dirty-region-overflow-expected.txt: Added.
* LayoutTests/ipc/dirty-region-overflow.html: Added.
* Source/WebCore/platform/graphics/Region.cpp:
(WebCore::Region::Shape::isValid const):
* Source/WebCore/platform/graphics/Region.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/272448.816@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.242@webkitglib/2.44
Commit: 9091cf27248d0185109dd39bd46134c016328db4
https://github.com/WebKit/WebKit/commit/9091cf27248d0185109dd39bd46134c016328db4
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A LayoutTests/ipc/validate-media-constraint-expected.txt
A LayoutTests/ipc/validate-media-constraint.html
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 272448.817 at safari-7618-branch (a734205bc9a9). https://bugs.webkit.org/show_bug.cgi?id=271816
Add IPC validation for `WebCore::MediaConstraint`
https://bugs.webkit.org/show_bug.cgi?id=271816
rdar://125343106
Reviewed by Pascoe.
* LayoutTests/ipc/validate-media-constraint-expected.txt: Added.
* LayoutTests/ipc/validate-media-constraint.html: Added.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/272448.817@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.243@webkitglib/2.44
Commit: 2eb29aa574ae1a1b8a6cf4dd5990bd3a3d5d9a92
https://github.com/WebKit/WebKit/commit/2eb29aa574ae1a1b8a6cf4dd5990bd3a3d5d9a92
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
A Source/WebKit/UIProcess/Cocoa/PickerDismissalReason.h
M Source/WebKit/UIProcess/Cocoa/WKContactPicker.h
M Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm
M Source/WebKit/UIProcess/Cocoa/WKShareSheet.h
M Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm
M Source/WebKit/UIProcess/ios/UIKitUtilities.h
M Source/WebKit/UIProcess/ios/UIKitUtilities.mm
M Source/WebKit/UIProcess/ios/WKContentView.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKPDFView.mm
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 272448.818 at safari-7618-branch (1db2f6a6a042). rdar://125046135
REGRESSION (272448.703 at safari-7618-branch): [iOS] <input type=file> camera capture instantly dismisses
rdar://125046135
Reviewed by Abrar Rahman Protyasha and Wenson Hsieh.
272448.703 at safari-7618-branch added logic to dismiss presented pickers, such as
the file upload panel, when the `WKWebView` was removed from the hierarchy. The
behavior is necessary to avoid scenarios where a picker can be displayed over a
site that's unrelated to the one requesting the information.
While that solution is correct for modal presentations, it is incorrect for
fullscreen presentations, which remove views from the hierarchy following
presentation. The camera view controller uses a fullscreen presentation.
Consequently, once it gets presented, the web view is removed from the
hierarchy, and following 272448.703 at safari-7618-branch, it is instantly
dismissed.
To fix, reduce the scope of the previous fix to exclude fullscreen presentations.
In this case, there is no need to dismiss presented view controllers, as the
web view content is already hidden.
Note that there is no way to detect whether a view was removed from the hierarchy
due to a fullscreen presentation. Consequently, the solution checks the status
of various presented pickers.
* Source/WebKit/UIProcess/Cocoa/PickerDismissalReason.h:
Introduce `PickerDismissalReason`s to control the dimissal behavior.
In particular, `ViewRemoved` now checks for fullscreen presentations, to avoid
instant dismissal.
* Source/WebKit/UIProcess/Cocoa/WKContactPicker.h:
* Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm:
(-[WKContactPicker dismissIfNeededWithReason:]):
* Source/WebKit/UIProcess/Cocoa/WKShareSheet.h:
* Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm:
(-[WKShareSheet dismissIfNeededWithReason:]):
* Source/WebKit/UIProcess/ios/UIKitUtilities.h:
* Source/WebKit/UIProcess/ios/UIKitUtilities.mm:
(-[UIViewController _wk_isInFullscreenPresentation]):
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView willMoveToWindow:]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView cleanUpInteraction]):
(-[WKContentView dismissFilePicker]):
(-[WKContentView _showShareSheet:inRect:completionHandler:]):
(-[WKContentView dismissPickersIfNeededWithReason:]):
(-[WKContentView dismissPickers]): Deleted.
* Source/WebKit/UIProcess/ios/WKPDFView.mm:
(-[WKPDFView dealloc]):
`ProcessExited` is used here, since it has the desired semantics.
In effect, the remote process of the host view controller is exited here.
(-[WKPDFView actionSheetAssistant:shareElementWithURL:rect:]):
* Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h:
* Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm:
(-[WKFileUploadPanel dismissIfNeededWithReason:]):
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::showShareSheet):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/272448.818@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.244@webkitglib/2.44
Commit: 7823ed2f90405961e0fae4c95352555265dff36c
https://github.com/WebKit/WebKit/commit/7823ed2f90405961e0fae4c95352555265dff36c
Author: Matthew Finkel <sysrqb at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
Log Message:
-----------
Cherry-pick 272448.832 at safari-7618-branch (61f821826ece). https://bugs.webkit.org/show_bug.cgi?id=271793
[cocoa] Explicitly check the file extension for webarchives when deciding quarantine
https://bugs.webkit.org/show_bug.cgi?id=271793
rdar://123902597
Reviewed by Brent Fulgham and Sihui Liu.
Currently we only check the string suffix to see if the requested file path is
a webarchive, but this isn't sufficient because the file extension isn't
guaranteed to be at the end of the string. This patch parses the string as a
file URL and then checks the file extension.
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::isQuarantinedAndNotUserApproved):
Canonical link: https://commits.webkit.org/272448.832@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.245@webkitglib/2.44
Commit: a7b995817b733dab2b83334a2b0eb15d19754bc4
https://github.com/WebKit/WebKit/commit/a7b995817b733dab2b83334a2b0eb15d19754bc4
Author: Pascoe <pascoe at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebCore/Modules/webauthn/fido/U2fResponseConverter.cpp
Log Message:
-----------
Cherry-pick 272448.931 at safari-7618-branch (595fc4594d77). https://bugs.webkit.org/show_bug.cgi?id=272698
Fix issue in createFidoAttestationStatementFromU2fRegisterResponse
https://bugs.webkit.org/show_bug.cgi?id=272698
rdar://125024119
Reviewed by Charlie Wolfe.
Since the x509 length here is user supplied, the addition of the offset
could overflow. We fix this issue by using the CheckedArithmetic header.
Canonical link: https://commits.webkit.org/272448.931@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.246@webkitglib/2.44
Commit: 4c39e2a089ba5ebe46c3a33ba2031068f9099239
https://github.com/WebKit/WebKit/commit/4c39e2a089ba5ebe46c3a33ba2031068f9099239
Author: Keith Miller <keith_miller at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h
M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp
M Source/JavaScriptCore/jit/ThunkGenerators.cpp
M Source/JavaScriptCore/llint/LLIntThunks.cpp
M Source/JavaScriptCore/runtime/Options.cpp
M Source/JavaScriptCore/runtime/OptionsList.h
M Source/WTF/wtf/PtrTag.h
M Source/WebKit/WebProcess/WebProcess.cpp
M Tools/Scripts/run-jsc-stress-tests
Log Message:
-----------
Cherry-pick f442fbe222f3. https://bugs.webkit.org/show_bug.cgi?id=272750
Make it harder to get a PAC signing gadget in JIT code.
https://bugs.webkit.org/show_bug.cgi?id=272750
rdar://125596635
Reviewed by Yusuke Suzuki.
Right now if an attacker can control where code is allocated they can overlap code to create a PAC bypass.
This patch makes that harder (in the WebContent process) by only allowing pacibsp and pacizb. This means
that during arity fixup we now tag the return PC with pacizb. This is ok because we don't use the zero
diversifier for anything. For reifying inlined call frames during OSR exit things are a bit more complicated.
First we have be careful to only move signed return addresses into lr then untag them there. Also, we have
to shuffle SP to point to where it would in reified frame. This means that there is technically live data
below our SP, which on many OSes causes problems. Talking to our kernel folks however this isn't a problem
as long as we don't have any signal handlers or run lldb expressions in this window. We don't use signal
handlers in the WebContent process and this patch tries to limit/document the window of JIT code where lldb
would trash the stack.
* Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::tagPtr):
* Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
(JSC::AssemblyHelpers::transferReturnPC):
* Source/JavaScriptCore/jit/ThunkGenerators.cpp:
(JSC::arityFixupGenerator):
* Source/JavaScriptCore/llint/LLIntThunks.cpp:
(JSC::LLInt::tagGateThunk):
(JSC::LLInt::untagGateThunk):
* Source/JavaScriptCore/runtime/OptionsList.h:
* Source/WTF/wtf/PtrTag.h:
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeProcess):
* Tools/Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/272448.948@safari-7618-branch
Canonical link: https://commits.webkit.org/272448.941@safari-7618.2.12.13-branch
Canonical link: https://commits.webkit.org/274313.247@webkitglib/2.44
Commit: d8509fbff591d5ba3f1db7dba6ae2c44e40be9e3
https://github.com/WebKit/WebKit/commit/d8509fbff591d5ba3f1db7dba6ae2c44e40be9e3
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/ThirdParty/ANGLE/src/compiler/translator/msl/Name.cpp
M Source/ThirdParty/ANGLE/src/compiler/translator/msl/TranslatorMSL.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp
Log Message:
-----------
Cherry-pick bce91c8033e3. https://bugs.webkit.org/show_bug.cgi?id=272750
WebGL fails to compile shaders with out variables that are arrays and start with underscore
rdar://126944294
Reviewed by Chris Dumez.
Integrates upstream commit:
commit e0e91b8cbb2e096d2d009cd0d1fbe20d785f2263
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: Mon Apr 22 18:11:30 2024 -0700
Metal: Fix rewritten out variables with underscores
Fix compilation in case of output variables start with underscores.
Make name emission always emit MSL name ANGLE_{name}, so that GLSL `_e`
and `e` cannot clash. This regressed in angleproject:8558.
Bug: b/335744344
Change-Id: Ibae4dba4a24888acc1461582e69d48218ba11176
Canonical link: https://commits.webkit.org/272448.959@safari-7618-branch
Canonical link: https://commits.webkit.org/272448.946@safari-7618.2.12.11-branch
Canonical link: https://commits.webkit.org/274313.248@webkitglib/2.44
Commit: 203ecc053827d64a27957b067b227b493f4ac9f9
https://github.com/WebKit/WebKit/commit/203ecc053827d64a27957b067b227b493f4ac9f9
Author: David Degazio <d_degazio at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
M Source/JavaScriptCore/bytecode/MetadataTable.cpp
M Source/JavaScriptCore/bytecode/MetadataTable.h
M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h
Log Message:
-----------
Cherry-pick 4cac7925aca4. https://bugs.webkit.org/show_bug.cgi?id=272787
[JSC] Mitigate null UnlinkedMetadataTable pointer in CodeBlock destructor
https://bugs.webkit.org/show_bug.cgi?id=272787
rdar://121747906
Reviewed by Yusuke Suzuki.
Attempts to fix a rare bug where the UnlinkedMetadataTable pointer accessed
in the CodeBlock destructor can become null. We think this may be due to a
series of thread-unsafe reference count operations that might allow the
destructor to happen twice, perhaps simultaneously on two threads. This
patch attempts to mitigate this by:
1. Making UnlinkedMetadataTable and MetadataTable thread-safe refcounted.
2. Checking for the presence of a null UnlinkedMetadataTable pointer in the
appropriate functions, and attempting to handle it nonfatally. This means
we skip updating the didOptimize state in the CodeBlock destructor, and
that we intentionally leak MetadataTables if they have this null pointer.
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
* Source/JavaScriptCore/bytecode/MetadataTable.cpp:
(JSC::MetadataTable::destroy):
(JSC::MetadataTable::sizeInBytesForGC):
* Source/JavaScriptCore/bytecode/MetadataTable.h:
(JSC::MetadataTable::forEachValueProfile):
(JSC::MetadataTable::valueProfileForOffset):
(JSC::MetadataTable::deref):
(JSC::MetadataTable::unlinkedMetadata const):
(JSC::MetadataTable::totalSize const):
* Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h:
Canonical link: https://commits.webkit.org/272448.937@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.249@webkitglib/2.44
Commit: 5a9234b48235fe47163c5fc603e4b786956f1d9b
https://github.com/WebKit/WebKit/commit/5a9234b48235fe47163c5fc603e4b786956f1d9b
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp
Log Message:
-----------
Cherry-pick bce91c8033e3. <bug>
WebGL fails to compile shaders with out variables that are arrays and start with underscore
rdar://126944294
Reviewed by Chris Dumez.
Integrates upstream commit:
commit e0e91b8cbb2e096d2d009cd0d1fbe20d785f2263
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: Mon Apr 22 18:11:30 2024 -0700
Metal: Fix rewritten out variables with underscores
Fix compilation in case of output variables start with underscores.
Make name emission always emit MSL name ANGLE_{name}, so that GLSL `_e`
and `e` cannot clash. This regressed in angleproject:8558.
Bug: b/335744344
Change-Id: Ibae4dba4a24888acc1461582e69d48218ba11176
Canonical link: https://commits.webkit.org/272448.959@safari-7618-branch
Canonical link: https://commits.webkit.org/272448.958@safari-7618.2.12.10-branch
Canonical link: https://commits.webkit.org/274313.250@webkitglib/2.44
Commit: 8f9e9493af4b730830a2988847ec1a61e7d036bd
https://github.com/WebKit/WebKit/commit/8f9e9493af4b730830a2988847ec1a61e7d036bd
Author: Pascoe <pascoe at apple.com>
Date: 2024-05-13 (Mon, 13 May 2024)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm
Log Message:
-----------
Cherry-pick 272448.740 at safari-7618-branch (c369f5018e91). https://bugs.webkit.org/show_bug.cgi?id=271003
PDFs should be downloaded in lockdown mode
https://bugs.webkit.org/show_bug.cgi?id=271003
rdar://124636755
Reviewed by Chris Dumez.
This functionality was first introduced in https://bugs.webkit.org/show_bug.cgi?id=237245, but
was disabled for macOS in https://bugs.webkit.org/show_bug.cgi?id=241741. This patch is to re-enable it.
This functionality should be covered by WKDownload.LockdownModePDF. Which is also fixed in this change
such that it fails whenever the conditional doesn't exist.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::decidePolicyForResponseShared):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm:
Canonical link: https://commits.webkit.org/272448.740@safari-7618-branch
Canonical link: https://commits.webkit.org/274313.251@webkitglib/2.44
Commit: f736325e66bfa8e85f85387299448476f3e1fb3c
https://github.com/WebKit/WebKit/commit/f736325e66bfa8e85f85387299448476f3e1fb3c
Author: Adrian Perez de Castro <aperez at igalia.com>
Date: 2024-05-14 (Tue, 14 May 2024)
Changed paths:
M Source/WebKit/wpe/NEWS
M Source/cmake/OptionsWPE.cmake
Log Message:
-----------
Unreviewed. Update OptionsWPE.cmake and NEWS for the 2.44.2 release
* Source/WebKit/wpe/NEWS: Add release notes for 2.44.2.
* Source/cmake/OptionsWPE.cmake: Bump version numbers.
Canonical link: https://commits.webkit.org/274313.252@webkitglib/2.44
Compare: https://github.com/WebKit/WebKit/compare/f6aae85eee6b...f736325e66bf
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list