[webkit-changes] [WebKit/WebKit] 75cec0: Crash under PlatformCALayerRemote::recursiveBuildT...

[Keith Miller]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 75cec00a439631f768dea754cf68c753c63ce185
      https://github.com/WebKit/WebKit/commit/75cec00a439631f768dea754cf68c753c63ce185
  Author: Simon Fraser <simon.fraser at 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 at 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_protyasha at 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 at 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 at 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_miller at 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 at safari-7616-branch (47e039ffd689). rdar://116426362
Canonical link: https://commits.webkit.org/269099@main


Compare: https://github.com/WebKit/WebKit/compare/946b13e5e935...08d5d17c766f