[webkit-changes] [WebKit/WebKit] 2d9e8d: Cherry-pick 252432.1013 at safari-7614-branch (1d545c...
Adrian Perez
noreply at github.com
Thu Apr 6 00:01:37 PDT 2023
Branch: refs/heads/webkitglib/2.38
Home: https://github.com/WebKit/WebKit
Commit: 2d9e8d17062b4cd26a3831982148d59f365979f5
https://github.com/WebKit/WebKit/commit/2d9e8d17062b4cd26a3831982148d59f365979f5
Author: David Li <jingye_li at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/animations/animation-set-effect-expected.txt
A LayoutTests/animations/animation-set-effect.html
M Source/WebCore/animation/CSSAnimation.cpp
Log Message:
-----------
Cherry-pick 252432.1013 at safari-7614-branch (1d545c7ebfef). rdar://102137788
[Web Animations] CSSAnimation::setBindingsEffect should also add KeyFrames to overriddenProperties
rdar://102137788
Reviewed by Jonathan Bedard and Antoine Quint.
* LayoutTests/animations/animation-set-effect-expected.txt: Added.
* LayoutTests/animations/animation-set-effect.html: Added.
* Source/WebCore/animation/CSSAnimation.cpp:
(WebCore::CSSAnimation::setBindingsEffect):
Canonical link: https://commits.webkit.org/252432.1013@safari-7614-branch
Commit: 6f56628944ecb038d711aa4c9a7ada5a90c6165c
https://github.com/WebKit/WebKit/commit/6f56628944ecb038d711aa4c9a7ada5a90c6165c
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/streams/blob-and-then-expected.txt
A LayoutTests/streams/blob-and-then.html
M Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp
M Source/WebCore/Modules/streams/ReadableStreamSink.cpp
Log Message:
-----------
Cherry-pick 252432.1018 at safari-7614-branch (792c09f18dc7). https://bugs.webkit.org/show_bug.cgi?id=249996
Use-after-free in FetchBodyConsumer::resolve
https://bugs.webkit.org/show_bug.cgi?id=249996
rdar://103649054
Reviewed by Jonathan Bedard and Alex Christensen.
Make sure in FetchBodyConsumer that refed promise/source remain protected.
We also revert part of an unnecessary and wrong change from https://trac.webkit.org/changeset/227760.
This makes sure ReadableStreamToSharedBufferSink callback remains valid until completely executed in close case, as was the case in error case.
We use std::exchange instead of move as it is more semantically correct.
Covered by added test.
* LayoutTests/streams/blob-and-then-expected.txt: Added.
* LayoutTests/streams/blob-and-then.html: Added.
* Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp:
(WebCore::FetchBodyConsumer::resolveWithFormData):
(WebCore::FetchBodyConsumer::consumeFormDataAsStream):
(WebCore::FetchBodyConsumer::resolve):
* Source/WebCore/Modules/streams/ReadableStreamSink.cpp:
(WebCore::ReadableStreamToSharedBufferSink::close):
(WebCore::ReadableStreamToSharedBufferSink::error):
Canonical link: https://commits.webkit.org/252432.1018@safari-7614-branch
Commit: 1cf2bfc2c871117c6cdad044e4d8bd3c22235ad3
https://github.com/WebKit/WebKit/commit/1cf2bfc2c871117c6cdad044e4d8bd3c22235ad3
Author: David Li <jingye_li at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/editing/async-clipboard/clipboard-clear-expected.txt
A LayoutTests/editing/async-clipboard/clipboard-clear.html
M Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.cpp
M Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.h
Log Message:
-----------
Cherry-pick 252432.1019 at safari-7614-branch (1988807a5229). rdar://103307563
[Clipboard] Explicitly call completion on clearing ClipboardItemTypeLoader
rdar://103307563
Reviewed by Jonathan Bedard and Wenson Hsieh.
In m_itemTypeLoaders.clear(), ClipboardItemBindingsDataSource::invokeCompletionHandler() is called after all m_itemTypeLoaders released
and traverses the itemTypeLoaders after itemTypeLoaders is clear but before the size is updated, causing nullptr accessment.
So we should explicitly call completion before itemTypeLoader is released.
* LayoutTests/editing/async-clipboard/clipboard-clear-expected.txt: Added.
* LayoutTests/editing/async-clipboard/clipboard-clear.html: Added.
* Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.cpp:
(WebCore::ClipboardItemBindingsDataSource::clearItemTypeLoaders):
(WebCore::ClipboardItemBindingsDataSource::collectDataForWriting):
(WebCore::ClipboardItemBindingsDataSource::ClipboardItemTypeLoader::~ClipboardItemTypeLoader):
* Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.h:
Canonical link: https://commits.webkit.org/252432.1019@safari-7614-branch
Commit: b7cc7543a2888be18dc97ad3dee24ca6314179e8
https://github.com/WebKit/WebKit/commit/b7cc7543a2888be18dc97ad3dee24ca6314179e8
Author: JC Alvarado <joncarlo at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/fast/backgrounds/background-color-lch-crash-expected.txt
A LayoutTests/fast/backgrounds/background-color-lch-crash.html
M Source/WebCore/platform/graphics/ColorBlending.cpp
Log Message:
-----------
Cherry-pick 259548.8 at safari-7615-branch (5a0f792b008f). https://bugs.webkit.org/show_bug.cgi?id=251158
Check color opacity after lossy conversion when blending
https://bugs.webkit.org/show_bug.cgi?id=251158
rdar://104553839
Reviewed by Dean Jackson.
We check opacity to determine if we should forgo blending,
however after performing a lossy conversion we can end
up with alpha values that result in a division by zero.
Add an additional check after conversion to prevent this
case.
* LayoutTests/fast/backgrounds/background-color-lch-crash-expected.txt: Added.
* LayoutTests/fast/backgrounds/background-color-lch-crash.html: Added.
* Source/WebCore/platform/graphics/ColorBlending.cpp:
(WebCore::blendSourceOver):
Canonical link: https://commits.webkit.org/259548.8@safari-7615-branch
Commit: 0540d75da4b7211d7e74a108cae8141505a63d75
https://github.com/WebKit/WebKit/commit/0540d75da4b7211d7e74a108cae8141505a63d75
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/fast/css/content/quote-display-contents-crash-expected.txt
A LayoutTests/fast/css/content/quote-display-contents-crash.html
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Cherry-pick 256843.5 at webkit-2022.12-embargoed (312254f5776d). https://bugs.webkit.org/show_bug.cgi?id=248776
Check displayContentsChanged in destroyRenderTreeIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=248776
rdar://102807985>
Reviewed by Antti Koivisto.
Check displayContentsChanged in destroyRenderTreeIfNeeded since
display: contents may be removed due to focus removal while
removing subtrees but we still need to clean up pseudo elements.
* LayoutTests/fast/css/content/quote-display-contents-crash-expected.txt: Added.
* LayoutTests/fast/css/content/quote-display-contents-crash.html: Added.
* Source/WebCore/dom/ContainerNode.cpp:
(WebCore::destroyRenderTreeIfNeeded):
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::resolveComputedStyle):
Canonical link: https://commits.webkit.org/256843.5@webkit-2022.12-embargoed
Commit: e38bdebefe7cec01bf2dda3b88c0614d3a03243e
https://github.com/WebKit/WebKit/commit/e38bdebefe7cec01bf2dda3b88c0614d3a03243e
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 252432.1023 at safari-7614-branch (55c2b9caae92). https://bugs.webkit.org/show_bug.cgi?id=250408
[CoreIPC] Integer overflow in UIProcess from scaling/zoom factors
https://bugs.webkit.org/show_bug.cgi?id=250408
rdar://101222657
Reviewed by Wenson Hsieh and Jonathan Bedard.
Adds bounds checking via `MESSAGE_CHECK` to the page/plugin scale/zoom `factorDidChange`
methods in `WebPageProxy` to ensure that overflow will not occur in the web process.
The bounds were chosen to be `(0, 100]` because a factor of `<= 0.0` does not make sense,
and `100.0` ia a reasonable upper bound.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::pageScaleFactorDidChange):
(WebKit::WebPageProxy::pluginScaleFactorDidChange):
(WebKit::WebPageProxy::pluginZoomFactorDidChange):
Canonical link: https://commits.webkit.org/252432.1023@safari-7614-branch
Commit: fc155846543e2e0d0dd2debc2c76810bc8a9da4b
https://github.com/WebKit/WebKit/commit/fc155846543e2e0d0dd2debc2c76810bc8a9da4b
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
M Source/WebCore/Modules/contact-picker/ContactsManager.cpp
M Source/WebCore/Modules/contact-picker/ContactsManager.h
Log Message:
-----------
Cherry-pick 252432.1024 at safari-7614-branch (2ea437d75522). https://bugs.webkit.org/show_bug.cgi?id=250351
Use-after-free in ContactsManager::select
https://bugs.webkit.org/show_bug.cgi?id=250351
rdar://101241436
Reviewed by Wenson Hsieh and Jonathan Bedard.
`ContactsManager` can be destroyed prior to receiving the user's selection, which
is performed asynchronously. Deploy `WeakPtr` to avoid a use-after-free in this
scenario.
A test was unable to be added, as the failure scenario involves opening a new
Window, using the new Window object's `navigator.contacts`, and performing user
interaction. Creating a new Window results in the creation of a new web view,
however all of our existing UIScriptController hooks only apply to the original
(main) web view. Consequently, it is not possible to use our testing
infrastructure to dismiss the contact picker and trigger the callback in the
failure scenario.
* Source/WebCore/Modules/contact-picker/ContactsManager.cpp:
(WebCore::ContactsManager::select):
* Source/WebCore/Modules/contact-picker/ContactsManager.h:
Canonical link: https://commits.webkit.org/252432.1024@safari-7614-branch
Commit: 1aa6c196906c5a1e88ee73484a3f349dc751eebc
https://github.com/WebKit/WebKit/commit/1aa6c196906c5a1e88ee73484a3f349dc751eebc
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames-expected.txt
A LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames.html
M LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe-expected.txt
M LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
Log Message:
-----------
Cherry-pick 252432.1026 at safari-7614-branch (2a8469e53b2f). https://bugs.webkit.org/show_bug.cgi?id=248615
Remove inheritance of designMode attribute
https://bugs.webkit.org/show_bug.cgi?id=248615
Reviewed by Wenson Hsieh and Jonathan Bedard.
Stop making design mode inherit across frame boundaries.
This will prevent a form element from being injected into a victim page via drag & drop
and the new behavior matches that of Firefox and Chrome.
* LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames-expected.txt: Added.
* LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames.html: Added.
* LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe-expected.txt:
* LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe.html:
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setDesignMode):
(WebCore::Document::inDesignMode const): Deleted.
* Source/WebCore/dom/Document.h:
(WebCore::Document::inDesignMode const):
Canonical link: https://commits.webkit.org/252432.1026@safari-7614-branch
Commit: e33db0128c6d4ceadf5eed5c0b8859ac8f07612b
https://github.com/WebKit/WebKit/commit/e33db0128c6d4ceadf5eed5c0b8859ac8f07612b
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A JSTests/wasm/stress/wasm-tuple-return.js
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Cherry-pick 252432.1029 at safari-7614-branch (9dda7bfe768d). https://bugs.webkit.org/show_bug.cgi?id=250482
LLInt WASM argument locals must be read before return values are written
https://bugs.webkit.org/show_bug.cgi?id=250482
rdar://103551585
Reviewed by Justin Michaud.
Given the wasm code which exports a wasm function `intFuncRef2` as a js function.
```
(func (export "intFuncRef2") (param $p0 f32) (param $p1 funcref) (result i32 funcref)
(i32.const 42)
(local.get $p1)
(return)
)
```
The corresponding dumped bytecodes show
```
[ 0] enter
[ 1] mov dst:loc2, src:42(const0)
[ 4] mov dst:loc3, src:loc2 // loc2 contains the funcref but now replaced with 42
[ 7] ret // return [loc2, loc3]
```
which is wrong. Instead we should do
```
[ 0] enter
[ 1] mov dst:loc18, src:42(const0)
[ 4] mov dst:loc19, src:loc2
[ 7] mov dst:loc2, src:loc18
[ 10] mov dst:loc3, src:loc19
[ 13] ret
```
Note that loc2 is both parameter and return lot.
Locals usually need to be materialized on wasm stack when they are about to be or could
be clobbered, usually before a control entry, a branch, or redefinition. Previously,
Return writes only one value to the result slot that clobber one argument slot which
is fine. Since now wasm function can return tuple that might bring us to the situation
as shown in above example. We should materialize expression stack when return more than
one values.
* JSTests/wasm/stress/tuple-return.js: Added.
(async test):
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addReturn):
Canonical link: https://commits.webkit.org/252432.1029@safari-7614-branch
Commit: b259c46492e94099fed6fd995b6cc72025af1104
https://github.com/WebKit/WebKit/commit/b259c46492e94099fed6fd995b6cc72025af1104
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
M Source/WebCore/bindings/js/JSErrorHandler.cpp
M Source/WebCore/bindings/js/JSEventListener.cpp
M Source/WebCore/bindings/js/JSEventListener.h
M Source/WebCore/bindings/js/JSLazyEventListener.cpp
M Source/WebCore/bindings/js/WebCoreJSClientData.cpp
M Source/WebCore/bindings/js/WebCoreJSClientData.h
M Source/WebCore/dom/EventTarget.cpp
M Source/WebCore/inspector/CommandLineAPIHost.cpp
M Source/WebCore/inspector/WebInjectedScriptHost.cpp
M Source/WebCore/inspector/agents/InspectorDOMAgent.cpp
Log Message:
-----------
Cherry-pick 252432.1030 at safari-7614-branch (433db4f29219). https://bugs.webkit.org/show_bug.cgi?id=246022
Heap use-after-free in DOMWrapperWorld::~DOMWrapperWorld
https://bugs.webkit.org/show_bug.cgi?id=246022
rdar://100763856
Reviewed by Jonathan Bedard and Ryosuke Niwa.
Right before a worker terminates, it destroys its WorkerOrWorkletScriptController,
which destroys the JS VM. Certain objects like DOMWrapperWorld cannot outlive
the VM since they keep a `VM&' as data member. However, DOMWrapperWorld is
refcounted and JSEventListeners hold a strong ref to their DOMWrapperWorld. If
JSEventListeners outlive the VM, then it would lead to a use-after free in the
DOMWrapperWorld destructor when destroying those JSEventListeners later on.
We have previously made several attempts to try and unregister all event
listeners before destroying the VM. However, those attempts were either
incomplete or led to other crashes. I am therefore trying a different approach
this time.
JSEventListeners now register themselves as client of the JSVMClientData (which
is owned by the VM) and the client gets a `willDestroyVM()` call before the
VM gets destroyed. This allows JSEventListeners to clear out their data members
which rely on the VM (DOMWrapperWorld and JSC::Weak data members).
* Source/WebCore/bindings/js/JSErrorHandler.cpp:
(WebCore::JSErrorHandler::handleEvent):
* Source/WebCore/bindings/js/JSEventListener.cpp:
(WebCore::JSEventListener::JSEventListener):
(WebCore::JSEventListener::handleEvent):
(WebCore::JSEventListener::functionName const):
(WebCore::JSEventListener::willDestroyVM):
* Source/WebCore/bindings/js/JSEventListener.h:
(WebCore::JSEventListener::isolatedWorld const):
(WebCore::JSEventListener::ensureJSFunction const):
* Source/WebCore/bindings/js/JSLazyEventListener.cpp:
(WebCore::JSLazyEventListener::initializeJSFunction const):
* Source/WebCore/bindings/js/WebCoreJSClientData.cpp:
(WebCore::JSVMClientData::~JSVMClientData):
* Source/WebCore/bindings/js/WebCoreJSClientData.h:
(WebCore::JSVMClientData::addClient):
* Source/WebCore/dom/EventTarget.cpp:
(WebCore::EventTarget::attributeEventListener):
* Source/WebCore/inspector/CommandLineAPIHost.cpp:
(WebCore::CommandLineAPIHost::getEventListeners):
* Source/WebCore/inspector/WebInjectedScriptHost.cpp:
(WebCore::objectForEventTargetListeners):
* Source/WebCore/inspector/agents/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::buildObjectForEventListener):
Canonical link: https://commits.webkit.org/252432.1030@safari-7614-branch
Commit: d88b287a63e20e9568878c41a0675cd708223b81
https://github.com/WebKit/WebKit/commit/d88b287a63e20e9568878c41a0675cd708223b81
Author: David Degazio <35146201+ddegazio at users.noreply.github.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A JSTests/stress/cell-speculated-array-indexof.js
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
Log Message:
-----------
Cherry-pick 252432.1031 at safari-7614-branch (9f7e401c42a8). https://bugs.webkit.org/show_bug.cgi?id=250429
Fix use-after-free in DFGFixupPhase for array indexOf
https://bugs.webkit.org/show_bug.cgi?id=250429
rdar://103852510
Reviewed by Jonathan Bedard and Michael Saboff.
During DFG fixup, array indexOf nodes are folded to -1 when the search element is speculated
to be a different type than the array element (for instance, JSCell instead of Int32). When
this happens, a speculation check is inserted, which can cause the DFG graph's varArgChildren
array to reallocate. This invalidates the searchElement Edge reference, which we use
immediately after the check insertion in the fixup phase. This patch fixes this potential
use-after-free by grabbing the searchElement's associated node before inserting any checks,
giving us a persistent pointer to a DFG node rather than a reference into a vector.
* JSTests/stress/cell-speculated-array-indexof.js: Added.
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArrayIndexOf):
Canonical link: https://commits.webkit.org/252432.1031@safari-7614-branch
Commit: 9eb3235086b2d3fc0a403d05f55ac9ad43d1130f
https://github.com/WebKit/WebKit/commit/9eb3235086b2d3fc0a403d05f55ac9ad43d1130f
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp
Log Message:
-----------
Cherry-pick 252432.1033 at safari-7614-branch (02e324c57689). https://bugs.webkit.org/show_bug.cgi?id=250742
Possible type confusion bug in RemoteScrollingCoordinatorTransaction::decode
https://bugs.webkit.org/show_bug.cgi?id=250742
<rdar://102373218>
Reviewed by Jonathan Bedard and Ryosuke Niwa.
RemoteScrollingCoordinatorTransaction::decode() fails to check whether the nodeID returned by
`m_scrollingStateTree->insertNode()` is a new one, different from the `nodeID` argument. If so, it
could indicate that the node type of `m_scrollingStateTree->stateNodeForID()` does not match
`nodeType`, leading to type confusion.
In the UI process, `m_scrollingStateTree->insertNode()` should never return a different nodeID; this
only happens when the given nodeType does not match the type of the existing node, which only
happens in the WebProcess. So if `insertNode()` returns a different nodeID, or when the returned
node doesn't have the expected type, we can consider it an IPC decoding error.
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
(WebKit::RemoteScrollingCoordinatorTransaction::decode):
Canonical link: https://commits.webkit.org/252432.1033@safari-7614-branch
Commit: a0e7a17da75ef3860efcc579682979d6482df62f
https://github.com/WebKit/WebKit/commit/a0e7a17da75ef3860efcc579682979d6482df62f
Author: Ryan Reno <rreno at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html
M Source/WebCore/page/csp/ContentSecurityPolicySource.cpp
Log Message:
-----------
Cherry-pick 252432.1034 at safari-7614-branch (3ee4a8321986). https://bugs.webkit.org/show_bug.cgi?id=250709
CSP bypass due to incorrect handling of wildcard character in host expression
https://bugs.webkit.org/show_bug.cgi?id=250709
rdar://104335301
Reviewed by Brent Fulgham and Jonathan Bedard.
We were treating something like "https://*/foo" as being a scheme-only source (so checking only against
'https'). That is fixed by not only checking for the host-part being an empty string but also whether or not
the host wildcard flag had been set by the CSP parser. Additionally, we were checking a given URL's host
against the wildcard assuming a format like "*.com" instead of the possibility of the catch-all "*" wildcard.
This change fixes our handling of the wildcard "*" in a directive's source list by correctly identifying when a
source is scheme-only and by correctly taking into account the entire host-part wildcard grammar when checking
a given host against a wildcard pattern.
* LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html: Added.
* Source/WebCore/page/csp/ContentSecurityPolicySource.cpp:
(WebCore::ContentSecurityPolicySource::hostMatches const):
(WebCore::ContentSecurityPolicySource::isSchemeOnly const):
Canonical link: https://commits.webkit.org/252432.1034@safari-7614-branch
Commit: 4081ff08dd2f75678d5d1261e43a5fcb39c5f22c
https://github.com/WebKit/WebKit/commit/4081ff08dd2f75678d5d1261e43a5fcb39c5f22c
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A JSTests/stress/regexp-testinline-stacklimits.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/runtime/RegExp.h
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
Cherry-pick 252432.1036 at safari-7614-branch (c553da3adc35). https://bugs.webkit.org/show_bug.cgi?id=250873
[JSC] RegExp.test inline is missing some stack overflow checks
https://bugs.webkit.org/show_bug.cgi?id=250873
rdar://104072550
Reviewed by Yusuke Suzuki.
The RegExp.test inline code is missing two stack overflow checks.
1) When compiling the pattern string to a YarrPattern, we checked for stack overflow,
but didn't do anything with the failure.
2) When allocating the stack space needed to execute the JIT code for the expression
we need to first check that we have enough stack.
This change adds checks for both cases using the JSRegExpResult::JITCodeFailure return value when we
would have overflowed the stack. The results checking code after the inline code sees that error
value, it will now call out to the appropriate C++ helper function to perform the match.
Those functions are capable of throwing Out of Stack exceptions.
* JSTests/stress/regexp-testinline-stacklimits.js: Added new test.
(baz):
(bar):
(foo):
(true.string_appeared_here.repeat):
(true.catch):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileRegExpTestInline):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/runtime/RegExp.h:
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
(JSC::Yarr::jitCompileInlinedTest):
Canonical link: https://commits.webkit.org/252432.1036@safari-7614-branch
Commit: af243f7e4bad24a7f73020e769d65e770c8b5c33
https://github.com/WebKit/WebKit/commit/af243f7e4bad24a7f73020e769d65e770c8b5c33
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/fast/table/table-cell-crash-when-detached-state-2-expected.txt
A LayoutTests/fast/table/table-cell-crash-when-detached-state-2.html
M Source/WebCore/rendering/RenderLayerModelObject.cpp
Log Message:
-----------
Cherry-pick 256843.4 at webkit-2022.12-embargoed (6234ec9c65b9). https://bugs.webkit.org/show_bug.cgi?id=248773
Do not issue repaints when in detached state
https://bugs.webkit.org/show_bug.cgi?id=248773
Reviewed by Antti Koivisto.
Do not issue repaints when the RenderObject is in detached state while removing render subtrees.
* LayoutTests/fast/table/table-cell-crash-when-detached-state-2-expected.txt: Added.
* LayoutTests/fast/table/table-cell-crash-when-detached-state-2.html: Added.
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderTableCell::willBeRemovedFromTree const):
Canonical link: https://commits.webkit.org/256843.4@webkit-2022.12-embargoed
Commit: 7d6706a79c077314d506f036bc5a233aac39bb9b
https://github.com/WebKit/WebKit/commit/7d6706a79c077314d506f036bc5a233aac39bb9b
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A JSTests/wasm/stress/many-locals-small-wasm-stack.js
A JSTests/wasm/stress/many-locals-small-wasm-stack.wasm
A JSTests/wasm/stress/many-locals-small-wasm-stack.wat
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Cherry-pick 259548.25 at safari-7615-branch (1a20160f826c). rdar://104692168
Locals should update max stack size
rdar://104692168
Reviewed by Yusuke Suzuki.
We can forget to update the max stack size, causing an OOB stack read in
OSR entry. This only happens if you create a bunch of locals and never
push anything to the stack, so it should be very rare and difficult to
abuse.
* JSTests/wasm/stress/many-locals-small-wasm-stack.js: Added.
(async let):
* JSTests/wasm/stress/many-locals-small-wasm-stack.wasm: Added.
* JSTests/wasm/stress/many-locals-small-wasm-stack.wat: Added.
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addLocal):
Canonical link: https://commits.webkit.org/259548.25@safari-7615-branch
Commit: 6395974018aad3d9f2969e0c65cee8ff20bf05d6
https://github.com/WebKit/WebKit/commit/6395974018aad3d9f2969e0c65cee8ff20bf05d6
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-04-05 (Wed, 05 Apr 2023)
Changed paths:
A LayoutTests/fast/dom/set-outer-text-on-moved-element-expected.html
A LayoutTests/fast/dom/set-outer-text-on-moved-element.html
M Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
Log Message:
-----------
Cherry-pick 256843.6 at webkit-2022.12-embargoed (c4c0ef6360b2). https://bugs.webkit.org/show_bug.cgi?id=248775
Verify that style update roots are for correct document
https://bugs.webkit.org/show_bug.cgi?id=248775
Reviewed by Antti Koivisto.
Verify that style update roots are for the correct document since
we may be dealing with a pending update on an element/text node that
moved to another document.
* LayoutTests/fast/dom/set-outer-text-on-moved-element-expected.html: Added.
* LayoutTests/fast/dom/set-outer-text-on-moved-element.html: Added.
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::commit):
Canonical link: https://commits.webkit.org/256843.6@webkit-2022.12-embargoed
Commit: ed0f829ea48e3a7c6c3c74f887b3e4f2a8c05ba7
https://github.com/WebKit/WebKit/commit/ed0f829ea48e3a7c6c3c74f887b3e4f2a8c05ba7
Author: Adrian Perez de Castro <aperez at igalia.com>
Date: 2023-04-06 (Thu, 06 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/cairo/CairoUtilities.cpp
M Source/WebKit/UIProcess/WebPasteboardProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebPlatformStrategies.cpp
Log Message:
-----------
Unreviewed build fixes after 2a5102da30b5
* Source/WebCore/platform/graphics/cairo/CairoUtilities.cpp:
(WebCore::getDefaultCairoFontOptions): Deleted. There is an equivalent
function with the same name in GdkCairoUtilities.cpp.
* Source/WebKit/UIProcess/WebPasteboardProxy.messages.in: Mark message
GetPasteboardChangeCount as needing a connection.
* Source/WebKit/WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:
(WebKit::WebPlatformStrategies::changeCount): Adapt to older sendSync()
that receives a reference to the return values container for IPC messages.
Compare: https://github.com/WebKit/WebKit/compare/d897c7223498...ed0f829ea48e
More information about the webkit-changes
mailing list