[webkit-changes] [WebKit/WebKit] 809cef: Versioning.
MyahCobbs
noreply at github.com
Tue May 14 14:28:32 PDT 2024
Branch: refs/heads/safari-7619.0.1-branch
Home: https://github.com/WebKit/WebKit
Commit: 809cefc4f62ff3a1f08a8a0619bd99cd308f4d95
https://github.com/WebKit/WebKit/commit/809cefc4f62ff3a1f08a8a0619bd99cd308f4d95
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-619.0.1
Canonical link: https://commits.webkit.org/271831.78@safari-7619.0.1-branch
Commit: 0abaf262ea36155da15c36d5d9f9887ec69df94a
https://github.com/WebKit/WebKit/commit/0abaf262ea36155da15c36d5d9f9887ec69df94a
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
A LayoutTests/compositing/repaint/copy-forward-clear-rect-expected.html
A LayoutTests/compositing/repaint/copy-forward-clear-rect.html
M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp
Log Message:
-----------
Cherry-pick 126e5bd39128. rdar://120666136
Cherry-pick 272394 at main (5ce41d80d507). rdar://120666136
Wikipedia video control icon backgrounds flicker.
https://bugs.webkit.org/show_bug.cgi?id=266726
<rdar://119868478>
Reviewed by Simon Fraser.
The previous code always required a full repaint of the layer whenever a buffer was allocated,
so the copy-forward code didn't run on the second paint of a layer. This meant the copy-forward
code, and the 'buffer is already clear' optimization were mutually exclusive.
The new code uses copy-forward and partial repaints whenever possible, even if the front buffer
was newly allocated (or existing, but purged).
The copy-forward code tries to only copy pixels that won't be re-drawn this frame, but is rounded
out to a single rectangle, not a complex region.
If the copy-forwards ends up copying pixels that we'll also drawn this frame, we can no longer
consider the buffer to be 'clear' and have to manually clear the paint region.
* LayoutTests/compositing/repaint/copy-forward-clear-rect-expected.html: Added.
* LayoutTests/compositing/repaint/copy-forward-clear-rect.html: Added.
* Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp:
(WebKit::RemoteImageBufferSet::prepareBufferForDisplay):
Canonical link: https://commits.webkit.org/272394@main
Canonical link: https://commits.webkit.org/271831.79@safari-7619.0.1-branch
Commit: a45d162a0c38b002526c361fe504fe55dd325cca
https://github.com/WebKit/WebKit/commit/a45d162a0c38b002526c361fe504fe55dd325cca
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
R Source/WebKit/UIProcess/API/ios/WKSEDefinitions.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
A Source/WebKit/UIProcess/ios/WKSEDefinitions.h
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKContentViewEditingActions.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm
M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
M Tools/TestWebKitAPI/Tests/ios/EnterKeyHintTests.mm
M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
M Tools/TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm
M Tools/TestWebKitAPI/Tests/ios/TextServicesTests.mm
M Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm
M Tools/TestWebKitAPI/cocoa/TestWKWebView.h
M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm
M Tools/WebKitTestRunner/Configurations/Base.xcconfig
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Cherry-pick 043e71bfb015. rdar://120812716
[iOS] Prepare API tests for async text input enablement
https://bugs.webkit.org/show_bug.cgi?id=266578
rdar://119816733
Reviewed by Aditya Keerthi.
Prepare our API tests for async text input enablement on iOS, many of which currently call into
legacy SPI methods that crash with the feature flag enabled. To avoid these release assertions, we
refactor all tests which explicitly call into these codepaths, such that they'll invoke their
`UIAsyncTextInput` counterparts when `UIKit/async_text_input` is enabled.
See below for more details.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView moveInDirection:byGranularity:]):
(-[WKContentView extendInDirection:byGranularity:]):
Also drive-by fix an actual bug that was caught by `SelectionTests.ModifyByParagraphBoundary`.
Instead of just moving backward or forward by paragraph granularity in the `UIAsyncTextInput` method
`-extendInDirection:byGranularity:`, we need to additionally move backwards or forwards by character
before doing so in order to maintain parity with `-_moveToEndOfParagraph:withHistory:` and
`_moveToStartOfParagraph:withHistory:`.
* Source/WebKit/UIProcess/ios/WKSEDefinitions.h: Renamed from Source/WebKit/UIProcess/API/ios/WKSEDefinitions.h.
Also move `WKSEDefinitions.h` to `UIProcess/ios` instead of `UIProcess/API/ios`, since the latter
just holds iOS-specific files related to WebKit API objects (in this case, only `WKWebView`).
Putting this in `UIProcess/ios` seems more appropriate, and also allows us to include it directly in
WebKitTestRunner.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Tools/TestRunnerShared/spi/UIKitSPIForTesting.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:
(-[TestWKWebView synchronouslyAdjustSelectionWithDelta:]): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm:
(TestWebKitAPI::simulateEditContextMenuAppearance):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKContentViewEditingActions.mm:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm:
(TestWebKitAPI::simulateEditContextMenuAppearance):
* Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
(-[TestWKWebView autocorrectionRectsForString:]): Deleted.
(-[TestWKWebView synchronouslyRequestAutocorrectionContext]): Deleted.
* Tools/TestWebKitAPI/Tests/ios/EnterKeyHintTests.mm:
(-[TestWKWebView test:enterKeyHint:returnKeyType:]):
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
* Tools/TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm:
* Tools/TestWebKitAPI/Tests/ios/TextServicesTests.mm:
* Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm:
* Tools/TestWebKitAPI/cocoa/TestWKWebView.h:
* Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:
Add a bunch of new category helpers on `WKWebView`, which replace many of the direct calls into
`WKContentView` in our API tests when exercising various `UIWKInteractionViewProtocol` SPIs. These
helper methods will call directly into these legacy SPIs when async text input is disabled, but will
call into their new `UIAsyncTextInput` counterparts when async text input is enabled.
(-[WKWebView defineSelection]):
(-[WKWebView shareSelection]):
(-[WKWebView hasAsyncTextInput]):
(-[WKWebView selectionClipRect]):
(-[WKWebView moveSelectionToStartOfParagraph]):
(-[WKWebView extendSelectionToStartOfParagraph]):
(-[WKWebView moveSelectionToEndOfParagraph]):
(-[WKWebView extendSelectionToEndOfParagraph]):
(-[WKWebView asyncTextInput]):
(-[WKWebView extendedTextInputTraits]):
(-[WKWebView autocorrectionRectsForString:]):
(-[WKWebView autocorrectionContext]):
(-[WKWebView effectiveTextInputTraits]):
(-[WKWebView replaceText:withText:shouldUnderline:completion:]):
(wrap):
(unwrap):
(-[WKWebView synchronouslyAdjustSelectionWithDelta:]):
(-[WKWebView selectTextForContextMenuWithLocationInView:completion:]):
(-[WKWebView handleKeyEvent:completion:]):
* Tools/WebKitTestRunner/Configurations/Base.xcconfig:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::asyncTextInput const):
Canonical link: https://commits.webkit.org/272233@main
Canonical link: https://commits.webkit.org/271831.80@safari-7619.0.1-branch
Commit: e681ed9048cbff59186dca126cd2d7600752352f
https://github.com/WebKit/WebKit/commit/e681ed9048cbff59186dca126cd2d7600752352f
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm
Log Message:
-----------
Cherry-pick 1f6aecd2d650. rdar://120666173
[UIAsyncTextInput] Fix several failing iOS API tests when async text input is enabled
https://bugs.webkit.org/show_bug.cgi?id=267064
rdar://120438466
Reviewed by Megan Gardner.
Fix 4 failing API tests, when async text input is enabled:
• DragAndDropTests.ContentEditableToContentEditable
• DragAndDropTests.ContentEditableToTextarea
These two tests are failing because they expect WebKit to write RTF and/or FlatRTFD upon starting a
drag. This is no longer the case when this feature is enabled, since the system now takes care of
lazily coercing web archive and HTML data to RTF/FlatRTFD/`NSAttributedString` as needed.
As such, we simply adjust this test to pass as long as HTML data is placed at a higher type fidelity
than plain text.
• KeyboardInputTests.IsSingleLineDocument
This actually caught a real bug, where we're failing to actually set the `singleLineDocument`
property on the extended traits delegate (`WKSEExtendedTextInputTraits`), since the call site is
guarded by a `-respondsToSelector:` check for `-setIsSingleLineDocument:` (the legacy name on
private text input traits) instead of `-setSingleLineDocument:` (the new property name on the
extended traits).
Fix the test by fixing `-_updateTextInputTraits:`.
• KeyboardInputTests.EditableWebViewRequiresKeyboardWhenFirstResponder
This test failure is due to the fact that, for a fully-editable web view (i.e. if the embedder sets
`-[WKWebView _editable]` to `YES`), `-_requiresKeyboardWhenFirstResponder` now returns `YES` instead
of `NO` when focusing a `readonly` text field.
Address this and restore shipping behavior by only reverting to the superclass implementation in the
case where the web view is not fully editable.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _requiresKeyboardWhenFirstResponder]):
(-[WKContentView _updateTextInputTraits:]):
* Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm:
(checkRichTextTypePrecedesPlainTextType):
Canonical link: https://commits.webkit.org/272638@main
Canonical link: https://commits.webkit.org/271831.81@safari-7619.0.1-branch
Commit: 87806d1f74bad966e7653513a6879b7d46390704
https://github.com/WebKit/WebKit/commit/87806d1f74bad966e7653513a6879b7d46390704
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/fast/scrolling/mac/keyboard-rubberband-expected.txt
A LayoutTests/fast/scrolling/mac/keyboard-rubberband.html
M LayoutTests/imported/w3c/web-platform-tests/css/css-scroll-anchoring/start-edge-in-block-layout-direction-expected.txt
M Source/WebCore/page/scrolling/ScrollAnchoringController.cpp
M Source/WebCore/platform/ScrollAnimator.cpp
Log Message:
-----------
Cherry-pick 50c9dcae7344. rdar://120662157
[scroll-anchoring] Keyboard scrolling into a rubberband leaves the page stuck at a bad scroll offset
https://bugs.webkit.org/show_bug.cgi?id=267061
rdar://120053910
Reviewed by Simon Fraser.
After https://commits.webkit.org/271957@main we disabled scroll anchoring adjustments while
m_owningScrollableArea.isRubberBandInProgress() is true. However, this is not true during a
keyboard scroll. A better solution to this is to invalidate the scroll anchoring element in
ScrollAnimator::setCurrentPosition itself. Normally scroll position changes here would be sent
down into the scrollable area via setScrollPositionFromAnimation, however while rubberbanding
notify is NotifyScrollableArea::No, so we don't propagate the scroll position change to the
scrollable area. Now that we properly notfiy the scroll anchoring controller of the scroll
position change while rubberbanding, we can remove the old solution.
* Source/WebCore/page/scrolling/ScrollAnchoringController.cpp:
(WebCore::ScrollAnchoringController::adjustScrollPositionForAnchoring):
* Source/WebCore/platform/ScrollAnimator.cpp:
(WebCore::notifyScrollAnchoringControllerOfScroll):
(WebCore::ScrollAnimator::setCurrentPosition):
Canonical link: https://commits.webkit.org/272657@main
Canonical link: https://commits.webkit.org/271831.82@safari-7619.0.1-branch
Commit: c21d507f6a8708ced2c60745d3489ec2e082a631
https://github.com/WebKit/WebKit/commit/c21d507f6a8708ced2c60745d3489ec2e082a631
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-01-10 (Wed, 10 Jan 2024)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp
Log Message:
-----------
Apply patch. rdar://120666136
Canonical link: https://commits.webkit.org/271831.83@safari-7619.0.1-branch
Commit: 078f3944a161d3afaf9a188743cd1cc9fb965169
https://github.com/WebKit/WebKit/commit/078f3944a161d3afaf9a188743cd1cc9fb965169
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2024-01-12 (Fri, 12 Jan 2024)
Changed paths:
M Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm
Log Message:
-----------
Cherry-pick 56991ea107a7. rdar://120431014
Check framework availability for all soft linked frameworks in Core IPC code
https://bugs.webkit.org/show_bug.cgi?id=267052
rdar://120004741
Reviewed by Andy Estes.
If we softlink a framework, it stands to reason that it might be unavailable at runtime.
So before looking up a `Class` that exists in such a framework, make sure the framework is available.
* Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm:
(IPC::typeFromObject):
Canonical link: https://commits.webkit.org/272618@main
Identifier: 270272.1643 at safari-7619.0.1-branch
Commit: 7d1ede9ccf3c675ca660d6fb0342240c4e760a7e
https://github.com/WebKit/WebKit/commit/7d1ede9ccf3c675ca660d6fb0342240c4e760a7e
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2024-01-12 (Fri, 12 Jan 2024)
Changed paths:
M LayoutTests/fast/scrolling/ios/scroll-anchoring-momentum-scroll.html
A LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element-expected.txt
A LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element.html
M LayoutTests/resources/ui-helper.js
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h
M Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/TestControllerIOS.mm
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Cherry-pick 184aa40be65f. rdar://120887424
[iOS] [scroll-anchoring] Software keyboard overlaps input field on webauthn.io
https://bugs.webkit.org/show_bug.cgi?id=267440
rdar://120753568
Reviewed by Simon Fraser.
It's possible for scroll anchoring to cause the scroll position to jump to the previously anchored
element, when scrolling to reveal the focused element on top of the software keyboard on iOS. This
scrolling (driven by `-_zoomToCenter:atScale:animated:` in the UI process) is bookended in Safari by
calls to `-_(begin|end)InteractiveObscuredInsetsChange` while the keyboard is showing, which puts us
in unstable state and also passes `ViewportRectStability::ChangingObscuredInsetsInteractively` into
`AsyncScrollingCoordinator::reconcileScrollingState`. This, in turn, means we'll skip setting the
layout viewport override rect when syncing the scroll position.
This isn't normally an issue, because we'll eventually update the layout viewport once we end
interactive obscured inset changes. However, in the context of scroll anchoring, the fact that the
scroll position is updated but the layout viewport rect isn't (when reconciling scrolling state)
means that it's possible for the scroll anchoring controller to adjust the layout viewport rect in
the following codepath during layout:
```
void LocalFrameView::updateLayoutViewport()
{
…
if (m_layoutViewportOverrideRect) {
if (currentScrollType() == ScrollType::Programmatic) {
LOG_WITH_STREAM(Scrolling, stream << "computing new override layout viewport because of programmatic scrolling");
LayoutPoint newOrigin = computeLayoutViewportOrigin(visualViewportRect(), minStableLayoutViewportOrigin(), maxStableLayoutViewportOrigin(), layoutViewport, StickToDocumentBounds);
setLayoutViewportOverrideRect(LayoutRect(newOrigin, m_layoutViewportOverrideRect.value().size()));
}
layoutOrVisualViewportChanged();
return;
}
```
..._without_ having properly invalidated and updated the current scroll anchor. In turn, this makes
it possible for us to compare the layout viewport after accounting for the keyboard scrolling amount
against a stale `m_lastOffsetForAnchorElement`, causing the adjustment to overcompensate and jump
back up to the top of the page in the middle of the keyboard scrolling animation.
To fix this, we simply invalidate the anchor element on `ScrollAnchoringController` (along with the
stale `m_lastOffsetForAnchorElement`) when the layout viewport changes.
* LayoutTests/fast/scrolling/ios/scroll-anchoring-momentum-scroll.html:
Drive-by fix: indentation.
* LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element-expected.txt: Added.
* LayoutTests/fast/scrolling/ios/scroll-anchoring-when-revealing-focused-element.html: Added.
Add a new layout test that fails without this fix. While it doesn't precisely simulate the bug as it
appears on webauthn.io, it exercises the same root cause by repeatedly triggering scroll anchoring
adjustment while scrolling to reveal the focused element with the software keyboard, all in the
scope of interactive obscured inset changes.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.beginInteractiveObscuredInsetsChange):
(window.UIHelper.endInteractiveObscuredInsetsChange):
(window.UIHelper.setObscuredInsets):
Add new `UIHelper` methods to allow layout tests to adjust the obscured insets in the same way that
Safari does when showing the software keyboard.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::setLayoutViewportOverrideRect):
See comments above for more detail.
* Source/WebKit/UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm:
(-[WKWebView _resetObscuredInsetsForTesting]):
Add a testing hook to reset the web view's obscured insets; used when resetting state in between
layout tests.
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::beginInteractiveObscuredInsetsChange):
(WTR::UIScriptController::endInteractiveObscuredInsetsChange):
(WTR::UIScriptController::setObscuredInsets):
Add boilerplate code to implement the new script controller helper methods.
* Tools/WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::beginInteractiveObscuredInsetsChange):
(WTR::UIScriptControllerIOS::setObscuredInsets):
(WTR::UIScriptControllerIOS::endInteractiveObscuredInsetsChange):
Canonical link: https://commits.webkit.org/272957@main
Identifier: 270272.1644 at safari-7619.0.1-branch
Commit: 20e2ad59fce4ffc7dbd499e4d78462b5224e61ef
https://github.com/WebKit/WebKit/commit/20e2ad59fce4ffc7dbd499e4d78462b5224e61ef
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2024-01-18 (Thu, 18 Jan 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7619.0.1.1
Identifier: 271831.86 at safari-7619.0.1-branch
Commit: fa54c9c9ab747fc1b47ff6a285754fea39f4739a
https://github.com/WebKit/WebKit/commit/fa54c9c9ab747fc1b47ff6a285754fea39f4739a
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2024-01-22 (Mon, 22 Jan 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7619.0.1.2
Identifier: 271831.87 at safari-7619.0.1-branch
Compare: https://github.com/WebKit/WebKit/compare/809cefc4f62f%5E...fa54c9c9ab74
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list