Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8b2e50918a1c6a0c064267a241b81c5b6f01115e
https://github.com/WebKit/WebKit/commit/8b2e50918a1c6a0c064267a241b81c5b6f01115e
Author: Erica Li <ler...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
A
LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash-expected.txt
A LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash.html
M Source/WebCore/rendering/RenderTable.cpp
Log Message:
-----------
ASAN_ILL | WebCore::RenderTableSection::layoutRows;
WebCore::RenderTable::simplifiedNormalFlowLayout;
WebCore::RenderBlock::simplifiedLayout.
https://bugs.webkit.org/show_bug.cgi?id=267198
rdar://113940614
Reviewed by Alan Baradlay.
Always setChildNeedsLayout for sections to make sure normalChildNeedsLayout is
flagged,
as for pagination we need to run a full layout on child table sections even
when the initial change,
otherwise requires simplified layout only.
*
LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash-expected.txt:
Added.
* LayoutTests/fast/multicol/pagination/pagination-diry-sections-crash.html:
Added.
*
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt:
re-baseline again, adding end of line back.
* Source/WebCore/rendering/RenderTable.cpp:
(WebCore::RenderTable::markForPaginationRelayoutIfNeeded):
Originally-landed-as: 272448.104@safari-7618-branch (8737c0374652).
rdar://124556239
Canonical link: https://commits.webkit.org/276103@main
Commit: ceb7e89febcd92b46d65396ce68e0d58ae6bcd6e
https://github.com/WebKit/WebKit/commit/ceb7e89febcd92b46d65396ce68e0d58ae6bcd6e
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
A JSTests/stress/regress-120777816.js
M Source/JavaScriptCore/builtins/ProxyHelpers.js
M Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.h
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h
M Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/runtime/ProxyObject.cpp
Log Message:
-----------
[JSC] get_by_id_with_this + ProxyObject can leak JSScope objects
https://bugs.webkit.org/show_bug.cgi?id=267425
<rdar://120777816>
Reviewed by Yusuke Suzuki and Justin Michaud.
According to the spec [1], `var base = { foo }; with (base) foo();` should be
called with `this`
value of `base`, which is why FunctionCallResolveNode moves resolved scope to
thisRegister().
That is arguably a bad design, and there is an effort [2] to abolish using
JSScope as `this` value.
When `this` value is accessed by JS code, it's being sanitized via ToThis
(JSScope replaced with
`undefined`), yet not in case of `super.property` access calling into
ProxyObject `get` trap,
which passes raw `this` value as receiver parameter, leaking JSScope to be
exploited.
For performance reasons, we can't call toThis() whenever `get_by_id_with_this`
is used, so this
change introduces @toThis() intrinsic specifically for ProxyObject IC helpers,
tweaks DFG to respect
`m_srcDst`, and also fixes baseline code.
Inlineability of ProxyObject IC helpers was verified to remain unaffected
(`performProxyObjectGet`
is smaller then 120 while other helpers were already exceeding inline size
limit).
[1]: https://tc39.es/ecma262/#sec-evaluatecall (step 1.b.iii)
[2]: https://bugs.webkit.org/show_bug.cgi?id=225397
* JSTests/stress/regress-120777816.js: Added.
* Source/JavaScriptCore/builtins/ProxyHelpers.js:
(linkTimeConstant.performProxyObjectGet):
(linkTimeConstant.performProxyObjectGetByVal):
(linkTimeConstant.performProxyObjectSetSloppy):
(linkTimeConstant.performProxyObjectSetStrict):
* Source/JavaScriptCore/bytecode/BytecodeIntrinsicRegistry.h:
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitToThis):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitToThis):
* Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_toThis):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::getThis): Deleted.
(JSC::DFG::ByteCodeParser::setThis): Deleted.
* Source/JavaScriptCore/runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performPut):
Originally-landed-as: 272448.103@safari-7618-branch (e3a75800fe85).
rdar://124556295
Canonical link: https://commits.webkit.org/276104@main
Commit: ffe58e2be703e4f6b69eb8c315b1c186676bb4b5
https://github.com/WebKit/WebKit/commit/ffe58e2be703e4f6b69eb8c315b1c186676bb4b5
Author: Alan Baradlay <za...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
A
LayoutTests/fast/inline/dynamic-inline-content-with-out-of-flow-child-expected.txt
A LayoutTests/fast/inline/dynamic-inline-content-with-out-of-flow-child.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Invalidate existing inline layout content when simplified out-of-flow is
sufficient
https://bugs.webkit.org/show_bug.cgi?id=267487
rdar://120496542
Reviewed by Antti Koivisto.
Do not leave stale inline content around.
*
LayoutTests/fast/inline/dynamic-inline-content-with-out-of-flow-child-expected.txt:
Added.
* LayoutTests/fast/inline/dynamic-inline-content-with-out-of-flow-child.html:
Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutModernLines):
Originally-landed-as: 272448.102@safari-7618-branch (6d2f579ca0ad).
rdar://124556312
Canonical link: https://commits.webkit.org/276105@main
Commit: 4e7c454bf50238f063d9614230027e7d1c1f5cd7
https://github.com/WebKit/WebKit/commit/4e7c454bf50238f063d9614230027e7d1c1f5cd7
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
M Source/JavaScriptCore/runtime/CommonSlowPaths.h
M Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp
M Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp
M Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp
M Source/JavaScriptCore/runtime/JSFunction.cpp
M Source/JavaScriptCore/runtime/JSFunction.h
M Source/JavaScriptCore/runtime/JSFunctionInlines.h
Log Message:
-----------
[JSC] setHasModifiedLengthForBoundOrNonHostFunction and
setHasModifiedNameForBoundOrNonHostFunction shouldn't be called if it fails to
reify the property
https://bugs.webkit.org/show_bug.cgi?id=267380
rdar://118761737
Reviewed by Yusuke Suzuki.
setHasModifiedLengthForBoundOrNonHostFunction and
setHasModifiedNameForBoundOrNonHostFunction
can be called if JSFunction::put() fails to reify the property. This case may
cause inconsistency between the AI and the runtime environment.
* Source/JavaScriptCore/runtime/JSFunction.cpp:
(JSC::JSFunction::put):
Originally-landed-as: 272448.101@safari-7618-branch (70ca9c1f54a0).
rdar://124556382
Canonical link: https://commits.webkit.org/276106@main
Commit: 93603245b1ebc4cd2c451af93d98c86533c0d6fe
https://github.com/WebKit/WebKit/commit/93603245b1ebc4cd2c451af93d98c86533c0d6fe
Author: Ryan Reno <rr...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part.py
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part.py
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/DocumentLoader.h
Log Message:
-----------
Content-Type x-mixed-replace can be abused to bypass CSP
https://bugs.webkit.org/show_bug.cgi?id=264811
rdar://118394343
Reviewed by John Wilander and Brent Fulgham.
When replacing the document in a multipart/x-mixed-replace response, the
DocumentLoader would reset its CSP every time a new response was received.
This change makes the CSP persistent across document replacements when
loading multipart content. Now the CSP can only become more restrictive
as new parts are received.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-three-part.py:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part-expected.txt:
Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/multipart-two-part.py:
Added.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::shouldClearContentSecurityPolicyForResponse const):
(WebCore::DocumentLoader::responseReceived):
* Source/WebCore/loader/DocumentLoader.h:
Originally-landed-as: 272448.100@safari-7618-branch (7f3ac60a98fc).
rdar://124556491
Canonical link: https://commits.webkit.org/276107@main
Commit: 18b2179221761d08ccea246b4f4f36ec24e9cc5e
https://github.com/WebKit/WebKit/commit/18b2179221761d08ccea246b4f4f36ec24e9cc5e
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2024-03-14 (Thu, 14 Mar 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Should crash when deserializing JSArray object containing named property
length
https://bugs.webkit.org/show_bug.cgi?id=267036
rdar://120410983
Reviewed by Sihui Liu and Mark Lam.
`length` is treated as a special property in JSArray. There shouldn't
be any named property `length` in JSArray. So, should crash when
deserializing JSArray object containing named property `length`.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::serialize):
(WebCore::CloneDeserializer::objectStartVisitMember):
(WebCore::CloneDeserializer::objectEndVisitMember):
(WebCore::CloneDeserializer::deserialize):
Originally-landed-as: 272448.74@safari-7618-branch (7bd07231e704).
rdar://124556898
Canonical link: https://commits.webkit.org/276108@main
Compare: https://github.com/WebKit/WebKit/compare/9854e2932ee2...18b217922176
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
