[webkit-changes] [WebKit/WebKit] d75147: Bad jsCast<>() in copyDataFromJSArrayToBuses() in ...

Brandon Stewart noreply at github.com
Thu Nov 2 12:03:19 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d7514794b61f7eca9936b334471ac444e2493ace
      https://github.com/WebKit/WebKit/commit/d7514794b61f7eca9936b334471ac444e2493ace
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-11-02 (Thu, 02 Nov 2023)

  Changed paths:
    A LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt
    A LayoutTests/webaudio/audioworklet-bad-array-type.html
    A LayoutTests/webaudio/bad-array-type-processor.js
    M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp

  Log Message:
  -----------
  Bad jsCast<>() in copyDataFromJSArrayToBuses() in AudioWorkletProcessor.cpp
https://bugs.webkit.org/show_bug.cgi?id=261289
rdar://115042475

Reviewed by Ryosuke Niwa.

Use jsDynamicCast<>() instead of jsCast<>() in AudioWorkletProcessor.cpp for
safety.

* LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt: Added.
* LayoutTests/webaudio/audioworklet-bad-array-type.html: Added.
* LayoutTests/webaudio/bad-array-type-processor.js: Added.
(CustomProcessor.prototype.process):
(CustomProcessor):
* Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp:
(WebCore::toJSArray):
(WebCore::toJSObject):
(WebCore::copyDataFromJSArrayToBuses):
(WebCore::AudioWorkletProcessor::process):

Originally-landed-as: 265870.534 at safari-7616-branch (3be781681be0). rdar://117810073
Canonical link: https://commits.webkit.org/270120@main


  Commit: 363afc5630dc2505f43771739954542fa4f58831
      https://github.com/WebKit/WebKit/commit/363afc5630dc2505f43771739954542fa4f58831
  Author: Alexey Shvayka <ashvayka at apple.com>
  Date:   2023-11-02 (Thu, 02 Nov 2023)

  Changed paths:
    A JSTests/stress/regress-114860483.js
    M Source/JavaScriptCore/runtime/JSObject.cpp
    M Source/JavaScriptCore/runtime/JSObjectInlines.h

  Log Message:
  -----------
  JSObject::anyObjectInChainMayInterceptIndexedAccesses and JSObject::didBecomePrototype need to account for JSGlobalProxy
https://bugs.webkit.org/show_bug.cgi?id=261287
rdar://114860483

Reviewed by Yusuke Suzuki.

Since JSObject::anyObjectInChainMayInterceptIndexedAccesses() walks up the [[Prototype]] chain,
whenever an indexed property is defined on a JSGlobalObject, we should add MayHaveIndexedAccessors
flag to JSGlobalProxy instead.

Currently, mayInterceptIndexedAccesses() is never queried on JSGlobalObject instances.

This change also fixes mayBePrototype() to be queried from JSGlobalProxy rather than JSGlobalObject,
which is correct given setPrototypeDirect() used to call didBecomePrototype() only on the proxy.
However, for extra robustness, this we propagate didBecomePrototype() to the global object as well.

* JSTests/stress/regress-114860483.js: Added.
* Source/JavaScriptCore/runtime/JSObjectInlines.h:
(JSC::JSObject::didBecomePrototype):
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):

Originally-landed-as: 265870.535 at safari-7616-branch (049d074c4b1b). rdar://117810163
Canonical link: https://commits.webkit.org/270121@main


  Commit: d73e7a76fb08ed4cd7678293862000808f4e843e
      https://github.com/WebKit/WebKit/commit/d73e7a76fb08ed4cd7678293862000808f4e843e
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2023-11-02 (Thu, 02 Nov 2023)

  Changed paths:
    A LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt
    A LayoutTests/animations/resolve-animation-should-not-execute-scripts.html
    M LayoutTests/platform/ios/imported/w3c/web-platform-tests/screen-orientation/active-lock-expected.txt
    M Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp
    M Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp
    M Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
    M Source/WebCore/animation/WebAnimation.cpp
    M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
    M Source/WebCore/dom/TaskSource.h
    M Source/WebCore/page/ScreenOrientation.cpp

  Log Message:
  -----------
  ScriptDisallowedScope bypass via a `then` getter in Document::updateStyleIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=261256
<rdar://114545310>

Reviewed by Ryosuke Niwa.

This PR addresses several bugs:
1. There is a ScriptDisallowedScope bypass via DeferredPromise::callFunction.
2. WebAnimation::resolve() tries to execute scripts by rejecting promises during updateStyle.
3. WebAnimation::cancel() and WebAnimation::resetPendingTasks() also tries to execute scripts by
rejecting promises during updateStyle.
4. PaymentRequest and PaymentResponse try to reject promises during active DOM object suspension
as well as the script execution context is being stopped.
5. WebAudio tries to reject promises during active DOM object suspension.

For (1), this PR adds a release assertion in DeferredPromise::callFunction like the one we have in
ScriptController::canExecuteScripts. Note this has to be a thread safe variant since this code can be
executed in a worker thread.

For (2), this PR makes WebAnimation::resolve call updateFinishedState with SynchronouslyNotify::No
instead of SynchronouslyNotify::Yes. Note that in the spec [1], the only scenario in which this flag
is set to yes is when the author script calls finish() on an Animation object.

For (3), (4), and (5), this PR makes these actions asynchronous by scheduling a task / microtask
instead of synchronously rejecting promises.

[1] https://drafts.csswg.org/web-animations-1/#update-an-animations-finished-state

Based on original patch by Ryosuke Niwa.

* LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt: Added.
* LayoutTests/animations/resolve-animation-should-not-execute-scripts.html: Added.

* Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp:
(WebCore::PaymentRequest::~PaymentRequest): Now allows pending activity to exist when the associated
script execution context had been stopped.
(WebCore::PaymentRequest::stop): Don't try to settle the promise in the middle of stopping this
active DOM object.
(WebCore::PaymentRequest::suspend): Ditto for suspension. Schedule a task to settle promise instead.

* Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp:
(WebCore::PaymentResponse::~PaymentResponse): Now allows pending activity to exist when
the associated script execution context had been stopped.
(WebCore::PaymentResponse::suspend): Don't try to settle the promise in the middle of stopping this
active DOM object.

* Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp:
(WebCore::OfflineAudioContext::uninitialize): Don't reject the promise when the active DOM objects
had already been stopped.

* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::cancel): Reject the finished promise in a newly scheduled task instead of
synchronously rejecting it, which would result in script execution.
(WebCore::WebAnimation::resolve): Resolve the promise asynchronously.

* Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
(WebCore::DeferredPromise::callFunction): Added a release assertion.
* Source/WebCore/dom/TaskSource.h:

Originally-landed-as: 265870.536 at safari-7616-branch (6d865c4bf3da). rdar://117810274
Canonical link: https://commits.webkit.org/270122@main


  Commit: eb3a8c2925c527c15ac432c60457d5d592be71c3
      https://github.com/WebKit/WebKit/commit/eb3a8c2925c527c15ac432c60457d5d592be71c3
  Author: Brandon Stewart <brandonstewart at apple.com>
  Date:   2023-11-02 (Thu, 02 Nov 2023)

  Changed paths:
    M Source/WebCore/crypto/SubtleCrypto.cpp

  Log Message:
  -----------
  SubtleCrypto:wrapKey ensure promise is not garbage collected
https://bugs.webkit.org/show_bug.cgi?id=261519
rdar://115349445

Reviewed by Tim Nguyen.

We need to ensure that the promise always remains alive when in use.
Adding a RefPtr guarantees that it will not be garbage collected.

* Source/WebCore/crypto/SubtleCrypto.cpp:
(WebCore::SubtleCrypto::wrapKey):

Originally-landed-as: 8e9332694594. rdar://117810508
Canonical link: https://commits.webkit.org/270123@main


Compare: https://github.com/WebKit/WebKit/compare/77c606018747...eb3a8c2925c5


More information about the webkit-changes mailing list