Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 75cec00a439631f768dea754cf68c753c63ce185
https://github.com/WebKit/WebKit/commit/75cec00a439631f768dea754cf68c753c63ce185
Author: Simon Fraser <simon.fra...@apple.com>
Date: 2023-10-09 (Mon, 09 Oct 2023)
Changed paths:
A
LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt
A LayoutTests/compositing/reflections/video-mask-reflection-crash.html
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
Log Message:
-----------
Crash under PlatformCALayerRemote::recursiveBuildTransaction()
https://bugs.webkit.org/show_bug.cgi?id=259607
rdar://32076163
Reviewed by Tim Horton.
In some scenarios, we can end up with a PlatformCALayerRemote which remains in
a sublayer list after
being deleted.
The testcase has a <video> which toggles from composited to non-composited and
back. This video has
a mask, and a reflection. The reflection RendeLayer (the RenderReplica's layer)
remains composited.
When this happens, the masks layer's clone remains in the sublayer list of the
"replica flattening"
layer, but it's owning reference, in the LayerClones struct owned by the video
layer, went away when
the video stopped being composited temporarily. The real issue is that we
failed to rebuild the
sublayer list of the "replica flattening" layer in this case, so make sure we
trigger that.
* LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt:
Added.
* LayoutTests/compositing/reflections/video-mask-reflection-crash.html: Added.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::setReplicatedLayer):
Originally-landed-as: 265870.224@safari-7616-branch (73eb68ead0fc).
rdar://116426044
Canonical link: https://commits.webkit.org/269097@main
Commit: 538c84a313edd834976fd519fc3aea603aa5a167
https://github.com/WebKit/WebKit/commit/538c84a313edd834976fd519fc3aea603aa5a167
Author: Abrar Rahman Protyasha <a_protya...@apple.com>
Date: 2023-10-09 (Mon, 09 Oct 2023)
Changed paths:
M Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp
M Source/WebCore/Modules/applepay/ApplePaySetup.cpp
M Source/WebCore/Modules/applepay/PaymentCoordinator.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
Log Message:
-----------
Ensure -[PKPaymentRequest originatingURL] is always set to the top-level
document URL
https://bugs.webkit.org/show_bug.cgi?id=259667
rdar://113143083
Reviewed by Andy Estes.
We support Apple Pay on cross-origin iframes following 262616@main, but
since we are plumbing the iframe domain rather than that of the parent
document embedding said iframe, we lose some Apple Pay domain validation
and abuse detection mitigations.
In this patch, we preserve our existing security mitigations by passing
the top-level domain to `-[PKPaymentRequest setOriginatingURL:]`.
This change also aligns ourselves to the existing shipping model for
payment session domain reporting in iOS 16.
Note that this patch necessitates that a website provide the top level
domain in its merchant session, i.e. "you can iFrame in Apple Pay, but
your merchant session must use the top-level domain". This is a
pre-existing invariant in PassKit, and this commit aligns WebKit in the
same direction.
* Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp:
(WebCore::ApplePayAMSUIPaymentHandler::show):
* Source/WebCore/Modules/applepay/ApplePaySetup.cpp:
(WebCore::ApplePaySetup::begin):
* Source/WebCore/Modules/applepay/PaymentCoordinator.cpp:
(WebCore::PaymentCoordinator::beginPaymentSession):
* Source/WebCore/page/Page.cpp:
(WebCore::Page::startApplePayAMSUISession):
* Source/WebCore/page/Page.h:
Originally-landed-as: 265870.231@eng/105809792_safari-7616-branch
(bb9c7e0fd205). rdar://116426149
Canonical link: https://commits.webkit.org/269098@main
Commit: 08d5d17c766ffc7ca6a7c833c5720eb71b427784
https://github.com/WebKit/WebKit/commit/08d5d17c766ffc7ca6a7c833c5720eb71b427784
Author: Keith Miller <keith_mil...@apple.com>
Date: 2023-10-09 (Mon, 09 Oct 2023)
Changed paths:
A JSTests/stress/getbyoffset-cse-consistency.js
A JSTests/stress/multigetbyoffset-cse-consistency.js
M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGHeapLocation.h
Log Message:
-----------
clobberize needs to be more precise with the *ByOffset nodes
https://bugs.webkit.org/show_bug.cgi?id=261544
rdar://115399657
Reviewed by Yusuke Suzuki and Mark Lam.
CSE phase uses clobberize to figure out if it's safe to merge two operations
that
def the same HeapLocation. Since HeapLocation does not currently have a way to
track the offset used by the various *ByOffset nodes it can get confused and
think that two ByOffset instructions produce the same value even if they don't
use the same offset. This patch solves this by adding a new field to
HeapLocation,
which takes the metadata associated with the corresponding *ByOffset node. If
two
*ByOffset operations don't share the same metadata then they cannot be CSEed.
* Source/JavaScriptCore/dfg/DFGCSEPhase.cpp:
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGHeapLocation.h:
(JSC::DFG::HeapLocation::HeapLocation):
(JSC::DFG::HeapLocation::extraState const):
(JSC::DFG::HeapLocation::hash const):
Originally-landed-as: 265870.558@safari-7616-branch (47e039ffd689).
rdar://116426362
Canonical link: https://commits.webkit.org/269099@main
Compare: https://github.com/WebKit/WebKit/compare/946b13e5e935...08d5d17c766f
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
