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