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_bugzi...@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_bugzi...@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@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_bugzi...@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_bugzi...@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_bugzi...@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_bugzi...@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 <mco...@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@safari-7619.0.1-branch Commit: 7d1ede9ccf3c675ca660d6fb0342240c4e760a7e https://github.com/WebKit/WebKit/commit/7d1ede9ccf3c675ca660d6fb0342240c4e760a7e Author: Myah Cobbs <mco...@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@safari-7619.0.1-branch Commit: 20e2ad59fce4ffc7dbd499e4d78462b5224e61ef https://github.com/WebKit/WebKit/commit/20e2ad59fce4ffc7dbd499e4d78462b5224e61ef Author: Myah Cobbs <mco...@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@safari-7619.0.1-branch Commit: fa54c9c9ab747fc1b47ff6a285754fea39f4739a https://github.com/WebKit/WebKit/commit/fa54c9c9ab747fc1b47ff6a285754fea39f4739a Author: Myah Cobbs <mco...@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@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 _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes