[webkit-changes] [WebKit/WebKit] 3d5ebb: Cherry-pick 256843.5 at webkit-2022.12-embargoed (312...
Michael Saboff
noreply at github.com
Thu Mar 30 11:57:12 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3d5ebb9e2ca0a1c9c2dbaab5ff8a00642709eb47
https://github.com/WebKit/WebKit/commit/3d5ebb9e2ca0a1c9c2dbaab5ff8a00642709eb47
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107366942
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
Canonical link: https://commits.webkit.org/262348@main
Commit: 0ef90805bce10ad4a40adcf8f4a32f72dfbcfa25
https://github.com/WebKit/WebKit/commit/0ef90805bce10ad4a40adcf8f4a32f72dfbcfa25
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 2023)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKitLegacy/mac/WebView/WebJSPDFDoc.mm
Log Message:
-----------
Cherry-pick 252432.1017 at safari-7614-branch (94d37ad7d541). rdar://107366983
WebKit`WebKit::PDFPlugin::jsPDFDocPrint - type confusion
https://bugs.webkit.org/show_bug.cgi?id=249169
rdar://102740487
Reviewed by Tim Horton, Yusuke Suzuki and Jonathan Bedard.
When JavaScript is embedded inside a PDF and it invokes the `print()` function,
the `thisObject` parameter in `PDFPlugin::jsPDFDocPrint` is not guaranteed
to be the proper type. Currently, we errenously assume it always is the proper
type, and cast it to `PDFPlugin *`, which results in an object with garbage values.
This PR protects against this by first checking if the `thisObject` is the correct
JavaScript object type, before trying to cast it.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::jsPDFDocClass):
(WebKit::PDFPlugin::jsPDFDocPrint):
(WebKit::PDFPlugin::makeJSPDFDoc):
Canonical link: https://commits.webkit.org/252432.1017@safari-7614-branch
Canonical link: https://commits.webkit.org/262349@main
Commit: af3036aa875162ca4088700b8f57f915eec6e36c
https://github.com/WebKit/WebKit/commit/af3036aa875162ca4088700b8f57f915eec6e36c
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 252432.1023 at safari-7614-branch (55c2b9caae92). rdar://107367011
[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
Canonical link: https://commits.webkit.org/262350@main
Commit: c09257499fe971a4134ca8ebab4d642ef4323660
https://github.com/WebKit/WebKit/commit/c09257499fe971a4134ca8ebab4d642ef4323660
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107367090
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
Canonical link: https://commits.webkit.org/262351@main
Commit: d1805dadb324be69abc61da1fde86e880573fb92
https://github.com/WebKit/WebKit/commit/d1805dadb324be69abc61da1fde86e880573fb92
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107367418
Remove inheritance of designMode attribute
https://bugs.webkit.org/show_bug.cgi?id=248615
rdar://102868995
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
Canonical link: https://commits.webkit.org/262352@main
Commit: 936a61795aa447fe1de2039a7d87e19f4ddbc599
https://github.com/WebKit/WebKit/commit/936a61795aa447fe1de2039a7d87e19f4ddbc599
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107367461
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
Canonical link: https://commits.webkit.org/262353@main
Commit: f317e5e7b17ad20bd653507fd956cd0251266bf6
https://github.com/WebKit/WebKit/commit/f317e5e7b17ad20bd653507fd956cd0251266bf6
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp
Log Message:
-----------
Cherry-pick 252432.1033 at safari-7614-branch (02e324c57689). rdar://107367530
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
Canonical link: https://commits.webkit.org/262354@main
Commit: 9f34042e08500512243b35f5a0d01122fd82cdc6
https://github.com/WebKit/WebKit/commit/9f34042e08500512243b35f5a0d01122fd82cdc6
Author: Ryan Reno <rreno at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107367566
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
Canonical link: https://commits.webkit.org/262355@main
Commit: b73837418b94ac2065418bbf068c0560b676bb89
https://github.com/WebKit/WebKit/commit/b73837418b94ac2065418bbf068c0560b676bb89
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-03-30 (Thu, 30 Mar 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). rdar://107367612
[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
Canonical link: https://commits.webkit.org/262356@main
Compare: https://github.com/WebKit/WebKit/compare/7e8e4a4f559c...b73837418b94
More information about the webkit-changes
mailing list