Branch: refs/heads/safari-7622.2.11.10-branch
Home: https://github.com/WebKit/WebKit
Commit: 5534839094e02dc8e79a05021c8865ddce4fa2af
https://github.com/WebKit/WebKit/commit/5534839094e02dc8e79a05021c8865ddce4fa2af
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: e603cb477c1ba159bd3a896569c6ec205f982ceb
https://github.com/WebKit/WebKit/commit/e603cb477c1ba159bd3a896569c6ec205f982ceb
Author: Keith Miller <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
A JSTests/stress/array-allocation-sink-conditional-write-osr.js
A JSTests/stress/array-sink-materialize-conditional-write-argument-value.js
A JSTests/stress/array-sink-materialize-conditional-write.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 934b1e28a87a. rdar://162144480
Conditional writes are incorrectly handled in Array allocation sinking
https://bugs.webkit.org/show_bug.cgi?id=299956
rdar://161681941
Reviewed by Yusuke Suzuki and Yijia Huang.
The current bottom value in ObjectAllocationSinking is incorrect for arrays.
Unlike with objects, which track conditional stores by passing the active
structure through SSA, arrays can't do this. Instead we should set default
value
to the appropriate hole value for the given IndexingShape. To make this work
I had to fix some Phi/Upsilon ResultFormat bugs since they previously
assumed
everything would be a JSValue.
Also, add ASSERT to FTL lowering that the Phi/Upsilon formats match. I
spent 1/2 a day
trying to understand why I was getting zero, when the issue was those
values disagreed
and I was getting the default zero value.
Tests: JSTests/stress/array-allocation-sink-conditional-write-osr.js
JSTests/stress/array-sink-materialize-conditional-write-argument-value.js
JSTests/stress/array-sink-materialize-conditional-write.js
Canonical link: https://commits.webkit.org/300888@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 80f7cdec45b2239dd7cb04c7348a99e99f9b14e4
https://github.com/WebKit/WebKit/commit/80f7cdec45b2239dd7cb04c7348a99e99f9b14e4
Author: Alan Baradlay <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
A LayoutTests/fast/repaint/new-deprecated-flex-item-repaint-expected.txt
A LayoutTests/fast/repaint/new-deprecated-flex-item-repaint.html
A
LayoutTests/platform/mac-wk1/fast/repaint/new-deprecated-flex-item-repaint-expected.txt
M Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp
Log Message:
-----------
Cherry-pick a9981fc4ecfa. rdar://162151781
Text in voice search is cropped on baidu.com
https://bugs.webkit.org/show_bug.cgi?id=300283
<rdar://154781269>
Reviewed by Antti Koivisto.
This is the deprecated flex box version of 199925@main fix where we need to
issue
full repaint on flex items that never had layout before.
Test: fast/repaint/new-deprecated-flex-item-repaint.html
* LayoutTests/fast/repaint/new-deprecated-flex-item-repaint-expected.txt:
Added.
* LayoutTests/fast/repaint/new-deprecated-flex-item-repaint.html: Added.
*
LayoutTests/platform/mac-wk1/fast/repaint/new-deprecated-flex-item-repaint-expected.txt:
Added.
* Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:
(WebCore::issueFullRepaintOnFirstLayout):
(WebCore::layoutChildIfNeededApplyingDelta):
(WebCore::RenderDeprecatedFlexibleBox::layoutSingleClampedFlexItem):
(WebCore::RenderDeprecatedFlexibleBox::layoutVerticalBox):
Canonical link: https://commits.webkit.org/301147@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 31969a1955f9408794a31a647ebe2aa72593f5a8
https://github.com/WebKit/WebKit/commit/31969a1955f9408794a31a647ebe2aa72593f5a8
Author: Sihui Liu <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp
Log Message:
-----------
Cherry-pick b290846137ed. rdar://162138327
ASSERTION FAILED: checkedPtrCountWithoutThreadCheck() in
SQLiteStorageArea::prepareDatabase
https://bugs.webkit.org/show_bug.cgi?id=300294
rdar://162083739
Reviewed by Chris Dumez.
SQLiteStorageArea::prepareDatabase might set m_database to null after
m_database is captured in a local CheckedPtr
variable resultDatabase. When the CheckedPtr variable is destroyed at
function exit, the assertion will be hit as the
SQLiteDatabase object is already gone. To fix this, this patch uses a local
UniqueRef variable to replace the
CheckedPtr. The UniqueRef is only moved to m_database if operation
succeeds, so prepareDatabase does not need to reset
m_database in multiple conditions.
This patch also contains a drive-by fix that when prepareDatabase tries to
open database for the second time, it does
not pass the right open options.
Canonical link: https://commits.webkit.org/301155@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9f7d32add5ab709766a7b83165c4509bf965d6de
https://github.com/WebKit/WebKit/commit/9f7d32add5ab709766a7b83165c4509bf965d6de
Author: Lily Spiniolas <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
A
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div-expected.txt
A
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html
M LayoutTests/resources/ui-helper.js
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Cherry-pick 081f5360d06e. rdar://162144018
[iOS] Cannot scroll on gemini.google.com after sending message
https://bugs.webkit.org/show_bug.cgi?id=300153
rdar://157042896
Reviewed by Wenson Hsieh.
When selection honors overflow scrolling is enabled (specifically after
285350@main,
in which we switched from tracking scroll containers for the selection to
tracking
the graphics layer for the selection), scrolling does not work as expected
on
gemini.google.com. After typing a message and hitting the send button, it
is not
possible to scroll in the conversation log until the log is tapped. This is
the
result of views related to text selection impacting the results of
`hitTest:` in
`WKScrollView`. To prevent this from happening, there is existing logic
which calls
`makeTextSelectionViewsNonInteractiveForScope` which ensures that user
interaction
is disabled for all views in `[_textInteractionWrapper
managedTextSelectionViews]`.
However, `managedTextSelectionViews` may be empty even when views related
to text
selection are present in the view hierarchy (this is the case on
gemini.google.com).
In this scenario, `makeTextSelectionViewsNonInteractiveForScope` fails to
disable
user interaction on the text selection views, causing them to impact hit
test results.
The emptiness of `managedTextSelectionViews` is the result of the following:
After the page loads but before user interaction:
1. gemini.google.com programmatically focuses a contenteditable div on page
load (the
message field), causing a selection to be made.
2. `prepareToMoveSelectionContainer:(UIView *)newContainer` is called as a
result
of the selection. `newContainer` is not yet the `superview` of the
display interaction's
highlight view, so `[displayInteraction willMoveToView:_view]` &
`[displayInteraction didMoveToView:_view]` are called to move the views
related to
text selection.
3. To determine which views are related to text selection, we compare the
descendants
of newContainer before calling `willMoveToView` and `didMoveToView` as
mentioned above
to the descendants afterwards. These views are stored in
_managedTextSelectionViews.
4. Critically, UIKit does not actually install any views because the
interaction is not
in the activated state (the focus which got us here was programmatic).
There is no
difference between the before and after state, so
_managedTextSelectionViews remains
empty.
After activating and typing in the message field:
5. The selection/highlight views are installed by UIKit as expected.
`prepareToMoveSelectionContainer:(UIView *)newContainer` is called
afterwards, but the
highlight/selection views have already been appended to the new
container.
_managedTextSelectionViews is thus not updated, and remains empty.
After the send button is pressed:
6. The selection is not cleared despite editing ending. This is because the
message field
is a contenteditable div rather than a text input or textarea (see
webkit.org/b/38696).
The highlight views remain installed as a result.
After attempting to scroll:
7. To prevent the selection/highlight views from interfering with the
scroll view's hit test,
we temporarily disable user interaction for all of the
selection/highlight views stored in
_managedTextSelectionViews. In this case, _managedTextSelectionViews is
empty despite the
presence of the views. The hit test breaks, and scrolling does not work
as a result.
To fix this, we simply activate the display interaction before calling
`willMoveToView` and
`didMoveToView`.
Added new UIHelper method `setFocusStartsInputSessionPolicy` to change the
input session policy
during a test. This is important for the newly added layout test because to
mimic the behavior
of a physical device without a hardware keyboard, we must start the test
with the policy set
to `disallow`, and then later restore it to "auto". This is required so
that we can avoid showing
keyboard UI on the initial programmatic focus (which would have started an
actual editing session)
and then later show the keyboard UI after activating the input field, just
like a physical device
without a hardware keyboard attached.
Test:
editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html
*
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div-expected.txt:
Added.
*
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html:
Added.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.setFocusStartsInputSessionPolicy):
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper prepareToMoveSelectionContainer:]):
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::setFocusStartsInputSessionPolicy):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::setFocusStartsInputSessionPolicy):
Canonical link: https://commits.webkit.org/301162@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: ef81817a533dfc31749ac51b2e27b1ec99a58775
https://github.com/WebKit/WebKit/commit/ef81817a533dfc31749ac51b2e27b1ec99a58775
Author: Dan Hecht <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
A JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap2.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Cherry-pick d37b918c6ed2. rdar://158848294
[JSC] BBQ does not have implicit exception slot inside Try
https://bugs.webkit.org/show_bug.cgi?id=300350
rdar://158848294
Reviewed by Yusuke Suzuki.
Follow up to 297297.400@safari-7622-branch: do not access
BBQJIT::exception() for Try blocks, and fill the Void stack map
entry with a zero constant so that loadValuesIntoBuffer() will
zero fill this placeholder slot when constructing the scratch buffer
for BBQ -> OMG loop OSR.
* JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap2.js:
Added.
(instantiate):
(async let.fn0):
(let.fn1):
(let.fn2):
(let.fn3):
(let.fn4):
(let.fn5):
(async let):
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::exception):
(JSC::Wasm::BBQJITImpl::BBQJIT::makeStackMap):
Canonical link: https://commits.webkit.org/297297.520@safari-7622-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: e3f2cdfcef278b11f4f1cafdee591a9f430b6d54
https://github.com/WebKit/WebKit/commit/e3f2cdfcef278b11f4f1cafdee591a9f430b6d54
Author: Dana Estra <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M Source/WebCore/Modules/mediasession/MediaSession.h
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/page/QuirksData.h
M Source/WebKit/WebProcess/cocoa/PlaybackSessionManager.mm
Log Message:
-----------
Cherry-pick 12c053fe9372. rdar://160307005
Cherry-pick 902a75fcfd40. rdar://158430821
HBO Max videos are labeled as ads in PiP
https://bugs.webkit.org/show_bug.cgi?id=298611
rdar://158430821
Reviewed by Ryan Reno.
HBO sets the skipAd action handler to an empty function, presumably
to attempt to say that the user cannot skip ads in pip. Until they
remove this, we should quirk HBO to not allow ad skipping on the site.
* Source/WebCore/Modules/mediasession/MediaSession.h:
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldDisableAdSkippingInPip const):
(WebCore::handleHBOMaxQuirks):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/page/QuirksData.h:
* Source/WebKit/WebProcess/cocoa/PlaybackSessionManager.mm:
(WebKit::PlaybackSessionManager::actionHandlersChanged):
Canonical link: https://commits.webkit.org/299784@main
Update MediaSession.h
(cherry picked from commit e069374fbd3348481aa0d18989fd763cdcf3c9ed)
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 3e4e95e278764ecae2c5ee203da37ce865c3be50
https://github.com/WebKit/WebKit/commit/3e4e95e278764ecae2c5ee203da37ce865c3be50
Author: Wenson Hsieh <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M Source/WebKit/WebProcess/cocoa/PlaybackSessionManager.mm
Log Message:
-----------
Cherry-pick 9b69ee2add84. rdar://160307005
Cherry-pick 9546eecd7fc7. rdar://160307005
Unreviewed, fix the build after 299784@main
Change:
```
if (RefPtr page = m_page.get() && !skipAdIsDisabledQuirk)
```
to:
```
if (RefPtr page = m_page.get(); page && !skipAdIsDisabledQuirk)
```
* Source/WebKit/WebProcess/cocoa/PlaybackSessionManager.mm:
(WebKit::PlaybackSessionManager::actionHandlersChanged):
Canonical link: https://commits.webkit.org/299789@main
(cherry picked from commit 9546eecd7fc75470284d37f6a62f544724a8eb46)
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 82ec0e812b062503f9aa0b3c617c0001587928bc
https://github.com/WebKit/WebKit/commit/82ec0e812b062503f9aa0b3c617c0001587928bc
Author: Dan Hecht <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
A JSTests/wasm/stress/catch-nested-expr-stack-and-locals.js
A JSTests/wasm/stress/catch-nested-rethrow.js
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick 6f9b4a803bef. rdar://162211758
[JSC] Wasm: Fix OMG exceptions with nested catch
https://bugs.webkit.org/show_bug.cgi?id=300395
rdar://162211758
Reviewed by Yusuke Suzuki.
OMGIRGenerator::emitCatchImpl consumes the scratch buffer produced by
the stack map generated by OMGIRGenerator::preparePatchpointForExceptions
which has the catch exception after the expressions of a Catch block.
However, when Options::useWasmIPInt()==true, connectControlAtEntrypoint()
does not load the exception value.
Added new tests to verify nested catch rethrow exception and
expression slots (and locals) are restored correctly when entering an
inner catch handler, as well verify that this state remains correct
for the OSR loop case.
* JSTests/wasm/stress/catch-nested-expr-stack-and-locals.js: Added.
(async testExpressionStack):
(async testExpressionStackWithOSR):
* JSTests/wasm/stress/catch-nested-rethrow.js: Added.
(async testBasic):
(async testWithOSR):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::connectControlAtEntrypoint):
(JSC::Wasm::OMGIRGenerator::addLoop):
(JSC::Wasm::OMGIRGenerator::emitCatchImpl):
(JSC::Wasm::OMGIRGenerator::emitCatchTableImpl):
Canonical link: https://commits.webkit.org/297297.521@safari-7622-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: ec466b8514722446df4528483edca6ff36980502
https://github.com/WebKit/WebKit/commit/ec466b8514722446df4528483edca6ff36980502
Author: Youenn Fablet <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
Log Message:
-----------
Cherry-pick d27c836e83c4. rdar://162296113
Cherry-pick 3c51043d4a39. rdar://162296113
[iOS 26] Camera capture orientation is not correct on SafariViewService
rdar://160105158
https://bugs.webkit.org/show_bug.cgi?id=300428
Reviewed by Wenson Hsieh.
On iOS 26, UIApplication.sharedApplication.statusBarOrientation seems
to always return the portrait orientation on SVC.
windowScene.effectiveGeometry.interfaceOrientation on the other end
provides the correct value.
We switch the order to use
windowScene.effectiveGeometry.interfaceOrientation if there is a scene and
UIApplication.sharedApplication.statusBarOrientation otherwise.
We also remove one UIKit SPI as part of this change.
Manually tested on Mobile Safari, SVC and WKWebView.
Canonical link: https://commits.webkit.org/301262@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: a8e9bf532a68e08a7726b4af97a2e3898ce5a724
https://github.com/WebKit/WebKit/commit/a8e9bf532a68e08a7726b4af97a2e3898ce5a724
Author: Aditya Keerthi <[email protected]>
Date: 2025-10-10 (Fri, 10 Oct 2025)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick e8ee6462e34e. rdar://162349742
Cherry-pick 418cd9192a51. rdar://162349742
[iOS] Safari crashes underneath `-[UIPreviewTarget
initWithContainer:center:transform:]`
https://bugs.webkit.org/show_bug.cgi?id=300460
rdar://158751554
Reviewed by Abrar Rahman Protyasha, Tim Horton, and Richard Robinson.
Crashes in Safari are being observed due to a UIKit assertion that
checks
whether a targeted preview container is in a window.
It remains unclear exactly how WebKit gets into this state. For now,
speculatively fix by not creating a targeted preview when the container
is
not in a window. This should have no user observable effect, since the
container is a subview of `_interactionViewsContainerView`, which is a
subview
of the `WKWebView`. Consequently, if the container is not in a window,
the
web view must also not be.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _createTargetedContextMenuHintPreviewIfPossible]):
Canonical link: https://commits.webkit.org/301302@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: e0390137cb89386a60b709ba1e62369646533d84
https://github.com/WebKit/WebKit/commit/e0390137cb89386a60b709ba1e62369646533d84
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-10 (Fri, 10 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: 3227351eb3eb72d5a4db837f849754b90cde5fe3
https://github.com/WebKit/WebKit/commit/3227351eb3eb72d5a4db837f849754b90cde5fe3
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-14 (Tue, 14 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: 90fdea8e9838cb09c65d3c79c33df8cb20f9ee5c
https://github.com/WebKit/WebKit/commit/90fdea8e9838cb09c65d3c79c33df8cb20f9ee5c
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: ec54277c4c3cea17af20b579357af6460c31cf50
https://github.com/WebKit/WebKit/commit/ec54277c4c3cea17af20b579357af6460c31cf50
Author: Keith Miller <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M Source/JavaScriptCore/runtime/OptionsList.h
Log Message:
-----------
Cherry-pick 70e68bf51c13. rdar://162482391
[No-merge-back] Turn Off Array Allocation Sinking
https://bugs.webkit.org/show_bug.cgi?id=300718
rdar://162482391
Reviewed by Yusuke Suzuki and Yijia Huang.
There seem to be outstanding issues with Array allocation sinking.
We should disable it for now while we resolve those issues.
Canonical link: https://commits.webkit.org/297297.522@safari-7622-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 30ad855296396bdba9556be5a91db2b60a79e2c9
https://github.com/WebKit/WebKit/commit/30ad855296396bdba9556be5a91db2b60a79e2c9
Author: Ryosuke Niwa <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M Source/WebCore/dom/LiveNodeList.h
M Source/WebCore/dom/LiveNodeListInlines.h
M Source/WebCore/html/CollectionTraversal.h
M Source/WebCore/html/CollectionTraversalInlines.h
M Source/WebCore/html/CollectionType.h
M Source/WebCore/html/LabelsNodeList.h
Log Message:
-----------
Cherry-pick 74aabff89f46. rdar://162644342
Crash in LabelsNodeList::~LabelsNodeList
https://bugs.webkit.org/show_bug.cgi?id=300692
<rdar://162254579>
Reviewed by Chris Dumez.
Fix the crash by using WeakPtr instead of CheckedPtr in LabelsNodeList.
No new tests since we don't have a reproduction.
* Source/WebCore/dom/LiveNodeList.h:
* Source/WebCore/html/CollectionTraversal.h:
* Source/WebCore/html/CollectionTraversalInlines.h:
(WebCore::CollectionTraversal<CollectionTraversalType::WeakPtrDescendants>::begin):
(WebCore::CollectionTraversal<CollectionTraversalType::WeakPtrDescendants>::last):
(WebCore::CollectionTraversal<CollectionTraversalType::WeakPtrDescendants>::traverseForward):
(WebCore::CollectionTraversal<CollectionTraversalType::WeakPtrDescendants>::traverseBackward):
* Source/WebCore/html/CollectionType.h:
Canonical link: https://commits.webkit.org/301516@main
(cherry picked from commit ce7e8f28b6b8fe961ec89320d199ec1bfc3510a1)
Canonical link: https://commits.webkit.org/[email protected]
Commit: f992c932f51fd27dc80c8a8bba240d70555528b6
https://github.com/WebKit/WebKit/commit/f992c932f51fd27dc80c8a8bba240d70555528b6
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-17 (Fri, 17 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: e36c99a5fbcf6aca3f2f4dfd6b828211ef8a7a77
https://github.com/WebKit/WebKit/commit/e36c99a5fbcf6aca3f2f4dfd6b828211ef8a7a77
Author: Jean-Yves Avenard <[email protected]>
Date: 2025-10-17 (Fri, 17 Oct 2025)
Changed paths:
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick c026408da578. rdar://162888917
[iOS] implement watchdog for completing fullscreen exit.
https://bugs.webkit.org/show_bug.cgi?id=300380
rdar://162112548
Reviewed by Jer Noble.
Following 290536@main ; exiting fullscreen relies on the web process to
complete its task and to call
WebFullScreenManagerProxy::beganEnterFullScreen
If the web process has hung or died, the fullscreen window remains on
screen with non-functional controls,
giving the appearance that Safari is completely locked up.
Like we do on Mac, we set a 1s watchdog that should the we failed to
complete the exit of fullscreen mode
we will dismiss the webview placeholder.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController exitFullScreen:]):
(-[WKFullScreenWindowController _completedExitFullScreen:]):
(-[WKFullScreenWindowController _startWatchdogTimer]):
(-[WKFullScreenWindowController _watchdogTimerFired:]):
(-[WKFullScreenWindowController _cancelWatchdogTimer]):
(-[WKFullScreenWindowController _exitFullscreenImmediately]):
Canonical link: https://commits.webkit.org/301296@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0196511e6bf9f60641331afbbe5a5f5d71b635a5
https://github.com/WebKit/WebKit/commit/0196511e6bf9f60641331afbbe5a5f5d71b635a5
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-20 (Mon, 20 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: 452bfd5207af50526edf2d1143f3e2020f3bf619
https://github.com/WebKit/WebKit/commit/452bfd5207af50526edf2d1143f3e2020f3bf619
Author: Commit Queue <[email protected]>
Date: 2025-10-20 (Mon, 20 Oct 2025)
Changed paths:
R
LayoutTests/fast/scrolling/ios/sticky-during-rubberband-offscreen-expected.txt
R LayoutTests/fast/scrolling/ios/sticky-during-rubberband-offscreen.html
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 08150b2ace9f. rdar://163075437
Unreviewed, reverting 300544@main.
https://bugs.webkit.org/show_bug.cgi?id=301145
Caused excessive memory usage for offscreen position:sticky elements
Reverted changeset:
"Sticky elements at the edge of the viewport can disappear when rubber band
scrolling."
https://bugs.webkit.org/show_bug.cgi?id=298709
https://commits.webkit.org/300544@main
Canonical link: https://commits.webkit.org/301832@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: b8a67f51500ca849ae3bd1ee0eaed62bfe581317
https://github.com/WebKit/WebKit/commit/b8a67f51500ca849ae3bd1ee0eaed62bfe581317
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: 17ee215c50bc3f467b42d353c9cec368f493c785
https://github.com/WebKit/WebKit/commit/17ee215c50bc3f467b42d353c9cec368f493c785
Author: Alan Baradlay <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
A LayoutTests/fast/box-shadow/inset-shadow-large-spread2-expected.html
A LayoutTests/fast/box-shadow/inset-shadow-large-spread2.html
M Source/WebCore/rendering/BackgroundPainter.cpp
Log Message:
-----------
Cherry-pick 8b5fe77dc02b. rdar://163134443
REGRESSION (299603@main): Inset box-shadow not rendered when spread is
larger than element
https://bugs.webkit.org/show_bug.cgi?id=300477
<rdar://problem/162373297>
Reviewed by Simon Fraser.
When the inset shadow fully covers the box (i.e., the inner hole rect
becomes zero),
we should paint the outer shape (the full rect) rather than the zero rect.
(Note that the inner rect is never the (inset) shadow itself).
Test: fast/box-shadow/inset-shadow-large-spread2.html
* LayoutTests/fast/box-shadow/inset-shadow-large-spread2-expected.html:
Added.
* LayoutTests/fast/box-shadow/inset-shadow-large-spread2.html: Added.
* Source/WebCore/rendering/BackgroundPainter.cpp:
(WebCore::BackgroundPainter::paintBoxShadow const):
Canonical link: https://commits.webkit.org/301741@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 1c127b1c2431fd741b2b2b3e9f4dbf42be8b771b
https://github.com/WebKit/WebKit/commit/1c127b1c2431fd741b2b2b3e9f4dbf42be8b771b
Author: Mohsin Qureshi <[email protected]>
Date: 2025-10-23 (Thu, 23 Oct 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7
Canonical link: https://commits.webkit.org/[email protected]
Commit: 8914df4ab564e7a9d033eb3666ada075d8878eee
https://github.com/WebKit/WebKit/commit/8914df4ab564e7a9d033eb3666ada075d8878eee
Author: Matthew Finkel <[email protected]>
Date: 2025-10-23 (Thu, 23 Oct 2025)
Changed paths:
R
LayoutTests/http/tests/cookies/block-cookies-when-loading-document-in-sandboxed-iframe.https-expected.txt
R
LayoutTests/http/tests/cookies/block-cookies-when-loading-document-in-sandboxed-iframe.https.html
M LayoutTests/http/tests/cookies/resources/cookie-utilities.js
R
LayoutTests/http/tests/websocket/tests/hybi/resources/set-cookie-with-websocket-and-echo.https.html
R
LayoutTests/http/tests/websocket/tests/hybi/websocket-in-sandboxed-iframe.https-expected.txt
R
LayoutTests/http/tests/websocket/tests/hybi/websocket-in-sandboxed-iframe.https.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/loader/DocumentLoader.cpp
Log Message:
-----------
Cherry-pick f31ea22e0275. rdar://163218886
Cherry-pick 740fdbc5ab49. rdar://163218886
REGRESSION (CheerB/LuckB): iCloud webmail attachments fail to download
(cookies not forwarding to iframe request)
rdar://163218886
Blocking all cookies in the initial request from a sandboxed iframe is
too
restrictive. This causes website breakage in some limited cases where
the
server expects that SameSite={Lax,None} cookies are included, such as
on iCloud
web mail.
Reverted change:
Sandboxed iframe without same-origin flag should not have access to
its site's cookies
https://bugs.webkit.org/show_bug.cgi?id=286769
rdar://143051787
499@safari-7622-branch (25ef58bd202a)
(cherry picked from commit 740fdbc5ab49a8d00e582fa79aadf88327e93f7c)
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/5534839094e0%5E...8914df4ab564
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
