Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: ae98f7b3181b76c6ca9917814709899abbc9eba1
https://github.com/WebKit/WebKit/commit/ae98f7b3181b76c6ca9917814709899abbc9eba1
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/fast/inline/layoutBox-null-deref-crash-on-repaint-expected.txt
A LayoutTests/fast/inline/layoutBox-null-deref-crash-on-repaint.html
M Source/WebCore/rendering/RenderInline.cpp
Log Message:
-----------
Cherry-pick 259548.678@safari-7615-branch (7c662f5b36e3).
https://bugs.webkit.org/show_bug.cgi?id=255552.
Renderinline::offsetForInFlowPositionedInline causes a null-deref of a
laybox on repaint.
https://bugs.webkit.org/show_bug.cgi?id=255552.
rdar://107952390.
Reviewed by Alan Baradlay.
Line layout codepath invalidation is triggered by JS which issues a repaint
on the newly inserted renderer. The newly inserted renderer is used for
geometry computations and which calls offsetForInFlowPositionedInline in case
of inline boxes. This tries to access the lineBoxes assocaited with the
renderers but they invalidated by previous repaints. This leads to null deref
of the lineboxes.
*
LayoutTests/fast/inline/layoutBox-null-deref-crash-on-repaint-expected.txt:
Added.
* LayoutTests/fast/inline/layoutBox-null-deref-crash-on-repaint.html: Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::isLineLayoutPresent const):
* Source/WebCore/rendering/RenderBlockFlow.h:
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::offsetForInFlowPositionedInline const):
Canonical link: https://commits.webkit.org/259548.678@safari-7615-branch
Commit: a0610381408a875a2edc1127f61c8b9ae90e0074
https://github.com/WebKit/WebKit/commit/a0610381408a875a2edc1127f61c8b9ae90e0074
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/regress-255806.js
M Source/JavaScriptCore/runtime/StringPrototype.cpp
Log Message:
-----------
Cherry-pick 259548.689@safari-7615-branch (a75d564e8c5f).
https://bugs.webkit.org/show_bug.cgi?id=255806
jsc_fuzz: ASSERTION FAILED: !is8Bit() || isEmpty() in
stringProtoFuncToWellFormed()
https://bugs.webkit.org/show_bug.cgi?id=255806
<rdar://108256807>
Reviewed by Yusuke Suzuki.
It's necessary to resolve a rope to determine if a string is 8-bit:
JSRopeString's is8BitInPointer merely
implies it can be represented as 8-bit, but after the rope is resolved, it
can become a 16-bit string.
* JSTests/stress/regress-255806.js: Added.
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
Canonical link: https://commits.webkit.org/259548.689@safari-7615-branch
Commit: 0fe701393004d6f0e1df461645985de53d313477
https://github.com/WebKit/WebKit/commit/0fe701393004d6f0e1df461645985de53d313477
Author: Yusuke Suzuki <ysuz...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/marked-buffer-fill-should-be-gc-aware.js
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
M Source/JavaScriptCore/runtime/ArgList.h
Log Message:
-----------
Cherry-pick 259548.690@safari-7615-branch (b05050e0cc00).
https://bugs.webkit.org/show_bug.cgi?id=255951
[JSC] MarkedVector::fill should register itself as a root
https://bugs.webkit.org/show_bug.cgi?id=255951
rdar://108261913
Reviewed by Alexey Shvayka and Justin Michaud.
1. MarkedVector::fill is not registering itself as a strong root of GC.
This patch fixes it with m_markSet->add.
2. Initialize buffer with empty value in MarkedVector::fill. This buffer
can be scanned via GC when GC is invoked from
a passed lambda.
* JSTests/stress/marked-buffer-fill-should-be-gc-aware.js: Added.
(foo):
* Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleVarargsCheckpoint):
* Source/JavaScriptCore/runtime/ArgList.h:
(JSC::MarkedVector::fill):
Canonical link: https://commits.webkit.org/259548.690@safari-7615-branch
Commit: e5958f914416c14e02ff967a16257409315944e9
https://github.com/WebKit/WebKit/commit/e5958f914416c14e02ff967a16257409315944e9
Author: Alex Christensen <achristen...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/platform/graphics/transforms/IdentityTransformOperation.h
M Source/WebCore/platform/graphics/transforms/Matrix3DTransformOperation.h
M Source/WebCore/platform/graphics/transforms/MatrixTransformOperation.h
M
Source/WebCore/platform/graphics/transforms/PerspectiveTransformOperation.h
M Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp
M Source/WebCore/platform/graphics/transforms/RotateTransformOperation.h
M Source/WebCore/platform/graphics/transforms/ScaleTransformOperation.cpp
M Source/WebCore/platform/graphics/transforms/ScaleTransformOperation.h
M Source/WebCore/platform/graphics/transforms/SkewTransformOperation.cpp
M Source/WebCore/platform/graphics/transforms/SkewTransformOperation.h
M Source/WebCore/platform/graphics/transforms/TransformOperation.h
M
Source/WebCore/platform/graphics/transforms/TranslateTransformOperation.cpp
M Source/WebCore/platform/graphics/transforms/TranslateTransformOperation.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 259548.723@safari-7615-branch (9e8e582627a8).
https://bugs.webkit.org/show_bug.cgi?id=255629
TransformOperation subclasses should verify deserialized type
https://bugs.webkit.org/show_bug.cgi?id=255629
rdar://108161092
Reviewed by David Kilzer.
The type needs to line up with the same types used by the is, downcast, and
dynamicDowncast functions.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::computedNeedsForcedLayout):
* Source/WebCore/platform/graphics/transforms/IdentityTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/Matrix3DTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/MatrixTransformOperation.h:
*
Source/WebCore/platform/graphics/transforms/PerspectiveTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp:
(WebCore::RotateTransformOperation::RotateTransformOperation):
* Source/WebCore/platform/graphics/transforms/RotateTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/ScaleTransformOperation.cpp:
(WebCore::ScaleTransformOperation::ScaleTransformOperation):
* Source/WebCore/platform/graphics/transforms/ScaleTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/SkewTransformOperation.cpp:
(WebCore::SkewTransformOperation::SkewTransformOperation):
* Source/WebCore/platform/graphics/transforms/SkewTransformOperation.h:
* Source/WebCore/platform/graphics/transforms/TransformOperation.h:
(WebCore::TransformOperation::isRotateTransformOperationType):
(WebCore::TransformOperation::isScaleTransformOperationType):
(WebCore::TransformOperation::isSkewTransformOperationType):
(WebCore::TransformOperation::isTranslateTransformOperationType):
(WebCore::TransformOperation::isRotateTransformOperationType const):
Deleted.
(WebCore::TransformOperation::isScaleTransformOperationType const): Deleted.
(WebCore::TransformOperation::isSkewTransformOperationType const): Deleted.
(WebCore::TransformOperation::isTranslateTransformOperationType const):
Deleted.
*
Source/WebCore/platform/graphics/transforms/TranslateTransformOperation.cpp:
(WebCore::TranslateTransformOperation::TranslateTransformOperation):
* Source/WebCore/platform/graphics/transforms/TranslateTransformOperation.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/259548.723@safari-7615-branch
Commit: 1b50a3df73d21bef150af61c2810002df3bc141e
https://github.com/WebKit/WebKit/commit/1b50a3df73d21bef150af61c2810002df3bc141e
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/fast/css/style-builder-apply-value-content-type-confusion-expected.txt
A LayoutTests/fast/css/style-builder-apply-value-content-type-confusion.html
M Source/WebCore/style/StyleBuilderCustom.h
Log Message:
-----------
Cherry-pick 259548.730@safari-7615-branch (c123784dc828).
https://bugs.webkit.org/show_bug.cgi?id=255955.
Fix type confusion in BuilderConverter::applyValueContent.
https://bugs.webkit.org/show_bug.cgi?id=255955.
rdar://108499561.
Reviewed by Antti Koivisto.
This change fixes applyValueContent so that it can deal with single
values instead of expecting a list of values towards the end.
*
LayoutTests/fast/css/style-builder-apply-value-content-type-confusion-expected.txt:
Added.
*
LayoutTests/fast/css/style-builder-apply-value-content-type-confusion.html:
Added.
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyValueContent):
Canonical link: https://commits.webkit.org/259548.730@safari-7615-branch
Commit: 2a8268d01eb0085e7efd3e0ca27aa6c30d452a86
https://github.com/WebKit/WebKit/commit/2a8268d01eb0085e7efd3e0ca27aa6c30d452a86
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/fast/css/style-builder-convert-grid-track-size-list-type-confusion-expected.txt
A
LayoutTests/fast/css/style-builder-convert-grid-track-size-list-type-confusion.html
M Source/WebCore/style/StyleBuilderConverter.h
Log Message:
-----------
Cherry-pick 259548.746@safari-7615-branch (1b98f8905ce2).
https://bugs.webkit.org/show_bug.cgi?id=256055.
Fix type confusion in StyleBuilder::ConvertGridTrackSizeList.
https://bugs.webkit.org/show_bug.cgi?id=256055.
rdar://108501981.
Reviewed by Antti Koivisto.
This change fixes convertGridTrackSizeList so that it can deal with single
values instead of expecting a list of values towards the end.
*
LayoutTests/fast/css/style-builder-convert-grid-track-size-list-type-confusion-expected.txt:
Added.
*
LayoutTests/fast/css/style-builder-convert-grid-track-size-list-type-confusion.html:
Added.
* Source/WebCore/style/StyleBuilderConverter.h:
(WebCore::Style::BuilderConverter::convertGridTrackSizeList):
Canonical link: https://commits.webkit.org/259548.746@safari-7615-branch
Commit: 8c362780c39314228531777335d72cf16b065465
https://github.com/WebKit/WebKit/commit/8c362780c39314228531777335d72cf16b065465
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/page/DOMWindow.h
Log Message:
-----------
Cherry-pick 259548.729@safari-7615-branch (5cc2ead4986a).
https://bugs.webkit.org/show_bug.cgi?id=256205.
Handle potential overflow of gamepadEventListenerCount.
https://bugs.webkit.org/show_bug.cgi?id=256205.
rdar://80838189.
Reviewed by Ryosuke Niwa.
m_gamepadEventListenerCount can overflow if addEventListener() is called
UINT_MAX+1 times.
Once the window is freed, we will be left with a dangling pointer in the
GamepadManager.
This change adds a flag to check for overflow and keep the behavior same in
the event of overflow..
* Source/WebCore/page/DOMWindow.cpp:
(WebCore::DOMWindow::~DOMWindow):
(WebCore::DOMWindow::incrementGamepadEventListenerCount):
(WebCore::DOMWindow::decrementGamepadEventListenerCount):
* Source/WebCore/page/DOMWindow.h:
Canonical link: https://commits.webkit.org/259548.729@safari-7615-branch
Commit: 818c5df196cc3257598e8799acc698fa3cb4f1d9
https://github.com/WebKit/WebKit/commit/818c5df196cc3257598e8799acc698fa3cb4f1d9
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebKit/Platform/IPC/Connection.cpp
M Source/WebKit/Scripts/webkit/model.py
M Source/WebKit/Scripts/webkit/tests/MessageNames.cpp
M Source/WebKit/Scripts/webkit/tests/MessageNames.h
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
Log Message:
-----------
Cherry-pick 259548.751@safari-7615-branch (9fc652968e3c).
https://bugs.webkit.org/show_bug.cgi?id=256373
Drop MessageName::Terminate IPC message
https://bugs.webkit.org/show_bug.cgi?id=256373
rdar://108899132
Reviewed by Sihui Liu.
Drop MessageName::Terminate IPC message as it could easily be abused by a
compromised WebProcess to kill the UIProcess.
It was temporarily introduced in 243810@main to investigate NetworkProcess
hangs we were seeing and should no longer be needed. This reverts
243810@main.
* Source/WebKit/Platform/IPC/Connection.cpp:
(IPC::Connection::processIncomingMessage):
(IPC::terminateDueToIPCTerminateMessage): Deleted.
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::didBecomeUnresponsive):
(WebKit::shouldTerminateNetworkProcessBySendingMessage): Deleted.
Canonical link: https://commits.webkit.org/259548.751@safari-7615-branch
Commit: 13db18fbb54ae73f4399a2c4addfac94f7bd7e95
https://github.com/WebKit/WebKit/commit/13db18fbb54ae73f4399a2c4addfac94f7bd7e95
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M LayoutTests/fast/files/null-origin-string-expected.txt
M LayoutTests/fast/files/null-origin-string.html
A
LayoutTests/http/tests/security/block-top-level-navigation-to-different-scheme-by-third-party-iframes-expected.txt
A
LayoutTests/http/tests/security/block-top-level-navigation-to-different-scheme-by-third-party-iframes.html
A
LayoutTests/http/tests/security/block-top-level-navigation-via-redirect-by-third-party-iframes-expected.txt
A
LayoutTests/http/tests/security/block-top-level-navigation-via-redirect-by-third-party-iframes.html
A
LayoutTests/http/tests/security/resources/navigate-top-level-frame-to-failure-page-different-scheme.html
A
LayoutTests/http/tests/security/resources/navigate-top-level-frame-to-failure-page-via-redirect.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/NavigationRequester.cpp
M Source/WebCore/loader/NavigationRequester.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 259548.752@safari-7615-branch (a0fa94d1a572).
https://bugs.webkit.org/show_bug.cgi?id=256549
Restrict further top-frame navigations by a third-party iframe
https://bugs.webkit.org/show_bug.cgi?id=256549
rdar://108794051
Reviewed by Geoffrey Garen.
Restrict further top-frame navigations by a third-party iframe:
- Block navigations to a different scheme
- Block navigations that start off same-site but redirect to a different
site
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::isNavigationBlockedByThirdPartyIFrameRedirectBlocking):
* Source/WebCore/dom/Document.h:
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest):
* Source/WebCore/loader/NavigationRequester.cpp:
(WebCore::NavigationRequester::from):
* Source/WebCore/loader/NavigationRequester.h:
(WebCore::NavigationRequester::encode const):
(WebCore::NavigationRequester::decode):
Canonical link: https://commits.webkit.org/259548.752@safari-7615-branch
Commit: 0e104f71f859197cf31a12ac0b4fad835d4bd3db
https://github.com/WebKit/WebKit/commit/0e104f71f859197cf31a12ac0b4fad835d4bd3db
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/regress-109134454.js
M Source/JavaScriptCore/b3/B3ReduceStrength.cpp
Log Message:
-----------
Cherry-pick 259548.761@safari-7615-branch (776066945bf4).
https://bugs.webkit.org/show_bug.cgi?id=256573
[JSC] Fix IntRange speculation for zExt32
https://bugs.webkit.org/show_bug.cgi?id=256573
rdar://109134454
Reviewed by Yusuke Suzuki.
Previously, the IntRange speculation in B3ReduceStrength for node
zExt32 is wrong. This patch fixes this issue.
* JSTests/stress/regress-109134454.js: Added.
* Source/JavaScriptCore/b3/B3ReduceStrength.cpp:
Canonical link: https://commits.webkit.org/259548.761@safari-7615-branch
Commit: b0f4f94839df47f872a0991b8ab46ba66543e223
https://github.com/WebKit/WebKit/commit/b0f4f94839df47f872a0991b8ab46ba66543e223
Author: David Degazio <d_dega...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/wasm/stress/throw-multiple-values.js
A JSTests/wasm/stress/throw-with-live-value-on-stack.js
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Cherry-pick 259548.762@safari-7615-branch (7fb3ced7874a).
https://bugs.webkit.org/show_bug.cgi?id=256818
Parameters to throw alias with stack elements in WASM LLInt
https://bugs.webkit.org/show_bug.cgi?id=256818
rdar://108036137
Reviewed by Yusuke Suzuki.
Correctly computes stack offsets when materializing the operands of
a wasm_throw instruction in the WasmLLIntGenerator by counting relative
to the stack height before the operands were popped as opposed to after.
* JSTests/wasm/stress/throw-multiple-values.js: Added.
(async test):
* JSTests/wasm/stress/throw-with-live-value-on-stack.js: Added.
(async test):
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addThrow):
Canonical link: https://commits.webkit.org/259548.762@safari-7615-branch
Commit: ec83f7580fdcc4a4ad7c1597053adc78dd0a922b
https://github.com/WebKit/WebKit/commit/ec83f7580fdcc4a4ad7c1597053adc78dd0a922b
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Cherry-pick 259548.773@safari-7615-branch (3d72c3255b5f).
https://bugs.webkit.org/show_bug.cgi?id=257161
Follow-up to 259548.752@safari-7615-branch to cancel navigations instead of
blocking them
https://bugs.webkit.org/show_bug.cgi?id=257161
rdar://108794051
Reviewed by Alex Christensen.
259548.752@safari-7615-branch added further restrictions to prevent
top-frame navigations
by third-party iframes, in particular using redirects. I had decided to
block the redirect
with a blockedError(). However, it turns out that Safari shows an error
page when doing
so, which results in a bad user experience since the top frame is still
being navigated
(to an error page).
To address the issue, I am now cancelling the redirect instead and
returning a
cancelledError(). I have verified that Safari doesn't show an error page in
this case and
that the top frame is not getting navigated.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest):
Canonical link: https://commits.webkit.org/259548.773@safari-7615-branch
Commit: 42bc82e63347c5c777dc201d955b7a747cb3cfff
https://github.com/WebKit/WebKit/commit/42bc82e63347c5c777dc201d955b7a747cb3cfff
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/fast/dom/non-reified-event-isTrusted-ic-crash-expected.txt
A LayoutTests/fast/dom/non-reified-event-isTrusted-ic-crash.html
M Source/JavaScriptCore/bytecode/PropertyCondition.cpp
M Source/JavaScriptCore/runtime/ClassInfo.h
M Source/JavaScriptCore/runtime/PropertySlot.h
M Source/JavaScriptCore/runtime/Structure.cpp
M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
Log Message:
-----------
Cherry-pick 259548.775@safari-7615-branch (ffe32d106cb2).
https://bugs.webkit.org/show_bug.cgi?id=255952
[JSC] PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint()
should take non-reified static properties into account
https://bugs.webkit.org/show_bug.cgi?id=255952
<rdar://108334411>
Reviewed by Yusuke Suzuki.
Currently,
PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint() is not
checking the
structure's non-reified static properties against the condition. This can
lead to incorrect analysis
of side effects: AbsenceOfSetEffect condition with a non-reified static
setter is considered pure
even though a setter with arbitrary code can be invoked.
This patch fixes AbsenceOfSetEffect validity check for structures with
non-reified static properties
while takes extra care to make the fix as precise as possible to avoid
unnecessary slowdowns.
* LayoutTests/fast/dom/non-reified-event-isTrusted-ic-crash-expected.txt:
Added.
* LayoutTests/fast/dom/non-reified-event-isTrusted-ic-crash.html: Added.
* Source/JavaScriptCore/bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint
const):
* Source/JavaScriptCore/runtime/ClassInfo.h:
* Source/JavaScriptCore/runtime/PropertySlot.h:
* Source/JavaScriptCore/runtime/Structure.cpp:
(JSC::ClassInfo::hasStaticReadOnlyOrGetterSetterProperty const):
* Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:
Canonical link: https://commits.webkit.org/259548.775@safari-7615-branch
Commit: ef65ba56c109cb54c24ed6da30a39ef230b1acf7
https://github.com/WebKit/WebKit/commit/ef65ba56c109cb54c24ed6da30a39ef230b1acf7
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/regress-109102631.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
Log Message:
-----------
Cherry-pick 259548.763@safari-7615-branch (62d974e46170).
https://bugs.webkit.org/show_bug.cgi?id=256865
[JSC] GetTypedArrayByteOffset should do speculation check for all bits in
DFG
https://bugs.webkit.org/show_bug.cgi?id=256865
rdar://109428505
Reviewed by Yusuke Suzuki.
DFG abstract interpreter speculates that GetTypedArrayByteOffset node
should have int32 result. However, when compiling GetTypedArrayByteOffset
we only do speculation check on lower bits of the result, which is wrong.
This patch fixes this problem.
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
Canonical link: https://commits.webkit.org/259548.763@safari-7615-branch
Commit: d784299e55fa84c267ca35ed257ef08a500571f7
https://github.com/WebKit/WebKit/commit/d784299e55fa84c267ca35ed257ef08a500571f7
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
JSTests/stress/define-property-on-receiver-jsfunction-prototype-no-crash.js
M JSTests/stress/ordinary-set-exceptions.js
M Source/JavaScriptCore/runtime/JSObject.cpp
Log Message:
-----------
Cherry-pick 259548.774@safari-7615-branch (23e9761b5751).
https://bugs.webkit.org/show_bug.cgi?id=257164
[JSC] putByValWithThis shouldn't bypass definePropertyOnReceiverSlow
https://bugs.webkit.org/show_bug.cgi?id=257164
<rdar://108759737>
Reviewed by Yusuke Suzuki.
The OrdinarySet revamp in https://webkit.org/b/217916 assumed that there
are only 2 cases to take the slow path
for altered receivers: overriden [[Set]] in prototype chain and
Reflect.set(). I thought that it's unobservable
to take the fast path otherwise since overriden methods were already called.
However, the third case was missed: put_by_val_with_this bytecode op, which
is emitted for setting a property
on `super` base, and with https://webkit.org/b/252602, for ProxyObjectStore
IC when the trap is missing.
Among other minor web compatibility bugs, missing that case caused
properties to be put right on ProxyObject's
structure, where they are unaccessible, skipping calls to "set" and
"defineProperty" traps.
This change relaxes the condition for taking the
definePropertyOnReceiverSlow() while ensuring all common
[[Set]] targets like JSArray or `class X extends Y {}` are just as fast.
*
JSTests/stress/define-property-on-receiver-jsfunction-prototype-no-crash.js:
Added.
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::canDefinePropertyOnReceiverFast):
(JSC::JSObject::definePropertyOnReceiver):
Canonical link: https://commits.webkit.org/259548.774@safari-7615-branch
Commit: fff78f2470f4e688798baa4c3133698963b3a4f3
https://github.com/WebKit/WebKit/commit/fff78f2470f4e688798baa4c3133698963b3a4f3
Author: Yijia Huang <yijia_hu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M JSTests/stress/regress-109102631.js
Log Message:
-----------
Cherry-pick 259548.776@safari-7615-branch (7849e30e34aa).
https://bugs.webkit.org/show_bug.cgi?id=257215
[JSC] Skip memory limited systems for test case allocating large size array
https://bugs.webkit.org/show_bug.cgi?id=257215
rdar://109729172
Reviewed by Yusuke Suzuki.
* JSTests/stress/regress-109102631.js:
Canonical link: https://commits.webkit.org/259548.776@safari-7615-branch
Commit: 920a6190c80740deae08cfe24e0c37eabb7cf9da
https://github.com/WebKit/WebKit/commit/920a6190c80740deae08cfe24e0c37eabb7cf9da
Author: Patrick Angle <pan...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/JavaScriptCore/inspector/ScriptCallStack.cpp
M Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.cpp
Log Message:
-----------
Cherry-pick 259548.777@safari-7615-branch (e74d4b07ad38).
https://bugs.webkit.org/show_bug.cgi?id=256932
Web Inspector: Deeply nested console logging can cause ConsoleMessage to be
destroyed while we are still trying to log it
https://bugs.webkit.org/show_bug.cgi?id=256932
rdar://108063640
Reviewed by Mark Lam.
InspectorConsoleAgent has been incorrectly managing the lifetime of each
ConsoleMessage by moving messages into a vector
of messages before we have passed those messages on to the frontend. This
means that a console message that causes
another console message to be logged may eventually cause our original
message to be dropped from the vector if this
occurs deeply enough. At that point, when we unwind back to the original
message, it has been destroyed while we are
trying to send it to the frontend, which results in a bad time because we
are still inside a function on the
ConsoleMessage that tries to access its own member variables like
m_arguments, and fails because the message object
itself has been destroyed, taking its members with it.
This also fixes a subtle message inversion in the backlog of messages and
what is logged to the console when Web
Inspector is open, since the message is sent to the frontend after all
other processing, but we were previously adding
the message to the vector of past messages before that processing (which
may in turn cause more logging before the
actual logging we called in to perform) to occur.
A second minor issue is that ScriptCallStack is incorrectly asserting in
its constructor, which preventing investigation
of this issue initially. The call stack should be less than __or equal to__
the max call stack, not just less than.
* Source/JavaScriptCore/inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
* Source/JavaScriptCore/inspector/InjectedScript.cpp:
(Inspector::InjectedScript::wrapObject const):
(Inspector::InjectedScript::wrapTable const):
* Source/JavaScriptCore/inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::ScriptCallStack):
* Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::addConsoleMessage):
* Source/WebCore/page/PageConsoleClient.cpp:
(WebCore::PageConsoleClient::messageWithTypeAndLevel):
Canonical link: https://commits.webkit.org/259548.777@safari-7615-branch
Commit: 58983074a9c84dfb0b3f6c4aab6c6de07648c6ae
https://github.com/WebKit/WebKit/commit/58983074a9c84dfb0b3f6c4aab6c6de07648c6ae
Author: Yusuke Suzuki <ysuz...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/resizable-array-buffer-copy-within-length-update.js
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
Log Message:
-----------
Cherry-pick 259548.785@safari-7615-branch (f2a2820d312c).
https://bugs.webkit.org/show_bug.cgi?id=257387
[JSC] Recompute length properly when resize happens during
TypedArray#copyWithin
https://bugs.webkit.org/show_bug.cgi?id=257387
rdar://109851495
Reviewed by Mark Lam.
copyWithin's side effectful operation can resize resizable ArrayBuffer. We
have a code catching this and recompute the appropriate copy count
again, but it can overflow if `to` or `from` are larger than the newly
updated `length`. This patch handles this case correctly: returning
since there is no copying content in this case.
* JSTests/stress/resizable-array-buffer-copy-within-length-update.js: Added.
(call_back):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
Canonical link: https://commits.webkit.org/259548.785@safari-7615-branch
Commit: 83d9025caca38091a9ba7f6978689d275960c5ab
https://github.com/WebKit/WebKit/commit/83d9025caca38091a9ba7f6978689d275960c5ab
Author: Matthew Finkel <sys...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/html/CanvasBase.h
M Source/WebCore/html/HTMLCanvasElement.h
M Source/WebCore/html/OffscreenCanvas.cpp
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
M Source/WebCore/rendering/style/StyleCanvasImage.cpp
Log Message:
-----------
Cherry-pick 259548.787@safari-7615-branch (88ed3825fa4e).
https://bugs.webkit.org/show_bug.cgi?id=257234
Ensure CanvasBase remains alive while in use
https://bugs.webkit.org/show_bug.cgi?id=257234
rdar://109540621
Reviewed by Chris Dumez.
A HTMLCanvasElement could be destroyed when it calls
CanvasBase::setImageBuffer
because that call could trigger a GC. We've seen crashes originating from
HTMLCanvasElement::setImageBufferAndMarkDirty, but this patch adds
protection
around other setImageBuffer call sites, as well.
* Source/WebCore/html/CanvasBase.h:
(WebCore::CanvasBase::ref):
(WebCore::CanvasBase::deref):
* Source/WebCore/html/HTMLCanvasElement.h:
* Source/WebCore/html/OffscreenCanvas.cpp:
(WebCore::OffscreenCanvas::create):
(WebCore::OffscreenCanvas::setPlaceholderCanvas):
(WebCore::OffscreenCanvas::pushBufferToPlaceholder):
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::drawImage):
* Source/WebCore/rendering/style/StyleCanvasImage.cpp:
(WebCore::StyleCanvasImage::image const):
Canonical link: https://commits.webkit.org/259548.787@safari-7615-branch
Commit: 5473f46b40d0c5f81440c2cfcf49d4a2d31c06bd
https://github.com/WebKit/WebKit/commit/5473f46b40d0c5f81440c2cfcf49d4a2d31c06bd
Author: Charlie Wolfe <charl...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 259548.792@safari-7615-branch (f52bc7e18a7c).
https://bugs.webkit.org/show_bug.cgi?id=257348
Process Isolation Bypass via navigating to about:* context
https://bugs.webkit.org/show_bug.cgi?id=257348
rdar://109853048
Reviewed by Chris Dumez and J Pascoe.
This patch fixes an issue where we will never swap processes when
navigating from an
about:* page. A compromised WebContent process could leverage this behavior
to avoid
swapping processes when navigating to a cross-origin domain.
This is fixed by checking the following when navigating from an about:*
page.
- The page has not committed a provisional load to a URL that isn't about:*.
- The source process last loaded a domain from the same origin as the
domain we are navigating to.
If neither of these two conditions are met, we won’t reuse the process.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didExplicitOpenForFrame):
(WebKit::WebPageProxy::didCommitLoadForFrame):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigationInternal):
* Source/WebKit/UIProcess/WebProcessProxy.h:
(WebKit::WebProcessProxy::didCommitMeaningfulProvisionalLoad):
(WebKit::WebProcessProxy::hasCommittedAnyMeaningfulProvisionalLoads const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/259548.792@safari-7615-branch
Commit: 993ed03d6b750a915d1bbca7712ce880c8605491
https://github.com/WebKit/WebKit/commit/993ed03d6b750a915d1bbca7712ce880c8605491
Author: Charlie Wolfe <charl...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/C/WKPage.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Tools/WebKitTestRunner/TestController.cpp
Log Message:
-----------
Cherry-pick 259548.812@safari-7615-branch (5e250c9fb3d7).
https://bugs.webkit.org/show_bug.cgi?id=257833
REGRESSION(259548.792@safari-7615-branch)
http/tests/contentextensions/block-everything-unless-domain-redirect.py &
http/tests/loading/preload-append-scan.py are failing
https://bugs.webkit.org/show_bug.cgi?id=257833
rdar://110350341
Reviewed by Alex Christensen.
259548.792@safari-7615-branch made a change where we will swap processes
when navigating from about:blank when
the current process has made a provisional load to a URL that was not
about:*. This state was not reset between
tests, and since about:blank is loaded between each test, we would process
swap in cases where we previously
hadn’t when running tests. Let’s fix this by clearing this state on
`WebProcessProxy` between each test run.
* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageResetProcessState):
* Source/WebKit/UIProcess/API/C/WKPage.h:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::resetState):
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetStateToConsistentValues):
Canonical link: https://commits.webkit.org/259548.812@safari-7615-branch
Commit: dfd82a930eeb410f063928b9817357d123039d24
https://github.com/WebKit/WebKit/commit/dfd82a930eeb410f063928b9817357d123039d24
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/regress-108468977.js
M Source/JavaScriptCore/bytecode/PropertyCondition.cpp
M Source/JavaScriptCore/runtime/JSObject.cpp
M Source/JavaScriptCore/runtime/JSObject.h
Log Message:
-----------
Cherry-pick 259548.797@safari-7615-branch (169a4b7e3f48).
https://bugs.webkit.org/show_bug.cgi?id=257271
[JSC] PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint()
should take all put() overrides into account
https://bugs.webkit.org/show_bug.cgi?id=257271
<rdar://108468977>
Reviewed by Yusuke Suzuki.
Currently,
PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint() is not taking
into account
all existing put() overrides when analyzing side effects of
AbsenceOfSetEffect condition, which leads
to incorrect results for e.g. StringObject's "length", which is no-op in
sloppy mode yet we rely on
structure being transitioned.
This patch fixes AbsenceOfSetEffect validity check to be more pessimistic
when there is overriden put(),
unless it's a common assigment target like JSArray or JSFunction to avoid
performance regressions,
all while the helper that checks for special properties with
JSObject::definePropertyOnReceiver().
* JSTests/stress/regress-108468977.js: Added.
* Source/JavaScriptCore/bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint
const):
(JSC::nonStructurePropertyMayBecomeReadOnlyWithoutTransition): Deleted.
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::JSObject::mightBeSpecialProperty):
(JSC::JSObject::definePropertyOnReceiver):
(JSC::canDefinePropertyOnReceiverFast): Deleted.
* Source/JavaScriptCore/runtime/JSObject.h:
Canonical link: https://commits.webkit.org/259548.797@safari-7615-branch
Commit: cb67dbb46230e8b0aecab3b6bb67caee8e7f0194
https://github.com/WebKit/WebKit/commit/cb67dbb46230e8b0aecab3b6bb67caee8e7f0194
Author: Justin Michaud <justin_mich...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/stress/get-concurrently-should-take-cell-lock.js
M Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp
M Source/JavaScriptCore/bytecode/PropertyCondition.cpp
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/runtime/JSArray.cpp
M Source/JavaScriptCore/runtime/JSCell.h
M Source/JavaScriptCore/runtime/JSObject.h
Log Message:
-----------
Cherry-pick 259548.798@safari-7615-branch (b7e3ebd9c372).
https://bugs.webkit.org/show_bug.cgi?id=257285
JSObject::getDirectConcurrently should take the cell lock.
https://bugs.webkit.org/show_bug.cgi?id=257285
rdar://108166258
Reviewed by Yusuke Suzuki.
`JSArray::unshiftCountWithArrayStorage` takes the cell lock and then the
structure lock to prevent the compiler thread from accessing the butterfly
before it is fully initialized.
`JSObject::getDirectConcurrently` only takes the structure lock. This means
that the compiler can take the structure lock, the cell can transition
to a new structure, then unshift can mess up the butterfly, and finally
the compiler thread proceeds to see garbage.
The attached POC only reproduces if waits are introduced to extend the race
window.
It seems that the comment above cellLock is outdated, as our current
concurrency
protocol to prevent deadlocks is to take the cell lock then the structure
lock.
I could not find anywhere that uses the reverse, but if I missed something,
a deadlock will be pretty easy to debug.
* Source/JavaScriptCore/runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountWithArrayStorage):
* Source/JavaScriptCore/runtime/JSCell.h:
(JSC::JSCell::cellLock const):
(JSC::JSCell::cellLock): Deleted.
* Source/JavaScriptCore/runtime/JSObject.h:
(JSC::JSObject::getDirectConcurrently const):
Canonical link: https://commits.webkit.org/259548.798@safari-7615-branch
Commit: 36a57b922accd6bd4a15f84f89b97fc29e713d25
https://github.com/WebKit/WebKit/commit/36a57b922accd6bd4a15f84f89b97fc29e713d25
Author: Ryan Reno <rr...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M
LayoutTests/http/tests/referrer-policy-iframe/no-referrer-when-downgrade/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/no-referrer/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/origin-when-cross-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/same-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/strict-origin-when-cross-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/strict-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy-iframe/unsafe-url/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/no-referrer-when-downgrade/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/no-referrer/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/origin-when-cross-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/same-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/strict-origin-when-cross-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/strict-origin/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/referrer-policy/unsafe-url/cross-origin-http.https-expected.txt
M
LayoutTests/http/tests/security/contentSecurityPolicy/upgrade-insecure-requests/iframe-upgrade.https-expected.txt
M
LayoutTests/http/tests/security/mixedContent/insecure-iframe-in-iframe-expected.txt
M
LayoutTests/http/tests/security/mixedContent/insecure-iframe-in-iframe.html
A
LayoutTests/http/tests/security/mixedContent/insecure-iframe-in-sandboxed-iframe-expected.txt
A
LayoutTests/http/tests/security/mixedContent/insecure-iframe-in-sandboxed-iframe.html
M
LayoutTests/http/tests/security/mixedContent/insecure-script-in-data-iframe-in-main-frame-blocked-expected.txt
M
LayoutTests/http/tests/security/referrer-policy-header-and-meta-tag-emptyString.html
M LayoutTests/http/tests/security/referrer-policy-header-and-meta-tag.html
M LayoutTests/http/tests/security/referrer-policy-header-multipart.html
M LayoutTests/http/tests/security/referrer-policy-header-test.js
M LayoutTests/http/tests/security/referrer-policy-header.html
M LayoutTests/http/tests/security/referrer-policy-https-always-expected.txt
M LayoutTests/http/tests/security/referrer-policy-https-always.html
M LayoutTests/http/tests/security/referrer-policy-https-default-expected.txt
M LayoutTests/http/tests/security/referrer-policy-https-default.html
M LayoutTests/http/tests/security/referrer-policy-https-never-expected.txt
M LayoutTests/http/tests/security/referrer-policy-https-never.html
M
LayoutTests/http/tests/security/referrer-policy-https-no-referrer-expected.txt
M
LayoutTests/http/tests/security/referrer-policy-https-no-referrer-when-downgrade-expected.txt
M
LayoutTests/http/tests/security/referrer-policy-https-no-referrer-when-downgrade.html
M LayoutTests/http/tests/security/referrer-policy-https-no-referrer.html
M LayoutTests/http/tests/security/referrer-policy-https-origin-expected.txt
M LayoutTests/http/tests/security/referrer-policy-https-origin.html
M
LayoutTests/http/tests/security/referrer-policy-https-unsafe-url-expected.txt
M LayoutTests/http/tests/security/referrer-policy-https-unsafe-url.html
M LayoutTests/http/tests/security/resources/postReferrer.py
M LayoutTests/http/tests/security/resources/referrer-policy-log.py
M
LayoutTests/http/tests/security/resources/sandboxed-iframe-geolocation-getCurrentPosition.html
M
LayoutTests/http/tests/security/resources/sandboxed-iframe-geolocation-watchPosition.html
M
LayoutTests/http/tests/security/resources/serve-referrer-policy-and-meta-tag.py
M
LayoutTests/http/tests/security/resources/serve-referrer-policy-and-test.py
R
LayoutTests/http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http-expected.txt
R
LayoutTests/http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http.html
M
LayoutTests/http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-https-with-embedded-http-with-embedded-https.https-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/reporting/report-original-url-on-mixed-content-frame.https.sub-expected.txt
A
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/fs/FileSystemFileHandle-create-sync-access-handle.https.tentative.window-expected.txt
A
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/screen-orientation/nested-documents-expected.txt
A
LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/screen-orientation/unlock-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/insecure-iframe-in-iframe-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/insecure-iframe-in-main-frame-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/insecure-iframe-in-sandboxed-iframe-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/insecure-image-in-iframe-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/redirect-http-to-https-iframe-in-main-frame-expected.txt
A
LayoutTests/platform/mac-wk1/http/tests/security/mixedContent/redirect-https-to-http-iframe-in-main-frame-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-css-in-iframe-report-only-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-iframe-in-main-frame-expected.txt
R
LayoutTests/platform/wk2/http/tests/security/mixedContent/insecure-iframe-in-iframe-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/mixedContent/insecure-iframe-in-main-frame-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/mixedContent/insecure-image-in-iframe-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/mixedContent/redirect-http-to-https-iframe-in-main-frame-expected.txt
M
LayoutTests/platform/wk2/http/tests/security/mixedContent/redirect-https-to-http-iframe-in-main-frame-expected.txt
M Source/WebCore/Modules/websockets/WebSocket.cpp
M Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp
M Source/WebCore/html/HTMLFormElement.cpp
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/loader/DocumentThreadableLoader.cpp
M Source/WebCore/loader/MixedContentChecker.cpp
M Source/WebCore/loader/MixedContentChecker.h
M Source/WebCore/loader/SubframeLoader.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
Log Message:
-----------
Cherry-pick 259548.802@safari-7615-branch (bc09b6fca325).
https://bugs.webkit.org/show_bug.cgi?id=257331
Framed pages have ability to bypass Mixed Content restrictions
https://bugs.webkit.org/show_bug.cgi?id=257331
rdar://109100886
Reviewed by Brent Fulgham.
It is possible to bypass mixed content restrictions in pages which are
framed. There are actually two issues here: secure frames embedded in
insecure frames can bypass and frames which are sandboxed can bypass.
In the former case we are only checking the for mixed content in the
frame making the request as well as the top frame. So if an insecure frame
embeds a secure frame, that secure frame could then embed an insecure frame
and
make mixed content requests without being blocked since the middle frame
is not checked against the URL for mixed content.
For the latter case we check whether or not the security origin
of the requestor has an "https" protocol. The problem is sandboxed iframes
are given an opaque origin which does not have the "https" protocol (or
any protocol for that matter) and so we were skipping the mixed content
check.
This patch cleans up the MixedContentChecker implementation and fixes
these two methods of bypass. This is accomplished by 1) checking the entire
ancestor frame path from the requestor up to the top frame and 2)
considering
what the protocol of the security origin for the frame making the
request would have been if it were not opaque. We special case a main
resource
load in the DocumentLoader by checking for mixed content starting from the
parent frame.
Otherwise we would block an insecure main frame from navigating a secure
iframe to an insecure URL which is allowed by other browser engines.
LayoutTests/http/tests/security:
Rewrote some tests to no longer use HTTP iframes in HTTPS frames
which is now blocked. These changes also include new console output
for mixed content blocking messages.
*
LayoutTests/http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http-expected.txt:
Removed.
*
LayoutTests/http/tests/websocket/tests/hybi/non-document-mixed-content-blocked-http-with-embedded-https-with-embedded-http.html:
Removed.
This test is no longer needed. We now block loading a HTTP iframe
in a middle HTTPS frame so the innermost frame would never have a
chance to load a worker anyway.
*
LayoutTests/imported/w3c/web-platform-tests/fs/FileSystemFileHandle-create-sync-access-handle.https.tentative.window-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/mixed-content/csp.https.window-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/mixed-content/nested-iframes.window-expected.txt:
LayoutTests/platform:
Updated platform-specific expectations.
* Source/WebCore/Modules/websockets/WebSocket.cpp:
(WebCore::WebSocket::connect):
* Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp:
(WebCore::WorkerThreadableWebSocketChannel::Bridge::connect):
* Source/WebCore/html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::parseAttribute):
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest):
* Source/WebCore/loader/DocumentThreadableLoader.cpp:
(WebCore::DocumentThreadableLoader::loadRequest):
Source/WebCore/loader/MixedContentChecker:
Refactor the MixedContentChecker to expose a more clear API.
isMixedContent was never called by client code and canDisplay and
canShow functions should be more clear that they will be checking
the entire frame ancestor hierarchy so clients don't try to do that
themselves. Move helpers to be static functions in the .cpp file.
* Source/WebCore/loader/MixedContentChecker.cpp:
(WebCore::isMixedContent):
(WebCore::foundMixedContentInFrameTree):
(WebCore::MixedContentChecker::frameAndAncestorsCanDisplayInsecureContent):
(WebCore::MixedContentChecker::frameAndAncestorsCanRunInsecureContent):
(WebCore::MixedContentChecker::checkFormForMixedContent):
(WebCore::MixedContentChecker::checkForMixedContentInFrameTree): Deleted.
(WebCore::MixedContentChecker::isMixedContent): Deleted.
(WebCore::MixedContentChecker::canDisplayInsecureContent): Deleted.
(WebCore::MixedContentChecker::canRunInsecureContent): Deleted.
* Source/WebCore/loader/MixedContentChecker.h:
* Source/WebCore/loader/SubframeLoader.cpp:
(WebCore::FrameLoader::SubframeLoader::pluginIsLoadable):
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::checkInsecureContent const):
Canonical link: https://commits.webkit.org/259548.802@safari-7615-branch
Commit: 8536c77b03e96a3aa6da0d979999796adeb153a5
https://github.com/WebKit/WebKit/commit/8536c77b03e96a3aa6da0d979999796adeb153a5
Author: Rob Buis <rb...@igalia.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/fast/media/print-video-crash-expected.txt
A LayoutTests/fast/media/print-video-crash.html
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/WebKitTestRunner/TestController.cpp
Log Message:
-----------
Cherry-pick 263022.8@webkit-2023.4-embargoed (221c50b850f8).
https://bugs.webkit.org/show_bug.cgi?id=237291
Make sure end printing is handled before PrintFrame
https://bugs.webkit.org/show_bug.cgi?id=237291
Reviewed by Chris Dumez.
To ensure end printing is handled (and layer tree is unfrozen)
introduce a completion handler on EndPrinting and tie its completion
to the completion handler in WebPageProxy::printFrame.
Also do not call endPrinting from TestController.cpp since
WebPageProxy::printFrame takes care of that.
* LayoutTests/fast/media/print-video-crash-expected.txt: Added.
* LayoutTests/fast/media/print-video-crash.html: Added.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::printFrame):
(WebKit::WebPageProxy::endPrinting):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::endPrinting):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
(WebKit::WebPage::endPrinting):
(WebKit::WebPage::endPrintingDuringDOMPrintOperation):
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::printFrame):
Canonical link: https://commits.webkit.org/263022.8@webkit-2023.4-embargoed
Commit: 6217482b85fa8cc40ece4119a0799ddf55683826
https://github.com/WebKit/WebKit/commit/6217482b85fa8cc40ece4119a0799ddf55683826
Author: Rob Buis <rb...@igalia.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/fast/canvas/canvas-print-crash-expected.txt
A LayoutTests/fast/canvas/canvas-print-crash.html
Log Message:
-----------
Cherry-pick 263022.9@webkit-2023.4-embargoed (a0645306d06d).
https://bugs.webkit.org/show_bug.cgi?id=251370
Add test case for bug 251370
https://bugs.webkit.org/show_bug.cgi?id=251370
Reviewed by Chris Dumez.
Already fixed by
https://commits.webkit.org/263022.8@webkit-2023.4-embargoed, but
add this test for completeness.
* LayoutTests/fast/canvas/canvas-print-crash-expected.txt: Added.
* LayoutTests/fast/canvas/canvas-print-crash.html: Added.
Canonical link: https://commits.webkit.org/263022.9@webkit-2023.4-embargoed
Commit: 3a117ed1a61280d2f945414d776f8cdf297d59c8
https://github.com/WebKit/WebKit/commit/3a117ed1a61280d2f945414d776f8cdf297d59c8
Author: Ryan Reno <rr...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/http/tests/security/sandboxed-iframe-javascript-self-navigation-expected.txt
A
LayoutTests/http/tests/security/sandboxed-iframe-javascript-self-navigation.html
A
LayoutTests/http/tests/security/sandboxed-iframe-javascript-top-navigation-expected.txt
A
LayoutTests/http/tests/security/sandboxed-iframe-javascript-top-navigation.html
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/NavigationRequester.cpp
M Source/WebCore/loader/NavigationRequester.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 259548.813@safari-7615-branch (47ed6aa2ea88).
https://bugs.webkit.org/show_bug.cgi?id=257824
Block sandboxed frames from navigating to javascript URLs without
allow-scripts sandbox flag.
https://bugs.webkit.org/show_bug.cgi?id=257824
rdar://108462161
Reviewed by Alex Christensen.
Sandboxed iframes could execute script in a target frame by navigating
the frame to a javascript: URL. For example, the top frame when the
iframe has the sandbox flag "allow-top-navigation". This change checks to
see if
the "allow-scripts" flag is set before executing the URL in the target
frame.
*
LayoutTests/http/tests/security/sandboxed-iframe-javascript-self-navigation-expected.txt:
Added.
*
LayoutTests/http/tests/security/sandboxed-iframe-javascript-self-navigation.html:
Added.
*
LayoutTests/http/tests/security/sandboxed-iframe-javascript-top-navigation-expected.txt:
Added.
*
LayoutTests/http/tests/security/sandboxed-iframe-javascript-top-navigation.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::executeJavaScriptURL):
* Source/WebCore/loader/NavigationRequester.cpp:
(WebCore::NavigationRequester::from):
* Source/WebCore/loader/NavigationRequester.h:
(WebCore::NavigationRequester::encode const):
(WebCore::NavigationRequester::decode):
Canonical link: https://commits.webkit.org/259548.813@safari-7615-branch
Commit: b140015f7c677a9ad75b8921f15206eefa6d2847
https://github.com/WebKit/WebKit/commit/b140015f7c677a9ad75b8921f15206eefa6d2847
Author: Marcos Caceres <marc...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/http/wpt/content-security-policy/manifest.json
A
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub-expected.txt
A
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub.html
A
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub.html.headers
A
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-expected.txt
A LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked.html
A
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked.html.headers
M LayoutTests/platform/ios-wk2/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/loader/ApplicationManifestLoader.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ApplicationManifest.mm
Log Message:
-----------
Cherry-pick 259548.816@safari-7615-branch (8437c2302b67).
https://bugs.webkit.org/show_bug.cgi?id=256686
Incorrect CORS mode for ApplicationManifest
https://bugs.webkit.org/show_bug.cgi?id=256686
rdar://109154572
Reviewed by Brent Fulgham.
* LayoutTests/TestExpectations:
* LayoutTests/http/wpt/content-security-policy/manifest.json: Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub-expected.txt:
Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-cross-origin.sub.html.headers:
Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked-expected.txt:
Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked.html:
Added.
*
LayoutTests/http/wpt/content-security-policy/sandbox-manifest-blocked.html.headers:
Added.
* LayoutTests/platform/ios-wk2/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/loader/ApplicationManifestLoader.cpp:
(WebCore::ApplicationManifestLoader::startLoading):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ApplicationManifest.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/259548.816@safari-7615-branch
Commit: 4b892d294751e3e37d7e31b4c89f0f15775c9797
https://github.com/WebKit/WebKit/commit/4b892d294751e3e37d7e31b4c89f0f15775c9797
Author: Said Abou-Hallawa <s...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/css3/filters/filter-visited-links-expected.html
A LayoutTests/css3/filters/filter-visited-links.html
M Source/WebCore/rendering/PaintPhase.h
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/StyledMarkedText.cpp
M Source/WebCore/rendering/TextDecorationPainter.cpp
M Source/WebCore/rendering/TextDecorationPainter.h
M Source/WebCore/rendering/TextPaintStyle.cpp
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/RenderStyle.h
Log Message:
-----------
Cherry-pick 259548.820@safari-7615-branch (89399f0f4614).
https://bugs.webkit.org/show_bug.cgi?id=257822
Prevent SVG filters from leaking visited hyperlinks
https://bugs.webkit.org/show_bug.cgi?id=257822
rdar://109749006
Reviewed by Simon Fraser.
We should prevent websites from learning which sites have been visited via
SVG
filters on hyperlinks, per the attack described in
https://arxiv.org/abs/2305.12784.
This can be acheived by ignoring the visited links color when a filter is
applied
to the anchor element.
* LayoutTests/css3/filters/filter-visited-links-expected.html: Added.
* LayoutTests/css3/filters/filter-visited-links.html: Added.
* Source/WebCore/rendering/PaintPhase.h:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintLayerContents):
(WebCore::RenderLayer::paintForegroundForFragments):
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/StyledMarkedText.cpp:
(WebCore::resolveStyleForMarkedText):
(WebCore::StyledMarkedText::computeStyleForUnmarkedMarkedText):
* Source/WebCore/rendering/TextDecorationPainter.cpp:
(WebCore::collectStylesForRenderer):
(WebCore::TextDecorationPainter::decorationColor):
(WebCore::TextDecorationPainter::stylesForRenderer):
* Source/WebCore/rendering/TextDecorationPainter.h:
(WebCore::TextDecorationPainter::decorationColor):
(WebCore::TextDecorationPainter::stylesForRenderer):
* Source/WebCore/rendering/TextPaintStyle.cpp:
(WebCore::computeTextPaintStyle):
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::visitedDependentColor const):
(WebCore::RenderStyle::visitedDependentColorWithColorFilter const):
* Source/WebCore/rendering/style/RenderStyle.h:
(WebCore::RenderStyle::visitedDependentColor):
(WebCore::RenderStyle::visitedDependentColorWithColorFilter):
Canonical link: https://commits.webkit.org/259548.820@safari-7615-branch
Commit: 686e5d97f21aae290daff443dd623107d0ac5372
https://github.com/WebKit/WebKit/commit/686e5d97f21aae290daff443dd623107d0ac5372
Author: Ryan Reno <rr...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/http/tests/security/block-top-level-navigations-by-third-party-iframe-sandboxed-by-own-csp-expected.txt
A
LayoutTests/http/tests/security/block-top-level-navigations-by-third-party-iframe-sandboxed-by-own-csp.html
A
LayoutTests/http/tests/security/resources/attempt-top-level-navigation-with-csp.py
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 259548.823@safari-7615-branch (18a05c43972c).
https://bugs.webkit.org/show_bug.cgi?id=257903
Third Party IFrame Navigation Block Bypass via Content Security Policy
Sandbox
https://bugs.webkit.org/show_bug.cgi?id=257903
rdar://109059471
Reviewed by Brent Fulgham.
If a third-party iframe is unsandboxed we will prevent top navigation
without user interaction with the frame. However, this is bypassable if
the iframe gives itself a sandbox which allows top navigation via CSP.
This change checks to see if the iframe element was unsandboxed and
proceeds with the more strict third-party checks if so.
*
LayoutTests/http/tests/security/block-top-level-navigations-by-third-party-iframe-sandboxed-by-own-csp-expected.txt:
Added.
*
LayoutTests/http/tests/security/block-top-level-navigations-by-third-party-iframe-sandboxed-by-own-csp.html:
Added.
*
LayoutTests/http/tests/security/resources/attempt-top-level-navigation-with-csp.py:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::isNavigationBlockedByThirdPartyIFrameRedirectBlocking):
Canonical link: https://commits.webkit.org/259548.823@safari-7615-branch
Commit: 77073e695d06411a1c311163812ec64c5160b1df
https://github.com/WebKit/WebKit/commit/77073e695d06411a1c311163812ec64c5160b1df
Author: J Pascoe <j_pas...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/page/DOMWindow.cpp
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 259548.824@safari-7615-branch (cff01e3a9ba5).
https://bugs.webkit.org/show_bug.cgi?id=257352
https://bugs.webkit.org/show_bug.cgi?id=257352
rdar://106974958
Reviewed by John Wilander and Brent Fulgham.
This quirk is no longer nessesary to get favorites and recents to show up
in the radio player, which is why it was added in the first place. Therefore
it can be removed.
* Source/WebCore/page/DOMWindow.cpp:
(WebCore::DOMWindow::open):
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::triggerOptionalStorageAccessQuirk const):
(WebCore::Quirks::BBCRadioPlayerURLString): Deleted.
(WebCore::Quirks::staticRadioPlayerURLString): Deleted.
(WebCore::isBBCDomain): Deleted.
(WebCore::isBBCPopUpPlayerElement): Deleted.
* Source/WebCore/page/Quirks.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::createNewPage):
Canonical link: https://commits.webkit.org/259548.824@safari-7615-branch
Commit: bf79ad432fb005b24f5c317014e79911de3bb993
https://github.com/WebKit/WebKit/commit/bf79ad432fb005b24f5c317014e79911de3bb993
Author: Sihui Liu <sihui_...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-expected.txt
A
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-private-expected.txt
A
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-private.html
A LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event.html
A
LayoutTests/storage/indexeddb/modern/resources/request-dispatch-untrusted-event.js
M Source/WebCore/Modules/indexeddb/IDBRequest.cpp
Log Message:
-----------
Cherry-pick 259548.825@safari-7615-branch (9b3d228ec2cb). rdar://110459666
jsc_fuz/wktr: null ptr deref in
WebCore::IDBRequest::dispatchEvent(WebCore::Event&)
rdar://110459666
Reviewed by Brady Eidson.
Make sure untrusted event does not change the internal state of IDBRequest.
Also, move the assert that request must have
pending activity when event is being dispatched to a later point, because
IDBRequest::dispatchEvent might be invoked
from JavaScript code (i.e. request does not actually have pending activity).
Test: storage/indexeddb/modern/request-dispatch-untrusted-event.html
storage/indexeddb/modern/request-dispatch-untrusted-event-private.html
*
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-expected.txt:
Added.
*
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-private-expected.txt:
Added.
*
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event-private.html:
Added.
*
LayoutTests/storage/indexeddb/modern/request-dispatch-untrusted-event.html:
Added.
*
LayoutTests/storage/indexeddb/modern/resources/request-dispatch-untrusted-event.js:
Added.
(loadImage):
(openDatabase):
* Source/WebCore/Modules/indexeddb/IDBRequest.cpp:
(WebCore::IDBRequest::dispatchEvent):
Canonical link: https://commits.webkit.org/259548.825@safari-7615-branch
Commit: a6294d763dca254a658172d5bc58b80994f5bbe8
https://github.com/WebKit/WebKit/commit/a6294d763dca254a658172d5bc58b80994f5bbe8
Author: Alex Christensen <achristen...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/editing/markup.cpp
Log Message:
-----------
Cherry-pick 259548.830@safari-7615-branch (9cd44913c84e).
https://bugs.webkit.org/show_bug.cgi?id=258100
Disable link preload when sanitizing web content
https://bugs.webkit.org/show_bug.cgi?id=258100
rdar://109675198
Reviewed by Chris Dumez.
Otherwise we get a request in the network process with an invalid pageID,
and it MESSAGE_CHECKs and terminates the process.
* Source/WebCore/editing/markup.cpp:
(WebCore::createPageForSanitizingWebContent):
Canonical link: https://commits.webkit.org/259548.830@safari-7615-branch
Commit: b384b6ffd356f2f4354d6c8696ea447a36c5a083
https://github.com/WebKit/WebKit/commit/b384b6ffd356f2f4354d6c8696ea447a36c5a083
Author: Alex Christensen <achristen...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WTF/wtf/URLHelpers.cpp
M Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm
Log Message:
-----------
Cherry-pick 259548.832@safari-7615-branch (aecf4d579f39).
https://bugs.webkit.org/show_bug.cgi?id=256813
Expand list of URL spoofing characters
https://bugs.webkit.org/show_bug.cgi?id=256813
rdar://109105078, rdar://109056841, and rdar://109056217
Reviewed by Tim Horton.
U+1E9C and U+1E9D are Medievalist characters, which means they haven't been
used much
in the last several centuries. They look kind of like 'f' and other
browsers punycode
encode them when seen in URL hosts, so let's do the same. Same with U+1EFE
and U+1EFF.
Deseret has been used much more recently, but still not much since the late
1800's.
There is a sign in a restaurant in the Salt Lake City airport that uses it,
but it
seems to be a historical reference. Classify Deseret like we do the
International
Phonetic Alphabet and punycode encode it if seen in URL hosts.
* Source/WTF/wtf/URLHelpers.cpp:
(WTF::URLHelpers::isLookalikeCharacter):
* Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/259548.832@safari-7615-branch
Commit: a4748238ffbd3e9629be45b1e2d07d136da17e66
https://github.com/WebKit/WebKit/commit/a4748238ffbd3e9629be45b1e2d07d136da17e66
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A
LayoutTests/fast/workers/pending-requestAnimationFrame-upon-destruction-expected.txt
A
LayoutTests/fast/workers/pending-requestAnimationFrame-upon-destruction.html
A
LayoutTests/fast/workers/resources/pending-requestAnimationFrame-upon-destruction-popup.html
M Source/WebCore/workers/WorkerAnimationController.cpp
Log Message:
-----------
Cherry-pick 259548.833@safari-7615-branch (c60c40574fc5).
https://bugs.webkit.org/show_bug.cgi?id=258058
Crash under
WebCore::JSRequestAnimationFrameCallback::~JSRequestAnimationFrameCallback()
https://bugs.webkit.org/show_bug.cgi?id=258058
rdar://110530772
Reviewed by Ryosuke Niwa.
JSRequestAnimationFrameCallback were outliving the VM and thus using the VM
after-free in their destructor. JS Wrapper should never outlive the VM.
JSRequestAnimationFrameCallback are subclasses of
RequestAnimationFrameCallback,
which were being kept alive by the WorkerAnimationController via its
m_animationCallbacks vector.
To address the issue, WorkerAnimationController now clears
m_animationCallbacks
in stop(), which gets called when the global scope (and thus the VM) are
about
to go away.
*
LayoutTests/fast/workers/pending-requestAnimationFrame-upon-destruction-expected.txt:
Added.
*
LayoutTests/fast/workers/pending-requestAnimationFrame-upon-destruction.html:
Added.
*
LayoutTests/fast/workers/resources/pending-requestAnimationFrame-upon-destruction-popup.html:
Added.
* Source/WebCore/workers/WorkerAnimationController.cpp:
(WebCore::WorkerAnimationController::stop):
Canonical link: https://commits.webkit.org/259548.833@safari-7615-branch
Commit: 21a661fd0240f047fc943f12fb94380709aca2ca
https://github.com/WebKit/WebKit/commit/21a661fd0240f047fc943f12fb94380709aca2ca
Author: Brandon Stewart <brandonstew...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/fast/css-grid-layout/baseline-masonry-crash-expected.html
A LayoutTests/fast/css-grid-layout/baseline-masonry-crash.html
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Cherry-pick 259548.835@safari-7615-branch (b63d45649891).
https://bugs.webkit.org/show_bug.cgi?id=257509
Crash in GridBaselineAlignment::baselineGroupForChild
https://bugs.webkit.org/show_bug.cgi?id=257509
rdar://110027455
Reviewed by Alan Baradlay.
Certain baseline properties are not properly handled in CSS Masonry.
We will just disable these calculations for now and then remove this in the
future.
* LayoutTests/fast/css-grid-layout/baseline-masonry-crash-expected.html:
Added.
* LayoutTests/fast/css-grid-layout/baseline-masonry-crash.html: Added.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::columnAxisBaselineOffsetForChild const):
(WebCore::RenderGrid::rowAxisBaselineOffsetForChild const):
Canonical link: https://commits.webkit.org/259548.835@safari-7615-branch
Commit: 169f297fcb3cb4c1f26c0c22b759044e3a448d48
https://github.com/WebKit/WebKit/commit/169f297fcb3cb4c1f26c0c22b759044e3a448d48
Author: Ryan Reno <rr...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/loader/MixedContentChecker.cpp
Log Message:
-----------
Cherry-pick 259548.841@safari-7615-branch (74f32c21189a).
https://bugs.webkit.org/show_bug.cgi?id=258303
Remove unnecessary release assertion from mixed content checker.
https://bugs.webkit.org/show_bug.cgi?id=258303
<rdar://110766912>
Reviewed by Brent Fulgham.
We now check the entire frame tree for mixed content checks for all
resources loads. An assertion that a document has a frame is no
longer valid in general. This assertion was originally added in
215749@main in an attempt to cover an untestable case. This replaces
the assert with a null check.
* Source/WebCore/loader/MixedContentChecker.cpp:
(WebCore::foundMixedContentInFrameTree):
Canonical link: https://commits.webkit.org/259548.841@safari-7615-branch
Commit: 950982a90668214d1fd91e180fc5db2c6d16391f
https://github.com/WebKit/WebKit/commit/950982a90668214d1fd91e180fc5db2c6d16391f
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 259548.842@safari-7615-branch (e6347f30ecf1).
https://bugs.webkit.org/show_bug.cgi?id=258322
[IPC][Hardening] Validate URLs sent by the WebProcess via the
WebPageProxy::DidFailProvisionalLoad IPC
https://bugs.webkit.org/show_bug.cgi?id=258322
rdar://111059792
Reviewed by Brent Fulgham.
Validate URLs sent by the WebProcess via the
WebPageProxy::DidFailProvisionalLoad IPC.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared):
Canonical link: https://commits.webkit.org/259548.842@safari-7615-branch
Commit: 20aeaf0e736a315ff857d13ce7626f061bc7254c
https://github.com/WebKit/WebKit/commit/20aeaf0e736a315ff857d13ce7626f061bc7254c
Author: David Degazio <d_dega...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A JSTests/wasm/stress/phi-live-across-rethrow.js
A JSTests/wasm/stress/phi-live-across-throw.js
M Source/JavaScriptCore/b3/B3DuplicateTails.cpp
M Source/JavaScriptCore/b3/B3Kind.cpp
M Source/JavaScriptCore/b3/B3Kind.h
M Source/JavaScriptCore/b3/B3PatchpointValue.cpp
M Source/JavaScriptCore/b3/B3PatchpointValue.h
M Source/JavaScriptCore/b3/B3ValueInlines.h
M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
Log Message:
-----------
Cherry-pick 259548.844@safari-7615-branch (2e29306082ae).
https://bugs.webkit.org/show_bug.cgi?id=258408
Prevent duplication of WASM throw and rethrow patchpoints in B3
https://bugs.webkit.org/show_bug.cgi?id=258408
rdar://110634913
Reviewed by Yusuke Suzuki.
Adds a cloningForbidden property to B3Kind, used to prevent a B3 value
from being cloned during optimizations, and applies it to the patchpoints
generated for the WASM throw and rethrow opcodes in WasmB3IRGenerator.
This prevents a problem where these patchpoints could be duplicated, still
share a stackmap/callsite index, but have conflicting live value
locations.
* JSTests/wasm/stress/phi-live-across-rethrow.js: Added.
(async test):
* JSTests/wasm/stress/phi-live-across-throw.js: Added.
(async test):
* Source/JavaScriptCore/b3/B3DuplicateTails.cpp:
* Source/JavaScriptCore/b3/B3Kind.cpp:
(JSC::B3::Kind::dump const):
* Source/JavaScriptCore/b3/B3Kind.h:
(JSC::B3::Kind::hasCloningForbidden):
(JSC::B3::Kind::hasCloningForbidden const):
(JSC::B3::Kind::isCloningForbidden const):
(JSC::B3::Kind::setIsCloningForbidden):
(JSC::B3::Kind::operator== const):
(JSC::B3::Kind::hash const):
(JSC::B3::cloningForbidden):
* Source/JavaScriptCore/b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::PatchpointValue):
* Source/JavaScriptCore/b3/B3PatchpointValue.h:
* Source/JavaScriptCore/b3/B3ValueInlines.h:
(JSC::B3::Value::cloneImpl const):
* Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addThrow):
(JSC::Wasm::B3IRGenerator::addRethrow):
Canonical link: https://commits.webkit.org/259548.844@safari-7615-branch
Commit: 4876897fd30ae1f4831a518a21ba13b66f99a179
https://github.com/WebKit/WebKit/commit/4876897fd30ae1f4831a518a21ba13b66f99a179
Author: Brady Eidson <beid...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
M Source/WebCore/bindings/js/ScriptController.cpp
M Source/WebCore/dom/UserGestureIndicator.cpp
M Source/WebCore/dom/UserGestureIndicator.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/AsyncFunction.mm
Log Message:
-----------
Cherry-pick 259548.840@safari-7615-branch (259842c7afc2). <bug>
Cherry-pick 265168@main (8e5ddea16577). rdar://110919134
evaluateJavaScript: and callAsyncJavaScript: should not leave behind
transient activation
https://bugs.webkit.org/show_bug.cgi?id=258037
rdar://107102031
Reviewed by Ben Nham.
JavaScript evaluated by the client app is executed as if from a user
gesture, which is fine for now.
But before this change, such JS left behind transient user activation
for (currently) 5 seconds, which is not fine.
Let's remove that sticky side effect.
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.cpp:
(WTF::computeSDKAlignedBehaviors):
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WebCore/bindings/js/ScriptController.cpp:
(WebCore::ScriptController::executeScriptInWorld):
(WebCore::ScriptController::executeAsynchronousUserAgentScriptInWorld):
* Source/WebCore/dom/UserGestureIndicator.cpp:
(WebCore::UserGestureToken::forEachImpactedDocument):
* Source/WebCore/dom/UserGestureIndicator.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/AsyncFunction.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265168@main
Canonical link: https://commits.webkit.org/259548.840@safari-7615-branch
Commit: 988aef019b272b6120c8658e88b273322a08a154
https://github.com/WebKit/WebKit/commit/988aef019b272b6120c8658e88b273322a08a154
Author: Brady Eidson <beid...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebCore/bindings/js/RunJavaScriptParameters.h
M Source/WebCore/bindings/js/ScriptController.cpp
M Source/WebKit/Shared/Cocoa/DefaultWebBrowserChecks.h
M Source/WebKit/Shared/Cocoa/DefaultWebBrowserChecks.mm
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
M
Source/WebKit/UIProcess/Inspector/socket/RemoteInspectorProtocolHandler.cpp
Log Message:
-----------
Cherry-pick 259548.854@safari-7615-branch (465b681115e6). rdar://104748908
User agent JavaScript from full web browsers should clear transient
activation.
rdar://104748908
https://bugs.webkit.org/show_bug.cgi?id=251276
Reviewed by Brent Fulgham.
Take the solution from https://commits.webkit.org/265168@main and extend it
to full web browsers now.
* Source/WebCore/bindings/js/RunJavaScriptParameters.h:
(WebCore::RunJavaScriptParameters::RunJavaScriptParameters):
(WebCore::RunJavaScriptParameters::encode const):
(WebCore::RunJavaScriptParameters::decode):
* Source/WebCore/bindings/js/ScriptController.cpp:
(WebCore::ScriptController::executeScriptInWorldIgnoringException):
(WebCore::ScriptController::executeScriptInWorld):
(WebCore::ScriptController::executeUserAgentScriptInWorld):
* Source/WebKit/Shared/Cocoa/DefaultWebBrowserChecks.h:
* Source/WebKit/Shared/Cocoa/DefaultWebBrowserChecks.mm:
(WebKit::shouldEvaluateJavaScriptWithoutTransientActivation):
* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageRunJavaScriptInMainFrame):
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView
_evaluateJavaScript:asAsyncFunction:withSourceURL:withArguments:forceUserGesture:inFrame:inWorld:completionHandler:]):
Canonical link: https://commits.webkit.org/259548.854@safari-7615-branch
Compare: https://github.com/WebKit/WebKit/compare/e5070753347b...988aef019b27
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
