[webkit-changes] [WebKit/WebKit] ed51f6: Cherry-pick 265870.234 at safari-7616-branch (9052a03...
Adrian Perez
noreply at github.com
Thu Nov 2 08:43:41 PDT 2023
Branch: refs/heads/webkitglib/2.42
Home: https://github.com/WebKit/WebKit
Commit: ed51f64f11a291efe9b25e4e0131ae4ead8032c7
https://github.com/WebKit/WebKit/commit/ed51f64f11a291efe9b25e4e0131ae4ead8032c7
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm
Log Message:
-----------
Cherry-pick 265870.234 at safari-7616-branch (9052a0395b9b). https://bugs.webkit.org/show_bug.cgi?id=259836
heap-use-after-free in WebKit::AudioSessionRoutingArbitratorProxy::logger
https://bugs.webkit.org/show_bug.cgi?id=259836
rdar://112774591
Reviewed by Simon Fraser.
Move the ALWAYS_LOG() inside the `if (weakThis)` scope since this macro will
call `this->logger()`.
* Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm:
(WebKit::AudioSessionRoutingArbitratorProxy::beginRoutingArbitrationWithCategory):
Canonical link: https://commits.webkit.org/265870.234@safari-7616-branch
Commit: 363afd5bfd6fba06820cff9df4239a32197c6c17
https://github.com/WebKit/WebKit/commit/363afd5bfd6fba06820cff9df4239a32197c6c17
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/platform/mac/ScrollbarsControllerMac.mm
Log Message:
-----------
Cherry-pick 265870.236 at safari-7616-branch (bf54ee3c4df6). https://bugs.webkit.org/show_bug.cgi?id=259890
Use-after-free under WebCore::Scrollbar::supportsUpdateOnSecondaryThread()
https://bugs.webkit.org/show_bug.cgi?id=259890
rdar://113037440
Reviewed by Ryosuke Niwa.
Use a WeakPtr for _scrollbar instead of a raw pointer and add a null-check
in [WebScrollbarPartAnimation setCurrentProgress:].
* Source/WebCore/platform/mac/ScrollbarsControllerMac.mm:
(-[WebScrollbarPartAnimation setCurrentProgress:]):
(-[WebScrollerImpDelegate setUpAlphaAnimation:scrollerPainter:part:animateAlphaTo:duration:]):
(-[WebScrollerImpDelegate scrollerImp:animateUIStateTransitionWithDuration:]):
(-[WebScrollerImpDelegate scrollerImp:animateExpansionTransitionWithDuration:]):
Canonical link: https://commits.webkit.org/265870.236@safari-7616-branch
Commit: 9e4616081fec8a5cd51fa19300ea39bf897346dd
https://github.com/WebKit/WebKit/commit/9e4616081fec8a5cd51fa19300ea39bf897346dd
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp
M Source/WebCore/workers/service/ServiceWorkerGlobalScope.h
Log Message:
-----------
Cherry-pick 265870.237 at safari-7616-branch (76715edd316d). https://bugs.webkit.org/show_bug.cgi?id=259896
Potential use-after-free of the VM under ~FetchEvent()
https://bugs.webkit.org/show_bug.cgi?id=259896
rdar://113148936
Reviewed by Brent Fulgham.
The VM gets destroyed in between the call for WorkerGlobalScope::prepareForDestruction()
and the call for the WorkerGlobalScope destructor. The crash trace indicates that
the ServiceWorkerGlobalScope destructor destroys FetchEvent objects which end up needing
the VM in their destructor.
This is a speculative fix as I cannot reproduce the issue. Brady already imported the
test case at 266608 at main.
* Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:
(WebCore::ServiceWorkerGlobalScope::prepareForDestruction):
* Source/WebCore/workers/service/ServiceWorkerGlobalScope.h:
Canonical link: https://commits.webkit.org/265870.237@safari-7616-branch
Commit: 3942867fc18d2c089c0e230b48a82f71d9cd3669
https://github.com/WebKit/WebKit/commit/3942867fc18d2c089c0e230b48a82f71d9cd3669
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 265870.357 at safari-7616-branch (8e677b301cae). https://bugs.webkit.org/show_bug.cgi?id=260046
Main frame URL is wrong after server-side redirect to a page serving the COOP header
https://bugs.webkit.org/show_bug.cgi?id=260046
rdar://111855179
Reviewed by Brent Fulgham and Alex Christensen.
In the poc, the page is opening a popup (without opener) to the same origin URL1.
This URL1 does a server-side redirect to URL2 which serves the `COOP: same-origin`
HTTP header. After the navigation, Safari was displaying URL1 instead of URL2 in
the URL bar.
It is important to note that that 2 process-swap occur here. The first occurs when
we do the navigation to URL1 in a popup that doesn't have an opener (in the
decidePolicyForNavigationAction). The second one occurs when we receive the
COOP header from URL2 (on navigation response).
In ProvisionalPageProxy::didCreateMainFrame(), we have code which does the following:
```
if (previousMainFrame && !previousMainFrame->provisionalURL().isEmpty()) {
// In case of a process swap after response policy, the didStartProvisionalLoad already happened but the new main frame doesn't know about it
// so we need to tell it so it can update its provisional URL.
m_mainFrame->didStartProvisionalLoad(previousMainFrame->provisionalURL());
}
```
During the second process-swap, we forward the provisional URL from the committed
frame to the provisional one. This is because the didStartProvisionalLoad IPC was
handled by the committed main frame, before we decided to process-swap on resource
response later on. As a result, the provisional main frame doesn't know yet about
the provisional load and we have to let it know about it so it sets its provisional
URL.
This worked fine in the usual case where the COOP process-swap doesn't follow
another process swap. However, in this case, the provisional URL got updated by
an earlier server side redirect which got handled by a provisional frame, not the
committed one. As a result, the committed frame didn't know about the latest
provisional URL, only the original one before the server side redirect.
To address the issue, whenever a provisional main frame receives a server-side
redirect, we now let the committed main frame know about it too so that the
committed frame's provisional URL always stays up-to-date. As a result, when
ProvisionalPageProxy::didCreateMainFrame() forwards the committed frame's URL to
the new provisional frame, it is now accurate.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/265870.357@safari-7616-branch
Commit: d1631eb8f0f589b64da570fa1d075001fe47da50
https://github.com/WebKit/WebKit/commit/d1631eb8f0f589b64da570fa1d075001fe47da50
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M JSTests/stress/regexp-vflag-property-of-strings.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
Cherry-pick 265870.381 at safari-7616-branch (b5b70c4574a7). https://bugs.webkit.org/show_bug.cgi?id=260173
CrashOnOverflow in CharacterClassConstructor::compareUTF32Strings
https://bugs.webkit.org/show_bug.cgi?id=260173
rdar://113872060
Reviewed by Ryosuke Niwa.
Fixed and simplified the the sort comparison function compareUTF32Strings() to properly handle
zero length strings.
Added relevant tests.
* JSTests/stress/regexp-vflag-property-of-strings.js:
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::compareUTF32Strings):
Canonical link: https://commits.webkit.org/265870.381@safari-7616-branch
Commit: 9d9d58fcd5689f18b64a9ced321111cc336841a6
https://github.com/WebKit/WebKit/commit/9d9d58fcd5689f18b64a9ced321111cc336841a6
Author: J Pascoe <j_pascoe at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
Log Message:
-----------
Cherry-pick 265870.403 at safari-7616-branch (43c01fefcaa5). https://bugs.webkit.org/show_bug.cgi?id=260100
Check CSP and X-Frame-Options for subframe AppSSO
https://bugs.webkit.org/show_bug.cgi?id=260100
rdar://108625087
Reviewed by Alex Christensen.
Before this patch, AppSSO unconditionally sets cookies whenever
a session occurs without considering the headers in the response.
This patch starts considering CSP and X-Frame-Options for AppSSO responses.
Added API tests for this behavior.
* Source/WebKit/UIProcess/API/APIFrameInfo.h:
* Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h:
* Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
(WebKit::SOAuthorizationSession::complete):
(WebKit::SOAuthorizationSession::shouldInterruptLoadForXFrameOptions):
(WebKit::SOAuthorizationSession::shouldInterruptLoadForCSPFrameAncestorsOrXFrameOptions):
(): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265870.403@safari-7616-branch
Commit: 9ef1b0b4d50a234078c2f81d1e4bfc31176c0c03
https://github.com/WebKit/WebKit/commit/9ef1b0b4d50a234078c2f81d1e4bfc31176c0c03
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
A JSTests/stress/date-set-time-purify-nan.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 265870.404 at safari-7616-branch (aa32244a89e7). https://bugs.webkit.org/show_bug.cgi?id=260497
[JSC] Purify NaN for Date#setTime DFG / FTL implementations
https://bugs.webkit.org/show_bug.cgi?id=260497
rdar://114177456
Reviewed by Mark Lam.
Date#setTime should purify NaN, otherwise, it can put arbitrary NaN boxed values, and cause type-confusion.
We can just use canonical NaN when the input is NaN.
* JSTests/stress/date-set-time-purify-nan.js: Added.
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileDateSet):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
Canonical link: https://commits.webkit.org/265870.404@safari-7616-branch
Commit: bf680fe857b85b3c04f906f674ed21422d5d14fd
https://github.com/WebKit/WebKit/commit/bf680fe857b85b3c04f906f674ed21422d5d14fd
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
A JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/dfg/DFGGraph.h
Log Message:
-----------
Cherry-pick 265870.440 at safari-7616-branch (965be685c2ff). https://bugs.webkit.org/show_bug.cgi?id=260678
[JSC] DFG AI GetById adhoc folding should insert watchpoints for structures
https://bugs.webkit.org/show_bug.cgi?id=260678
rdar://114072069
Reviewed by Keith Miller.
For DFG AI GetById's variants, they are tuples of StructureSet and offset.
So, we should not obtain constant property just with offset since we first need to
ensure that the base object is having a structure in StructureSet.
Let's say [S0, 0] [S1, 1] variants are produced. In that case, we should not load
a value from offset 1 when object is S0. But previously we were doing that since
only thing we checked is that base is S0 or S1.
This patch just extends DFG AI GetById handling to use existing tryGetConstantProperty
mechanism with StructureSet. This properly inserts replacement watchpoints too, so that
we can guarantee that the loaded value is inferred constant (if it gets different, then
watchpoint fires). And we correctly check that the current object's structure is meeting
the requirement against *variant*'s structure set.
* JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js: Added.
(main.const.object1):
(main.const.object2):
(main.const.object3):
(main.get opt):
(main):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::inferredValueForProperty):
* Source/JavaScriptCore/dfg/DFGGraph.h:
Canonical link: https://commits.webkit.org/265870.440@safari-7616-branch
Commit: c78253385448723d17a89b7ebeb0b30586cecc44
https://github.com/WebKit/WebKit/commit/c78253385448723d17a89b7ebeb0b30586cecc44
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/platform/graphics/Region.cpp
Log Message:
-----------
Cherry-pick 265870.452 at safari-7616-branch (ca4f7c9b9939). https://bugs.webkit.org/show_bug.cgi?id=260757
WebContent may get killed due to invalid RemoteLayerTreeDrawingAreaProxy_CommitLayerTree IPC message
https://bugs.webkit.org/show_bug.cgi?id=260757
rdar://113860744
Reviewed by Aditya Keerthi.
The fuzzer found a case where the RemoteLayerTreeDrawingAreaProxy_CommitLayerTree
IPC message may fail decoding because its contains an invalid IntRect. After some
investigation, I found that we didn't handle overflows in the arithmetics in
Region::Shape::bounds(), which means that we could end up with an IntRect that
had a negative width or height.
In the fuzzer case, we ended up with the following values:
minX=-2147483648, minY=3, maxX=62, maxY=2306
We would compute the width doing `62 - (-2147483648)` which would overflow and end
up with a negative width. We now use checkedDifference<int32_t>() to detect
overflows and clamp to std::numeric_limits<int32_t>::max() when it happens.
* Source/WebCore/platform/graphics/Region.cpp:
(WebCore::Region::Shape::bounds const):
Canonical link: https://commits.webkit.org/265870.452@safari-7616-branch
Commit: 610a6cbb21dcad1bf521bce0a288b965b498dfa9
https://github.com/WebKit/WebKit/commit/610a6cbb21dcad1bf521bce0a288b965b498dfa9
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
M Source/WebCore/Modules/mediarecorder/MediaRecorder.h
Log Message:
-----------
Cherry-pick 265870.463 at safari-7616-branch (f255dd40b82e). https://bugs.webkit.org/show_bug.cgi?id=260736
CRASH in MediaRecorderPrivate::startRecording()
https://bugs.webkit.org/show_bug.cgi?id=260736
rdar://113544631
Reviewed by Brent Fulgham and Eric Carlson.
MediaRecorder can be destroyed before the completion handler passed to
MediaRecorderPrivate::startRecording() is called. Detect this state by
passing a WeakPtr into the completion handler lambda. Because MediaRecoder
has multiple base classes which are CanMakeWeakPtr subclasses, disambiguate
which subclass's WeakPtr implementation to use in the MediaRecoder class
declaration.
* Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp:
(WebCore::MediaRecorder::startRecording):
* Source/WebCore/Modules/mediarecorder/MediaRecorder.h:
Canonical link: https://commits.webkit.org/265870.463@safari-7616-branch
Commit: f843025f13282977533aa26efcf93caf92f08710
https://github.com/WebKit/WebKit/commit/f843025f13282977533aa26efcf93caf92f08710
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 265870.467 at safari-7616-branch (1f9e21240663). https://bugs.webkit.org/show_bug.cgi?id=260822
CloneDeserializer::readBigInt() should check for overflow when reifying JSBigInt length on 32-bit platforms.
https://bugs.webkit.org/show_bug.cgi?id=260822
rdar://114547822
Reviewed by Chris Dumez.
The serialized length is a number of Uint64 elements. On 32-bit platforms, this length gets multiplied by 2 in
order to compute the actual length of the backing store to re-construct the JSBigInt. Both the transmitted length
and the JSBigInt length is stored as uint32_t. Hence, the 2x multiplication can theoretically result in an
overflow. This patch adds an overflow check to handle this edge case.
Also renamed lengthInUint64 to numberOfUint64Elements. lengthInUint64 can be misread to mean a length stored as a
uint64_t value, which is not what it actually means. The length value is store in a uint32_t, and is a count of
the number of uint64_t sized elements.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::dumpHeapBigIntData):
(WebCore::CloneDeserializer::readBigInt):
Canonical link: https://commits.webkit.org/265870.467@safari-7616-branch
Commit: 331906ed656dfe5747ade12430d445e0f5922d6d
https://github.com/WebKit/WebKit/commit/331906ed656dfe5747ade12430d445e0f5922d6d
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/html/HTMLInputElement.cpp
M Source/WebCore/html/HTMLInputElement.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Shared/FocusedElementInformation.h
M Source/WebKit/Shared/FocusedElementInformation.serialization.in
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
M Tools/TestWebKitAPI/ios/UIKitSPI.h
Log Message:
-----------
Cherry-pick 265870.476 at safari-7616-branch (5cfdf9b1cbac). https://bugs.webkit.org/show_bug.cgi?id=260864
[iOS] Keyboard should not learn autocorrections after revealing password in Gmail login flow
https://bugs.webkit.org/show_bug.cgi?id=260864
rdar://111393742
Reviewed by Aditya Keerthi.
When focusing and editing secure inputs (i.e. input type="password"), we set `isSecureTextEntry` on
`UITextInputTraits` to `YES`, which disables autocorrection learning when the user types in this
field, suppresses the keyboard in screen recordings, and more.
However, some webpages (e.g. Gmail login) offer the ability to reveal the password as plain text as
a convenience to the user — this typically works by changing the input type from `"password"` to
just `"text"`. This currently causes all of the secure text entry behaviors to be disabled, which
includes disabling correction learning; this is undesirable, since the password may be offered as an
autocorrection candidate when editing in other plain text fields in the future, in non-secure
contexts.
Because the user opted to reveal the input, it doesn't really make sense to treat the input as fully
secure (for instance, there's no reason to suppress keyboard visibility in screen recordings if the
password text itself is fully visible). However, we need to (at least) prevent the keyboard from
learning suggestions when typing in this field. To achieve this, we add a flag on `HTMLInputElement`
to remember whether it was ever a password field; if so, we set the `-learnsCorrections` property on
text input traits to `NO`.
Test: AutocorrectionTests.DoNotLearnCorrectionsAfterChangingInputTypeFromPassword
* Source/WebCore/html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::runPostTypeUpdateTasks):
Set `m_hasEverBeenPasswordField` here.
* Source/WebCore/html/HTMLInputElement.h:
(WebCore::HTMLInputElement::hasEverBeenPasswordField const):
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/Shared/FocusedElementInformation.h:
* Source/WebKit/Shared/FocusedElementInformation.serialization.in:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateTextInputTraits:]):
Consult `hasEverBeenPasswordField` on the focused element information, and disable learning from
corrections if it's set.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
Propagate `hasEverBeenPasswordField` state to the UI process when focusing an input element.
(WebKit::WebPage::focusedElementInformation):
* Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
Add an API test to exercise the change.
* Tools/TestWebKitAPI/ios/UIKitSPI.h:
Canonical link: https://commits.webkit.org/265870.476@safari-7616-branch
Commit: bdeaa5d7c60fa63947ecf14d6ab7246d45653a00
https://github.com/WebKit/WebKit/commit/bdeaa5d7c60fa63947ecf14d6ab7246d45653a00
Author: Antti Koivisto <antti at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
A LayoutTests/fast/css/style-scope-destruction-crash-expected.txt
A LayoutTests/fast/css/style-scope-destruction-crash.html
M Source/WebCore/rendering/PathOperation.cpp
M Source/WebCore/rendering/PathOperation.h
M Source/WebCore/style/StyleScope.cpp
Log Message:
-----------
Cherry-pick 265870.481 at safari-7616-branch (382b02a5fc10). https://bugs.webkit.org/show_bug.cgi?id=260896
heap-use-after-free | Style::Scope::removeStyleSheetCandidateNode; WebCore::SVGStyleElement::~SVGStyleElement; WebCore::ContainerNode::~ContainerNode
https://bugs.webkit.org/show_bug.cgi?id=260896
rdar://114231775
Reviewed by Alan Baradlay.
* LayoutTests/fast/css/style-scope-destruction-crash-expected.txt: Added.
* LayoutTests/fast/css/style-scope-destruction-crash.html: Added.
* Source/WebCore/rendering/PathOperation.cpp:
(WebCore::ReferencePathOperation::ReferencePathOperation):
(WebCore::ReferencePathOperation::element const): Deleted.
Get rid of the unused element field. This creates a RenderStyle -> DOM ownership cycle which
allows this crash to happen.
* Source/WebCore/rendering/PathOperation.h:
* Source/WebCore/style/StyleScope.cpp:
(WebCore::Style::Scope::~Scope):
Ensure we revoke weak pointers at the start of the destructor to avoid this class of problems.
Canonical link: https://commits.webkit.org/265870.481@safari-7616-branch
Commit: 20c4be22ba9848b0343a512040788af55f3d5a91
https://github.com/WebKit/WebKit/commit/20c4be22ba9848b0343a512040788af55f3d5a91
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/platform/audio/SincResampler.h
Log Message:
-----------
Cherry-pick 265870.482 at safari-7616-branch (aae3b70b0eff). https://bugs.webkit.org/show_bug.cgi?id=260933
Make WebCore::SincResampler testable
https://bugs.webkit.org/show_bug.cgi?id=260933
<rdar://114732348>
Reviewed by Chris Dumez.
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
- Make SincResampler.h a private header.
* Source/WebCore/platform/audio/SincResampler.h:
(WebCore::SincResampler::processBuffer):
- Export static class method.
Canonical link: https://commits.webkit.org/265870.482@safari-7616-branch
Commit: a30532513b4498ff1be9996add1de16696cc7dfa
https://github.com/WebKit/WebKit/commit/a30532513b4498ff1be9996add1de16696cc7dfa
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-19 (Thu, 19 Oct 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt
A LayoutTests/fast/frames/frame-append-body-child-crash.html
M Source/WebCore/html/HTMLBodyElement.cpp
Log Message:
-----------
Cherry-pick 265870.486 at safari-7616-branch (3fc6931dcc2c). https://bugs.webkit.org/show_bug.cgi?id=260907
Crash under HTMLBodyElement::didFinishInsertingNode()
https://bugs.webkit.org/show_bug.cgi?id=260907
rdar://114177696
Reviewed by Ryosuke Niwa.
When a <body> is inserted into the document, `HTMLBodyElement::insertedIntoAncestor()`
gets called. This function would only return `InsertedIntoAncestorResult::NeedsPostInsertionCallback`
if `is<HTMLFrameElementBase>(document().ownerElement())`, causing `HTMLBodyElement::didFinishInsertingNode()`
to get called later on. We would then assume in didFinishInsertingNode() that the document's owner element
is a non-null HTMLFrameElementBase.
However, as proven by the test, DOM manipulations can happen in between the 2 calls
causing the assertion to no longer hold. To address the issue we now early return
if `is<HTMLFrameElementBase>(document().ownerElement())` is no longer true in
`HTMLBodyElement::didFinishInsertingNode()`.
In the case of the test, `document().frame()` becomes null because the frame gets
detached, causing `document().ownerElement()` to return null as well.
* LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt: Added.
* LayoutTests/fast/frames/frame-append-body-child-crash.html: Added.
* Source/WebCore/html/HTMLBodyElement.cpp:
(WebCore::HTMLBodyElement::didFinishInsertingNode):
Canonical link: https://commits.webkit.org/265870.486@safari-7616-branch
Commit: e0e6399d979e76db566ad2eab38db8c9577d4837
https://github.com/WebKit/WebKit/commit/e0e6399d979e76db566ad2eab38db8c9577d4837
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 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:
-----------
Cherry-pick 265870.534 at safari-7616-branch (3be781681be0). https://bugs.webkit.org/show_bug.cgi?id=261289
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):
Canonical link: https://commits.webkit.org/265870.534@safari-7616-branch
Commit: 62bc9d115f69618d6ea221f616c72f64e13e1a7c
https://github.com/WebKit/WebKit/commit/62bc9d115f69618d6ea221f616c72f64e13e1a7c
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
A JSTests/stress/regress-114860483.js
M Source/JavaScriptCore/runtime/JSObject.cpp
M Source/JavaScriptCore/runtime/JSObjectInlines.h
Log Message:
-----------
Cherry-pick 265870.535 at safari-7616-branch (049d074c4b1b). https://bugs.webkit.org/show_bug.cgi?id=261287
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):
Canonical link: https://commits.webkit.org/265870.535@safari-7616-branch
Commit: da56ace715856dbed69d2a2fd79142a4cfd68997
https://github.com/WebKit/WebKit/commit/da56ace715856dbed69d2a2fd79142a4cfd68997
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-10-20 (Fri, 20 Oct 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:
-----------
Cherry-pick 265870.536 at safari-7616-branch (6d865c4bf3da). https://bugs.webkit.org/show_bug.cgi?id=261256
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:
Canonical link: https://commits.webkit.org/265870.536@safari-7616-branch
Commit: aa2b734db49912b00ea9b1fd38714a3ddc6d1d9c
https://github.com/WebKit/WebKit/commit/aa2b734db49912b00ea9b1fd38714a3ddc6d1d9c
Author: Abigail Fox <abigail_fox at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
M Source/WTF/wtf/Vector.h
Log Message:
-----------
Cherry-pick 265870.553 at safari-7616-branch (1393b618ad01). https://bugs.webkit.org/show_bug.cgi?id=261220
WTF::Vector cross-container overflow ASAN support
https://bugs.webkit.org/show_bug.cgi?id=261220
rdar://113692853
Reviewed by David Kilzer.
Added check in ASAN builds for container overflow
* Source/WTF/wtf/Vector.h:
(WTF::Malloc>::asanBufferSizeWillChangeTo):
(WTF::Malloc>::uncheckedAppend):
* Tools/TestWebKitAPI/Tests/WTF/Vector.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265870.553@safari-7616-branch
Commit: 778c0252b606286f2015319504b2e944662ff697
https://github.com/WebKit/WebKit/commit/778c0252b606286f2015319504b2e944662ff697
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h
Log Message:
-----------
Cherry-pick 265870.557 at safari-7616-branch (5dd0bac29991). https://bugs.webkit.org/show_bug.cgi?id=261200
NetworkRTCProvider::doSocketTaskOnRTCNetworkThread should protect iself
https://bugs.webkit.org/show_bug.cgi?id=261200
rdar://112521277
Reviewed by Eric Carlson.
Make sure to ref NetworkRTCProvider before hopping to another thread.
We mark NetworkRTCProvider as DestructionThread::MainRunLoop to ensure it gets destroyed in main run loop.
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:
(WebKit::NetworkRTCProvider::createClientTCPSocket):
(WebKit::NetworkRTCProvider::doSocketTaskOnRTCNetworkThread):
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h:
Canonical link: https://commits.webkit.org/265870.557@safari-7616-branch
Commit: 4f150b6eca02e2d05719ade9dcb2cdb2868ea918
https://github.com/WebKit/WebKit/commit/4f150b6eca02e2d05719ade9dcb2cdb2868ea918
Author: Brandon Stewart <brandonstewart at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
M Source/WebCore/crypto/SubtleCrypto.cpp
Log Message:
-----------
Cherry-pick 265870.559 at safari-7616-branch (8e9332694594). https://bugs.webkit.org/show_bug.cgi?id=261519
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):
Canonical link: https://commits.webkit.org/265870.559@safari-7616-branch
Commit: 39906508cf32752207a10f77bf4fa96fe8b49f68
https://github.com/WebKit/WebKit/commit/39906508cf32752207a10f77bf4fa96fe8b49f68
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
Log Message:
-----------
Cherry-pick 265870.560 at safari-7616-branch (0f4469003671). rdar://113770369
AX: Heap-use-after-free in WebCore::AXObjectCache::get(WebCore::Node*)+0x41c
rdar://113770369
Reviewed by Ryosuke Niwa.
This UAF is most likely caused by a mutation in the WeakListHashSet while iterating over it. This patch avoids the problem by copying the set to a Vector and iterating over the Vector.
The same technique is applied to another iteration over a WeakListHashsSet, m_deferredNodeAddedOrRemovedList, in the same method.
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::performDeferredCacheUpdate):
Canonical link: https://commits.webkit.org/265870.560@safari-7616-branch
Commit: 466056288105e42969f244bd33862ef050925994
https://github.com/WebKit/WebKit/commit/466056288105e42969f244bd33862ef050925994
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-10-20 (Fri, 20 Oct 2023)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 265870.574 at safari-7616-branch (58238f2ad1a0). https://bugs.webkit.org/show_bug.cgi?id=261801
CloneDeserializer should always purifyNaN all double values it reads.
https://bugs.webkit.org/show_bug.cgi?id=261801
rdar://115756664
Reviewed by Yusuke Suzuki.
CloneDeserializer::read() will now invoke purifyNaN() on any double values that it reads.
As a result, we can remove the 2 purifyNaN calls in its client that are now redundant.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::read):
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/265870.574@safari-7616-branch
Commit: 325c110d98657180020871982ca9be36660ca789
https://github.com/WebKit/WebKit/commit/325c110d98657180020871982ca9be36660ca789
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-10-24 (Tue, 24 Oct 2023)
Changed paths:
A LayoutTests/webaudio/promise-resolution-crash-expected.txt
A LayoutTests/webaudio/promise-resolution-crash.html
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
Log Message:
-----------
Cherry-pick 265870.579 at safari-7616-branch (587ed3048a75). https://bugs.webkit.org/show_bug.cgi?id=261829
Regression(265870.536 at safari-7616-branch) Crashes under DeferredPromise::callFunction()
https://bugs.webkit.org/show_bug.cgi?id=261829
rdar://115712299
Reviewed by Brent Fulgham and Mark Lam.
The RELEASE_ASSERT() added by Ryosuke in 265870.536 at safari-7616-branch in DeferredPromise::callFunction()
is hitting a lot in the wild, from various call sites. The assertion makes sure we're allowed to run
script when resolving a promise (i.e. we're not in the middle of layout or style resolution).
* LayoutTests/webaudio/promise-resolution-crash-expected.txt: Added.
* LayoutTests/webaudio/promise-resolution-crash.html: Added.
New test coverage.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
(WebCore::DeferredPromise::callFunction):
Drop the release assertion and instead schedule a task to resolve the promise
asynchronously when we're not allowed to run script, similarly to what we were
already doing when b/f cache suspended.
Canonical link: https://commits.webkit.org/265870.579@safari-7616-branch
Commit: 027d2d68cdf8a5b7678015efbf98dfedf42e6e79
https://github.com/WebKit/WebKit/commit/027d2d68cdf8a5b7678015efbf98dfedf42e6e79
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-10-24 (Tue, 24 Oct 2023)
Changed paths:
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/resize_test.cc
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/common/vp9_alloccommon.c
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c
Log Message:
-----------
Cherry-pick 265870.611 at safari-7616.2.9.10-branch (6de839091b9f). <bug>
Cherry-pick 505f26eea3a5. rdar://116293231
VP9 additional changes related to CVE-2023-5217
rdar://116293231
Reviewed by Jean-Yves Avenard.
Cherry-picking patches that do hardening of VP9 encoder reconfiguration:
- 02ab555e992c191e5c509ed87b3cc48ed915b447
- 263682c9a29395055f3b3afe2d97be1828a6223f
I had to update CHECK_MEM_ERROR call site since we need to pass cm currently, while they do pass cm->error upstream.
While we do not think we are exercising this code path of reconfiguring while encoding,
it is future proof and low risk to cherry-pick these changes.
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/resize_test.cc:
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/common/vp9_alloccommon.c:
(free_seg_map):
(vp9_free_context_buffers):
(vp9_alloc_context_buffers):
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c:
(free_copy_partition_data):
(vp9_change_config):
Canonical link: https://commits.webkit.org/267815.170@safari-7617-branch
Canonical link: https://commits.webkit.org/265870.611@safari-7616.2.9.10-branch
Compare: https://github.com/WebKit/WebKit/compare/2725c3d1aec9...027d2d68cdf8
More information about the webkit-changes
mailing list