[webkit-changes] [295756] trunk/Source
Title: [295756] trunk/Source Revision 295756 Author wenson_hs...@apple.com Date 2022-06-22 17:04:40 -0700 (Wed, 22 Jun 2022) Log Message Implement painting for MSE videos using -[AVSampleBufferDisplayLayer copyDisplayedPixelBuffer] https://bugs.webkit.org/show_bug.cgi?id=241788 rdar://94325004 Reviewed by Eric Carlson. In r292811, we enabled MSE inline painting on iOS 16 and macOS Ventura; this was intentionally limited to these versions, since CoreMedia made refinements in these OS versions to prune the `AVSampleBufferVideoOutput` queue more frequently, in order to avoid a large increase in memory use while playing MSE videos, due to accumulating excess video output frame data. However, this more frequent pruning interval has led to significantly increased power use when playing MSE video, due to the extra work done every time the pruning timer fires. To ensure that Live Text in MSE video and MSE to canvas painting still work in iOS 16 and macOS Ventura, we instead adopt new AVFoundation SPI that allows us to ask `AVSampleBufferDisplayLayer` directly for the currently displayed pixel buffer. As opposed to the `AVSampleBufferVideoOutput`- based approach, this will only kick in if MSE video inline painting is actually requested (either by the page, or from within the engine, in the case of Live Text), which avoids both increased memory use and power use. On versions of macOS and iOS that don't have the new SPI, we simply fall back to the `AVSampleBufferVideoOutput`-based snapshotting approach that we currently use. We also fall back to using the video output if the display layer is empty, in which case the backing `CAImageQueue` won't contain _any_ displayed surfaces (which means `-copyDisplayedPixelBuffer` will always end up returning null). By refactoring logic to create and set `m_videoOutput` out into a helper method (`updateVideoOutput`) that's invoked after we've finished setting up the sample buffer display layer, we can transition as needed between setting and unsetting the video output, based on whether or not the display layer is actually displaying any content. There should be no change in behavior, apart from less memory and power use due to not spinning up the `AVSampleBufferVideoOutput` queue whenever we play MSE videos. See below for more details. * Source/WTF/Scripts/Preferences/WebPreferencesExperimental.yaml: Gate MSE inline painting on `HAVE(AVSAMPLEBUFFERDISPLAYLAYER_COPYDISPLAYEDPIXELBUFFER)`, instead of `HAVE(LOW_AV_SAMPLE_BUFFER_PRUNING_INTERVAL)`. * Source/WTF/wtf/PlatformHave.h: Add a new feature flag to guard the availability of the new AVFoundation SPI, `-[AVSampleBufferDisplayLayer copyDisplayedPixelBuffer]`. * Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h: Add a staging declaration for `-copyDisplayedPixelBuffer`, so that we can maintain source compatibility when building against older versions of the iOS 16 or macOS Ventura SDKs. * Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp: (WebCore::WebGLRenderingContextBase::texImageSourceHelper): * Source/WebCore/platform/graphics/MediaPlayer.cpp: * Source/WebCore/platform/graphics/MediaPlayer.h: * Source/WebCore/platform/graphics/MediaPlayerPrivate.h: Replace more uses of `HAVE(LOW_AV_SAMPLE_BUFFER_PRUNING_INTERVAL)` with the new flag `HAVE(AVSAMPLEBUFFERDISPLAYLAYER_COPYDISPLAYEDPIXELBUFFER)`, which is now used to guard availability of MSE inline painting. The purpose of guarding this logic behind `!HAVE(LOW_AV_SAMPLE_BUFFER_PRUNING_INTERVAL)` in the first place seems to have been to limit the `willBeAskedToPaintGL()` codepaths to versions of macOS and iOS, where we can't enable MSE inline painting due to lack of system support. Since "system support" now depends on the availability of `-copyDisplayedPixelBuffer`, we should change to use that flag instead of one about pruning interval frequency. This also allows us to remove the `HAVE(LOW_AV_SAMPLE_BUFFER_PRUNING_INTERVAL)` flag altogether, now that there isn't any code that needs to be guarded by it. * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h: * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::updateLastPixelBuffer): Adjust this logic to ask `m_sampleBufferDisplayLayer` for a copy of the last displayed pixel buffer, instead of grabbing it from the video output, if possible. (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::shouldEnsureLayer const): (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::acceleratedRenderingStateChanged): (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::updateVideoOutput): Factor out logic for creating or destroying the video output into a separate helper method, that's invoked after updating the display layer. (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::readbackMethod const): Replace `isVideoOutputAvailable()` with
[webkit-changes] [295751] trunk
Title: [295751] trunk
Revision 295751
Author wenson_hs...@apple.com
Date 2022-06-22 15:42:57 -0700 (Wed, 22 Jun 2022)
Log Message
REGRESSION (iOS 16): System controls overlap website controls (affects SquareSpace, medium.com, and others)
https://bugs.webkit.org/show_bug.cgi?id=241837
rdar://95658478
Reviewed by Aditya Keerthi.
On iOS 16, the callout bar (which is now built on top of `UIEditMenuInteraction`) no longer respects
evasion rects, passed in through the `UIWKInteractionViewProtocol` delegate method
`-requestRectsToEvadeForSelectionCommandsWithCompletionHandler:`. This was previously used to avoid
overlapping interactable controls on the page when presenting the callout bar, which the layout
test `editing/selection/ios/avoid-showing-callout-menu-over-controls.html` exercises.
To fix this, we're adding a replacement SPI in UIKit, allowing WebKit to vend a preferred
`UIEditMenuArrowDirection` which will be consulted when presenting the edit menu interaction in
order to show the callout bar.
For more details, see: rdar://95652872.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView requestPreferredArrowDirectionForEditMenuWithCompletionHandler:]):
In the case where there are clickable controls above the selection, use `UIEditMenuArrowDirectionUp`
to make the callout bar present _below_ the selection instead of above; otherwise, simply go with
the default behavior, which puts the callout bar above the selection.
(-[WKContentView requestRectsToEvadeForSelectionCommandsWithCompletionHandler:]):
Pull out common logic for requesting a list of rects to evade into a separate internal helper
method, and use this common helper method to implement both the legacy delegate method (which no
longer works on iOS 16), as well as the new delegate method in iOS 16. For now, I opted to still
implement both methods, such that this test will pass on both iOS 15 and iOS 16 (but only with the
changes in rdar://95652872).
(-[WKContentView _requestEvasionRectsAboveSelectionIfNeeded:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm:
Also, adopt the new SPI in an API test that simulates callout bar appearance on iOS 16.
(TestWebKitAPI::simulateCalloutBarAppearance):
* Tools/TestWebKitAPI/cocoa/TestWKWebView.h:
* Tools/TestWebKitAPI/ios/UIKitSPI.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::internalClassNamed):
(WTR::UIScriptControllerIOS::menuRect const):
(WTR::UIScriptControllerIOS::contextMenuRect const):
Additionally tweak a couple of script controller hooks, to work with the new `UIEditMenuInteraction`
-based callout bars on iOS 16.
Canonical link: https://commits.webkit.org/251756@main
Modified Paths
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.h
trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h
trunk/Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Diff
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (295750 => 295751)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-22 22:07:32 UTC (rev 295750)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-22 22:42:57 UTC (rev 295751)
@@ -4624,53 +4624,64 @@
});
}
-- (void)requestRectsToEvadeForSelectionCommandsWithCompletionHandler:(void(^)(NSArray *rects))completionHandler
+#if HAVE(UI_EDIT_MENU_INTERACTION)
+
+- (void)requestPreferredArrowDirectionForEditMenuWithCompletionHandler:(void(^)(UIEditMenuArrowDirection))completion
{
-if (!completionHandler) {
-[NSException raise:NSInvalidArgumentException format:@"Expected a nonnull completion handler in %s.", __PRETTY_FUNCTION__];
-return;
-}
+[self _requestEvasionRectsAboveSelectionIfNeeded:[completion = makeBlockPtr(completion)](const Vector& rects) {
+completion(rects.isEmpty() ? UIEditMenuArrowDirectionAutomatic : UIEditMenuArrowDirectionUp);
+}];
+}
+#endif
+
+- (void)requestRectsToEvadeForSelectionCommandsWithCompletionHandler:(void(^)(NSArray *rects))completion
+{
+[self _requestEvasionRectsAboveSelectionIfNeeded:[completion = makeBlockPtr(completion)](const Vector& rects) {
+completion(createNSArray(rects).get());
+}];
+}
+
+- (void)_requestEvasionRectsAboveSelectionIfNeeded:(CompletionHandler&)>&&)completion
+{
if ([self _shouldSuppressSelectionCommands]) {
-completionHandler(@[ ]);
+completion({ });
return;
}
-auto requestRectsToEvadeIfNeeded = [startTime = ApproximateTime::now(), weakSelf = WeakObjCPtr(self), completion = makeBlockPtr(completionHandler)] {
+auto requestRectsToEvadeIfNeeded = [startTime = ApproximateTime::now(), weakSelf = WeakObjCPtr(self), completion = WTFMove(completion)]() mutable {
auto strongSelf = weakSelf.get();
if (!strongSelf) {
-completion(@[ ]);
+completion({ });
[webkit-changes] [295732] trunk
Title: [295732] trunk Revision 295732 Author wenson_hs...@apple.com Date 2022-06-22 09:07:32 -0700 (Wed, 22 Jun 2022) Log Message [ iOS ] editing/selection/ios/show-callout-bar-after-selecting-word.html is a flaky timeout https://bugs.webkit.org/show_bug.cgi?id=240544 rdar://93458507 Reviewed by Aditya Keerthi. Currently, any LayoutTest that attempts to wait for (or interact with) the callout bar after selecting text fails, due to the fact that on iOS 16, the callout bar is implemented using a `UIEditMenuInteraction` on the content view, which doesn't use the extant classes for managing and observing callout bar UI -- i.e. `UIMenuController`, `UICalloutBar` and the associated global notifications. Unfortunately, when using iOS 16, there are no longer any global notifications that the test harness can listen for to detect when the callout bar has been presented or dismissed. To keep these tests passing on iOS 16, we introduce a mechanism to the test harness to intercept edit menu interaction delegate method calls, and notify `TestController` when the edit menu has completed its presention or dismissal animations. Also, tweak a flaky layout test that exercises this logic to be more robust — see below for more detail. * LayoutTests/editing/selection/ios/show-callout-bar-after-selecting-word.html: Additionally, adjust this layout test to explicitly wait for the 'Select' menu action before trying to select that item -- this might mitigate potential flakiness on iOS 15, due to calling `UIHelper.chooseMenuAction()` too early. * Source/WTF/wtf/PlatformHave.h: Add a new build-time flag to guard the availability of `UIEditMenuInteraction`. * Tools/WebKitTestRunner/TestController.h: * Tools/WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.h: * Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm: (-[TestRunnerWKWebView textEffectsWindow]): Add a helper method to return the web view's associated text effects window. This is used below in `TestController` when recursively searching the view hierarchy for callout menu buttons with a given label string (e.g. "Select", "Select All", "Copy", etc.), because these buttons and labels now exist within the view hierarchy of the `UITextEffectsWindow` on iOS 16, when using the edit menu interaction. (-[TestRunnerWKWebView currentEditMenuInteraction]): Add a helper method to grab the edit menu interaction corresponding to text selection on the content view. (-[TestRunnerWKWebView didPresentEditMenuInteraction:]): (-[TestRunnerWKWebView didDismissEditMenuInteraction:]): Plumb into the existing `-_didHideMenu` and `-_didShowMenu` methods, which we currently use to observe callout bar presentation and dismissal. This allows the test harness to simultaneously support iOS 15 and iOS 16, for layout tests that exercise the callout bar. (-[TestRunnerWKWebView immediatelyDismissEditMenuInteractionIfNeeded]): Add a hook to immediately dismiss the callout bar between layout tests, that is compatible with UIEditMenuInteraction-backed callout bars. * Tools/WebKitTestRunner/ios/EditMenuInteractionSwizzler.h: Added. * Tools/WebKitTestRunner/ios/EditMenuInteractionSwizzler.mm: Added. Add a helper class to swizzle `-[UIEditMenuInteraction initWithDelegate:]`, and call the original method implementation with an object that wraps the given `UIEditMenuInteractionDelegate` in another object (`EditMenuInteractionDelegateWrapper`) that forwards all selector invocations to the original delegate (in practice: `_UIContextMenuInteractionBasedTextContextInteraction`), but additionally implements the `-willPresentMenuForConfiguration:` and `-willDismissMenuForConfiguration:` delegate hooks and adds animation completion blocks that call out to the global `TestController`. This allows us to passively observe calls to `-editMenuInteraction:(will|did)PresentMenuForConfiguration:animator:`, without affecting the internal UIKit implementation of the text interaction assistant's edit menu interaction. (-[EditMenuInteractionDelegateWrapper initWithDelegate:]): (-[EditMenuInteractionDelegateWrapper forwardInvocation:]): (-[EditMenuInteractionDelegateWrapper respondsToSelector:]): (-[EditMenuInteractionDelegateWrapper methodSignatureForSelector:]): (-[EditMenuInteractionDelegateWrapper editMenuInteraction:willPresentMenuForConfiguration:animator:]): (-[EditMenuInteractionDelegateWrapper editMenuInteraction:willDismissMenuForConfiguration:animator:]): (-[UIEditMenuInteraction swizzled_initWithDelegate:]): (WTR::EditMenuInteractionSwizzler::EditMenuInteractionSwizzler): (WTR::EditMenuInteractionSwizzler::~EditMenuInteractionSwizzler): * Tools/WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformInitialize): Initialize the edit menu interaction swizzler. (WTR::TestController::platformResetStateToConsistentValues): (WTR::TestController::didPresentEditMenuInteraction):
[webkit-changes] [295645] trunk
Title: [295645] trunk
Revision 295645
Author wenson_hs...@apple.com
Date 2022-06-17 15:18:20 -0700 (Fri, 17 Jun 2022)
Log Message
attachment elements with `-webkit-user-drag: none;` should not be draggable
https://bugs.webkit.org/show_bug.cgi?id=241720
rdar://95401577
Reviewed by Tim Horton.
The logic to walk up the ancestor chain in search of draggable elements in `draggableElement()`
currently ignores `-webkit-user-drag` for `attachment` elements, and instead considers the
attachment draggable as long as it's either the only element in the selection range, or the
selection range does not encompass the hit-tested attachment element.
Fix this by only proceeding with the single-attachment-drag codepath (`DragSourceAction::Attachment`)
in the case where the dragged attachment has a `-webkit-user-drag` value that isn't `"none"`.
Test: WKAttachmentTests.UserDragNonePreventsDragOnAttachmentElement
* Source/WebCore/page/DragController.cpp:
(WebCore::DragController::draggableElement const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/251650@main
Modified Paths
trunk/Source/WebCore/page/DragController.cpp
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm
Diff
Modified: trunk/Source/WebCore/page/DragController.cpp (295644 => 295645)
--- trunk/Source/WebCore/page/DragController.cpp 2022-06-17 21:42:20 UTC (rev 295644)
+++ trunk/Source/WebCore/page/DragController.cpp 2022-06-17 22:18:20 UTC (rev 295645)
@@ -787,6 +787,10 @@
if (auto attachment = enclosingAttachmentElement(*startElement)) {
auto& selection = sourceFrame->selection().selection();
bool isSingleAttachmentSelection = selection.start() == Position(attachment.get(), Position::PositionIsBeforeAnchor) && selection.end() == Position(attachment.get(), Position::PositionIsAfterAnchor);
+auto* renderer = attachment->renderer();
+if (!renderer || renderer->style().userDrag() == UserDrag::None)
+return nullptr;
+
auto selectedRange = selection.firstRange();
if (isSingleAttachmentSelection || !selectedRange || !contains(*selectedRange, *attachment)) {
state.type = DragSourceAction::Attachment;
@@ -793,7 +797,7 @@
return attachment.get();
}
}
-#endif
+#endif // ENABLE(ATTACHMENT_ELEMENT)
auto selectionDragElement = state.type.contains(DragSourceAction::Selection) && m_dragSourceAction.contains(DragSourceAction::Selection) ? startElement : nullptr;
if (ImageOverlay::isOverlayText(startElement))
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm (295644 => 295645)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm 2022-06-17 21:42:20 UTC (rev 295644)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm 2022-06-17 22:18:20 UTC (rev 295645)
@@ -40,9 +40,11 @@
#import
#import
#import
+#import
#import
#import
#import
+#import
#import
#import
@@ -1882,6 +1884,28 @@
EXPECT_TRUE([[info data] isEqualToData:testImageData()]);
}
+TEST(WKAttachmentTests, UserDragNonePreventsDragOnAttachmentElement)
+{
+auto configuration = adoptNS([[WKWebViewConfiguration alloc] init]);
+auto styleSheet = adoptNS([[_WKUserStyleSheet alloc] initWithSource:@"attachment { -webkit-user-drag: none; }" forMainFrameOnly:YES]);
+[[configuration userContentController] _addUserStyleSheet:styleSheet.get()];
+[configuration _setAttachmentElementEnabled:YES];
+
+auto simulator = adoptNS([[DragAndDropSimulator alloc] initWithWebViewFrame:NSMakeRect(0, 0, 800, 600) configuration:configuration.get()]);
+auto *webView = [simulator webView];
+[webView synchronouslyLoadHTMLString:attachmentEditingTestMarkup];
+
+auto file = adoptNS([[NSFileWrapper alloc] initWithURL:testPDFFileURL() options:0 error:nil]);
+[webView synchronouslyInsertAttachmentWithFileWrapper:file.get() contentType:nil];
+[simulator runFrom:NSMakePoint(15, 15) to:NSMakePoint(50, 50)];
+
+#if PLATFORM(MAC)
+EXPECT_NULL([simulator draggingInfo]);
+#else
+EXPECT_EQ(0U, [simulator sourceItemProviders].count);
+#endif
+}
+
#pragma mark - Platform-specific tests
#if PLATFORM(MAC)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295628] trunk/Source/WebCore
Title: [295628] trunk/Source/WebCore
Revision 295628
Author wenson_hs...@apple.com
Date 2022-06-16 23:05:39 -0700 (Thu, 16 Jun 2022)
Log Message
[iOS] Callout bar is sometimes obscured when selecting Live Text in a fullscreen video in AVPlayerViewController
https://bugs.webkit.org/show_bug.cgi?id=241700
rdar://95310525
Reviewed by Tim Horton.
Even after the changes in r295052, `UITextEffectsWindow`-hosted text selection views (e.g. grabber
dots and callout bar) are still _sometimes_ obscured behind the fullscreen player view controller
window. This happens because UIKit may actually maintain multiple `UITextEffectsWindow`s at
different window levels (only one of which is used to host text selection UI for Live Text in
fullscreen videos). For instance, if the user focuses the unified field in Safari and selects or
edits text in the unified field, a `UITextEffectsWindow` with a window level of 1.0 will be
instantiated; if this happens prior to triggering Live Text for a fullscreen video, this text
effects window may be reused for Live Text.
In cases where this `.windowLevel = 1.0` text effects window is used, the window used for the player
view controller (which currently has a level of `UITextEffectsBeneathStatusBarWindowLevel - 1`) will
be above the rest of the Live Text selection UI, which causes this bug to occur.
Mitigate this by explicitly grabbing the `UITextEffectsWindow` that corresponds to the player view's
window using `+sharedTextEffectsWindowForWindowScene:`, and setting the player view window's level
to a value that's right below this text effects window.
* Source/WebCore/PAL/pal/ios/UIKitSoftLink.h:
* Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm:
* Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h:
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm:
(VideoFullscreenInterfaceAVKit::doSetup):
Canonical link: https://commits.webkit.org/251633@main
Modified Paths
trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.h
trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm
trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h
trunk/Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm
Diff
Modified: trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.h (295627 => 295628)
--- trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.h 2022-06-17 05:26:58 UTC (rev 295627)
+++ trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.h 2022-06-17 06:05:39 UTC (rev 295628)
@@ -58,6 +58,7 @@
SOFT_LINK_CLASS_FOR_HEADER(PAL, UIPasteboard)
SOFT_LINK_CLASS_FOR_HEADER(PAL, UIScreen)
SOFT_LINK_CLASS_FOR_HEADER(PAL, UITapGestureRecognizer)
+SOFT_LINK_CLASS_FOR_HEADER(PAL, UITextEffectsWindow)
SOFT_LINK_CLASS_FOR_HEADER(PAL, UITraitCollection)
SOFT_LINK_CLASS_FOR_HEADER(PAL, UIView)
SOFT_LINK_CLASS_FOR_HEADER(PAL, UIViewController)
Modified: trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm (295627 => 295628)
--- trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm 2022-06-17 05:26:58 UTC (rev 295627)
+++ trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm 2022-06-17 06:05:39 UTC (rev 295628)
@@ -58,6 +58,7 @@
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UIPasteboard)
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UIScreen)
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UITapGestureRecognizer)
+SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UITextEffectsWindow)
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UITraitCollection)
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UIView)
SOFT_LINK_CLASS_FOR_SOURCE(PAL, UIKit, UIViewController)
Modified: trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h (295627 => 295628)
--- trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h 2022-06-17 05:26:58 UTC (rev 295627)
+++ trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h 2022-06-17 06:05:39 UTC (rev 295628)
@@ -43,6 +43,7 @@
#import
#import
#import
+#import
#import
#import
#import
@@ -173,6 +174,16 @@
+ (CGFloat)alphaThreshold;
@end
+@interface UIApplicationRotationFollowingWindow : UIWindow
+@end
+
+@interface UIAutoRotatingWindow : UIApplicationRotationFollowingWindow
+@end
+
+@interface UITextEffectsWindow : UIAutoRotatingWindow
++ (UITextEffectsWindow *)sharedTextEffectsWindowForWindowScene:(UIWindowScene *)windowScene;
+@end
+
#endif // USE(APPLE_INTERNAL_SDK)
@interface UIColor (IPI)
Modified: trunk/Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm (295627 => 295628)
--- trunk/Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm 2022-06-17 05:26:58 UTC (rev 295627)
+++ trunk/Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm 2022-06-17 06:05:39 UTC (rev 295628)
@@ -1371,10 +1371,14 @@
[[m_viewController view] setFrame:[m_window bounds]];
[m_viewController _setIgnoreAppSupportedOrientations:YES];
[m_window setRootViewController:m_viewController.get()];
-[m_window setWindowLevel:PAL::get_UIKit_UITextEffectsBeneathStatusBarWindowLevel() - 1];
+auto textEffectsWindowLevel = [&] {
+auto *textEffectsWindow = [PAL::getUITextEffectsWindowClass()
[webkit-changes] [295548] trunk/LayoutTests
Title: [295548] trunk/LayoutTests Revision 295548 Author wenson_hs...@apple.com Date 2022-06-14 18:49:53 -0700 (Tue, 14 Jun 2022) Log Message [iOS 15+] editing/selection/ios/hide-selection-in-tiny-contenteditable.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=241611 rdar://82183980 Reviewed by Aditya Keerthi. This test is intended to check whether the text editing caret is visible or hidden on iOS when focusing a 1px by 1px editable container; in particular, we expect to see the caret show up after making the tiny contenteditable area much larger. However, the horizontal offset of the caret is sometimes shifted by a small amount to the left during the final step of the test, likely due to the fact that the web view might still be in an unstable state after the animated zoom in and out. Unfortunately, I haven't been able to reproduce this locally, so I can't confirm that this theory. To try and mitigate this with a speculative fix, we: 1. Update the test so that it just checks whether or not the caret rect is empty during each step. 2. Use `immediateZoomToScale` instead of `zoomToScale`, so that we don't end up in an unstable state after finishing the second part of the test (which zooms in and out). * LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt: * LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html: * LayoutTests/platform/ios-wk2/TestExpectations: Mark the test as passing. Canonical link: https://commits.webkit.org/251553@main Modified Paths trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html trunk/LayoutTests/platform/ios-wk2/TestExpectations Diff Modified: trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt (295547 => 295548) --- trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt 2022-06-15 01:13:06 UTC (rev 295547) +++ trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt 2022-06-15 01:49:53 UTC (rev 295548) @@ -7,11 +7,11 @@ After focus, the caret rect is empty After zooming in, the caret rect is empty After making editor large, the caret rect is empty -After making editor opaque, the caret rect is (left=21, top=100, width=2, height=19) +After making editor opaque, the caret rect is not empty After making editor tiny again, the caret rect is empty After making editor transparent again, the caret rect is empty After making editor large again, the caret rect is empty -After making editor opaque again, the caret rect is (left=50, top=100, width=2, height=19) +After making editor opaque again, the caret rect is not empty PASS successfullyParsed is true TEST COMPLETE Modified: trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html (295547 => 295548) --- trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html 2022-06-15 01:13:06 UTC (rev 295547) +++ trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html 2022-06-15 01:49:53 UTC (rev 295548) @@ -33,17 +33,11 @@
[webkit-changes] [295479] trunk
Title: [295479] trunk
Revision 295479
Author wenson_hs...@apple.com
Date 2022-06-12 19:40:04 -0700 (Sun, 12 Jun 2022)
Log Message
REGRESSION (r290875): [iOS] Safari renders many blank tiles after navigating back to webpage from PDF
https://bugs.webkit.org/show_bug.cgi?id=241536
rdar://94637323
Reviewed by Tim Horton.
When using a standard content view, the logic in `WKApplicationStateTrackingView` creates a
`WebKit::ApplicationStateTracker` after the view becomes parented in the view hierarchy (in
`-didMoveToWindow`), and holds onto it until it is about to be unparented from the view hierarchy
(in `-willMoveToWindow:`).
However, in the case where `WKApplicationStateTrackingView` is a `WKPDFView` (i.e. we're hosting a
remote PDFKit view controller), the behavior is much more intricate; this is because the `WKPDFView`
is replaced in the view hierarchy by the remote view controller's sizing view once the
`PDFHostViewController` has finished loading its remote content. Once this happens, the
`-_contentView` of the `WKApplicationStateTrackingView` points to this sizing view instead, and the
`WKPDFView` (which subclasses `WKApplicationStateTrackingView`) is no longer in the view hierarchy.
Prior to r290875: when we remove `WKPDFView` from the view hierarchy and replace it with a sizing
view, `self._contentView` in both cases already points to the `_UISizeTrackingView`, even though it
hasn't been added to the view hierarchy yet. Since we bail if this size tracking view is not in the
view hierarchy, we previously ended up never clearing out the application state tracker when loading
a PDF, which means that `-[WKPDFView isBackground]` would always return NO, despite the view not
being in the view hierarchy.
In r290875, I replaced the `!self._contentView.window` check with `!_applicationStateTracker`, which
caused us to now clear out the application state tracker when unparenting `WKPDFView`. This, in
turn, means that `-[WKPDFView isBackground]` now returns YES when the `WKPDFView` is removed and
replaced with the size tracking view. When navigating back to the previous page, this causes us to
end up in a state where the `WindowIsActive` flag in `WebPageProxy::m_activityState` is off until
the next page load, since we only update this flag in `WebPageProxy::finishAttachingToWebProcess`,
which is called when `WKPDFView` is still being used as the custom content view. This ultimately
causes the symptoms observed in this bug, which include blank tiles when scrolling.
To address this bug, we first revert the changes in r290875, which allows `WKPDFView` to behave as
if it were in the foreground, even when it's not in the view hierarchy:
```
- (void)willMoveToWindow:(UIWindow *)newWindow
{
if (!self._contentView.window || newWindow)
return;
…
```
Of course, this (by itself) would bring back ; to preserve that fix, we
additionally limit the early return to cases where the window is *not* in the process of being
destroyed (that is, `-willMoveToWindow:` is called with both the new `window == nil`, while the
current window `self.window == nil`):
```
- (void)willMoveToWindow:(UIWindow *)newWindow
{
BOOL windowIsBeingDeallocated = !self.window && !newWindow;
if (!windowIsBeingDeallocated) {
if (!self._contentView.window || newWindow)
return;
}
…
```
Note that this is logically equivalent to:
```
- (void)willMoveToWindow:(UIWindow *)newWindow
{
if ((self.window || newWindow) && (!self._contentView.window || newWindow))
return;
…
```
...which can also be rewritten a bit more succinctly as:
```
- (void)willMoveToWindow:(UIWindow *)newWindow
{
if ((self.window && !self._contentView.window) || newWindow)
return;
…
```
In other words:
- In the case where a standard content view is used (i.e. `self == self._contentView`), we always
clear out `_applicationStateTracker` if the window we're moving to is `nil`. This takes care of the
normal scenario of unparenting a web view, as well as the corner case where the web view is
unparented in the middle of `-[UIWindow dealloc]`.
- In the case of `PDFHostViewController` where a custom content view is used, we'll return early
in `-willMoveToWindow:` and keep the existing `_applicationStateTracker`, because the size tracking
view has not been parented yet.
Test: ApplicationStateTracking.NavigatingFromPDFDoesNotLeaveWebViewInactive
* Source/WebKit/UIProcess/ios/WKApplicationStateTrackingView.mm:
(-[WKApplicationStateTrackingView willMoveToWindow:]):
* Tools/TestWebKitAPI/Configurations/Base.xcconfig:
Add `Source/WebKit/Platform/spi/ios` as a relative header include path for iOS family, such that we
can import the internal `PDFKitSPI.h` in API tests.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/ios/ApplicationStateTracking.mm:
(TestWebKitAPI::TEST):
Introduce a new API test that loads a simple webpage, navigates to a PDF document (and uses
[webkit-changes] [295468] trunk
Title: [295468] trunk
Revision 295468
Author wenson_hs...@apple.com
Date 2022-06-10 16:26:43 -0700 (Fri, 10 Jun 2022)
Log Message
[iOS] Specifying spellcheck="false" on a contentEditable element should suppress platform spellchecking
https://bugs.webkit.org/show_bug.cgi?id=241514
rdar://91123300
Reviewed by Devin Rousso.
Additionally set `-[UITextInputTraits spellCheckingType]` to `UITextSpellCheckingTypeNo` when
focusing editable fields with the DOM attribute `spellcheck="false"`. This provides a hint to UIKit
that system spellchecking should be disabled when editing this field - among other things, this
allows us to avoid showing text candidates in the case where `autocorrect="off"` is additionally
specified.
If either `spellcheck="true"` is set or `spellcheck` is not specified, we fall back to the user's
preference by using `UITextSpellCheckingTypeDefault`.
Test: KeyboardInputTests.DisableSpellChecking
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateTextInputTraits:]):
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/251473@main
Modified Paths
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
Diff
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (295467 => 295468)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-10 23:10:44 UTC (rev 295467)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-10 23:26:43 UTC (rev 295468)
@@ -5897,6 +5897,7 @@
traits.smartQuotesType = UITextSmartQuotesTypeNo;
if ([traits respondsToSelector:@selector(setSmartDashesType:)])
traits.smartDashesType = UITextSmartDashesTypeNo;
+traits.spellCheckingType = UITextSpellCheckingTypeNo;
}
switch (_focusedElementInformation.inputMode) {
Modified: trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm (295467 => 295468)
--- trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm 2022-06-10 23:10:44 UTC (rev 295467)
+++ trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm 2022-06-10 23:26:43 UTC (rev 295468)
@@ -624,7 +624,7 @@
EXPECT_EQ(inputView.get(), [contentView inputView]);
}
-TEST(KeyboardInputTests, DisableSmartQuotesAndDashes)
+TEST(KeyboardInputTests, DisableSpellChecking)
{
auto webView = adoptNS([[TestWKWebView alloc] initWithFrame:CGRectMake(0, 0, 320, 500)]);
auto inputDelegate = adoptNS([[TestInputDelegate alloc] init]);
@@ -633,27 +633,28 @@
}];
[webView _setInputDelegate:inputDelegate.get()];
-auto checkSmartQuotesAndDashesType = [&] (UITextSmartDashesType dashesType, UITextSmartQuotesType quotesType) {
+auto checkSmartQuotesAndDashesType = [&] (UITextSmartDashesType dashesType, UITextSmartQuotesType quotesType, UITextSpellCheckingType spellCheckingType) {
UITextInputTraits *traits = [[webView textInputContentView] textInputTraits];
EXPECT_EQ(dashesType, traits.smartDashesType);
EXPECT_EQ(quotesType, traits.smartQuotesType);
+EXPECT_EQ(spellCheckingType, traits.spellCheckingType);
};
[webView synchronouslyLoadHTMLString:@""];
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"foo.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo);
+checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo, UITextSpellCheckingTypeNo);
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"bar.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo);
+checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo, UITextSpellCheckingTypeNo);
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"baz.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo);
+checkSmartQuotesAndDashesType(UITextSmartDashesTypeNo, UITextSmartQuotesTypeNo, UITextSpellCheckingTypeNo);
[webView synchronouslyLoadHTMLString:@""];
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"foo.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeDefault, UITextSmartQuotesTypeDefault);
+checkSmartQuotesAndDashesType(UITextSmartDashesTypeDefault, UITextSmartQuotesTypeDefault, UITextSpellCheckingTypeDefault);
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"bar.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeDefault, UITextSmartQuotesTypeDefault);
+checkSmartQuotesAndDashesType(UITextSmartDashesTypeDefault, UITextSmartQuotesTypeDefault, UITextSpellCheckingTypeDefault);
[webView evaluateJavaScriptAndWaitForInputSessionToChange:@"baz.focus()"];
-checkSmartQuotesAndDashesType(UITextSmartDashesTypeDefault, UITextSmartQuotesTypeDefault);
+
[webkit-changes] [295464] trunk
Title: [295464] trunk Revision 295464 Author wenson_hs...@apple.com Date 2022-06-10 14:49:55 -0700 (Fri, 10 Jun 2022) Log Message Update TBA API availability macros for iOS 16 and macOS Ventura https://bugs.webkit.org/show_bug.cgi?id=241482 rdar://94651561 Reviewed by Tim Horton. Update `WK_MAC_TBA` and `WK_IOS_TBA` macros to 13.0 and 16.0, respectively. * Source/WebKit/Shared/API/Cocoa/WKMain.h: * Source/WebKit/Shared/API/Cocoa/_WKHitTestResult.h: * Source/WebKit/UIProcess/API/Cocoa/WKError.h: * Source/WebKit/UIProcess/API/Cocoa/WKMenuItemIdentifiersPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKPreferences.h: Mark these two API properties as available since macOS 12.3 and iOS 15.4. These were first introduced in these respective macOS and iOS versions, but with incorrect availability macros indicating that they were available since 12.0 and 15.0. * Source/WebKit/UIProcess/API/Cocoa/WKPreferencesPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKProcessPoolPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKUserContentControllerPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebView.h: Also, mark `setMinimumViewportInset:maximumViewportInset:`, `minimumViewportInset`, and `maximumViewportInset` as being available since iOS 15.5. * Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h: (-[WKWebView _dataTaskWithRequest:completionHandler:]): * Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferencesPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataRecord.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataRecordPrivate.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h: * Source/WebKit/UIProcess/API/Cocoa/_WKApplicationManifest.h: * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticatorSelectionCriteria.h: * Source/WebKit/UIProcess/API/Cocoa/_WKAutomationSession.h: * Source/WebKit/UIProcess/API/Cocoa/_WKContentRuleListAction.h: * Source/WebKit/UIProcess/API/Cocoa/_WKDataTask.h: * Source/WebKit/UIProcess/API/Cocoa/_WKDataTaskDelegate.h: * Source/WebKit/UIProcess/API/Cocoa/_WKElementAction.h: * Source/WebKit/UIProcess/API/Cocoa/_WKModalContainerInfo.h: * Source/WebKit/UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h: * Source/WebKit/UIProcess/API/Cocoa/_WKResidentKeyRequirement.h: * Source/WebKit/UIProcess/API/Cocoa/_WKSystemPreferences.h: * Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.h: * Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.h: * Source/WebKit/WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInCSSStyleDeclarationHandle.h: * Source/WebKit/WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h: * Source/WebKit/WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInNodeHandle.h: * Tools/Scripts/webkitpy/common/version_name_map.py: (VersionNameMap.__init__): Canonical link: https://commits.webkit.org/251470@main Modified Paths trunk/Source/WebKit/Shared/API/Cocoa/WKMain.h trunk/Source/WebKit/Shared/API/Cocoa/_WKHitTestResult.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKError.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKMenuItemIdentifiersPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferences.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferencesPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKProcessPoolPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKUserContentControllerPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferencesPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataRecord.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataRecordPrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKApplicationManifest.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticatorSelectionCriteria.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKAutomationSession.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKContentRuleListAction.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKDataTask.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKDataTaskDelegate.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKElementAction.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKModalContainerInfo.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKResidentKeyRequirement.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKSystemPreferences.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.h trunk/Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.h
[webkit-changes] [295441] trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Title: [295441] trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Revision 295441
Author wenson_hs...@apple.com
Date 2022-06-09 17:14:26 -0700 (Thu, 09 Jun 2022)
Log Message
[ iOS Debug ] ASSERTION FAILED: Attempt to access post layout data before receiving it on editing/editable-region/fixed-and-absolute-contenteditable-scrolled.html
https://bugs.webkit.org/show_bug.cgi?id=237541
rdar://89918871
Reviewed by Simon Fraser.
After the changes in r289876, this test started sometimes hitting an assertion when run immediately
after `editing/deleting/ios/backspace-last-character.html`. By eliminating a sync IPC call to the
web content process when requesting autocorrection information, UIKit now requests selection-caret-
relative character information slightly earlier than it previously did when dismissing the keyboard,
which may occur after we've received an editor state update after blurring the focused element, but
before we've received post-layout data.
In this scenario, we already know that the focused element has been blurred and the selection is no
longer editable, so once the post-layout data does arrive, it would contain `0` for all of the
characters close to the selection caret.
As such, we can simply return 0 early before attempting to access post-layout data if the selection
is not a caret in editable content, since all of the relevant post-layout data members
(`characterAfterSelection`, `characterBeforeSelection` and `twoCharacterBeforeSelection`) are going
to be 0 anyways.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _characterInRelationToCaretSelection:]):
Canonical link: https://commits.webkit.org/251447@main
Modified Paths
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Diff
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (295440 => 295441)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-09 23:43:51 UTC (rev 295440)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-10 00:14:26 UTC (rev 295441)
@@ -4869,20 +4869,22 @@
});
}
-- (UTF32Char)_characterBeforeCaretSelection
+- (UTF32Char)_characterInRelationToCaretSelection:(int)amount
{
-return _lastInsertedCharacterToOverrideCharacterBeforeSelection.value_or(_page->editorState().postLayoutData().characterBeforeSelection);
-}
+if (amount == -1 && _lastInsertedCharacterToOverrideCharacterBeforeSelection)
+return *_lastInsertedCharacterToOverrideCharacterBeforeSelection;
-- (UTF32Char)_characterInRelationToCaretSelection:(int)amount
-{
+auto& state = _page->editorState();
+if (!state.isContentEditable || state.selectionIsNone || state.selectionIsRange)
+return 0;
+
switch (amount) {
case 0:
-return _page->editorState().postLayoutData().characterAfterSelection;
+return state.postLayoutData().characterAfterSelection;
case -1:
-return self._characterBeforeCaretSelection;
+return state.postLayoutData().characterBeforeSelection;
case -2:
-return _page->editorState().postLayoutData().twoCharacterBeforeSelection;
+return state.postLayoutData().twoCharacterBeforeSelection;
default:
return 0;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295427] trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/ WebAuthenticatorCoordinatorProxy.mm
Title: [295427] trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm Revision 295427 Author wenson_hs...@apple.com Date 2022-06-09 11:57:46 -0700 (Thu, 09 Jun 2022) Log Message Unreviewed, fix the internal iOS build Add a missing header include (due to source unification order). * Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm: Canonical link: https://commits.webkit.org/251433@main Modified Paths trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm Diff Modified: trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm (295426 => 295427) --- trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm 2022-06-09 18:35:15 UTC (rev 295426) +++ trunk/Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm 2022-06-09 18:57:46 UTC (rev 295427) @@ -38,6 +38,7 @@ #import #import #import +#import #import "AuthenticationServicesCoreSoftLink.h" ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295367] trunk
Title: [295367] trunk Revision 295367 Author wenson_hs...@apple.com Date 2022-06-07 15:46:18 -0700 (Tue, 07 Jun 2022) Log Message [Live Text in Video] Rename "video extraction" code to refer to text recognition instead https://bugs.webkit.org/show_bug.cgi?id=241381 rdar://94446831 Reviewed by Tim Horton. Replace all references to "fullscreen video extraction" with "text recognition in fullscreen video" instead, to reflect the real purpose of this code. No change in behavior. * Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didChangePlaybackRate): (WebKit::WebPageProxy::didChangeCurrentTime): (WebKit::WebPageProxy::updateFullscreenVideoTextRecognition): (WebKit::WebPageProxy::fullscreenVideoTextRecognitionTimerFired): (WebKit::WebPageProxy::updateFullscreenVideoExtraction): Deleted. (WebKit::WebPageProxy::fullscreenVideoExtractionTimerFired): Deleted. * Source/WebKit/UIProcess/Cocoa/WebViewImpl.h: * Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::beginTextRecognitionForVideoInElementFullscreen): (WebKit::WebViewImpl::cancelTextRecognitionForVideoInElementFullscreen): (WebKit::WebViewImpl::beginElementFullscreenVideoExtraction): Deleted. (WebKit::WebViewImpl::cancelElementFullscreenVideoExtraction): Deleted. * Source/WebKit/UIProcess/PageClient.h: (WebKit::PageClient::isTextRecognitionInFullscreenVideoEnabled const): (WebKit::PageClient::beginTextRecognitionForVideoInElementFullscreen): (WebKit::PageClient::cancelTextRecognitionForVideoInElementFullscreen): (WebKit::PageClient::isFullscreenVideoExtractionEnabled const): Deleted. (WebKit::PageClient::beginElementFullscreenVideoExtraction): Deleted. (WebKit::PageClient::cancelElementFullscreenVideoExtraction): Deleted. * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::m_fullscreenVideoTextRecognitionTimer): (WebKit::WebPageProxy::didEnterFullscreen): (WebKit::WebPageProxy::didExitFullscreen): (WebKit::WebPageProxy::resetStateAfterProcessExited): (WebKit::WebPageProxy::beginTextRecognitionForVideoInElementFullScreen): (WebKit::WebPageProxy::cancelTextRecognitionForVideoInElementFullScreen): (WebKit::m_fullscreenVideoExtractionTimer): Deleted. (WebKit::WebPageProxy::extractVideoInElementFullScreen): Deleted. (WebKit::WebPageProxy::cancelVideoExtractionInElementFullScreen): Deleted. * Source/WebKit/UIProcess/WebPageProxy.h: * Source/WebKit/UIProcess/WebPageProxy.messages.in: * Source/WebKit/UIProcess/ios/PageClientImplIOS.h: * Source/WebKit/UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::beginTextRecognitionForFullscreenVideo): (WebKit::PageClientImpl::cancelTextRecognitionForFullscreenVideo): (WebKit::PageClientImpl::isTextRecognitionInFullscreenVideoEnabled const): (WebKit::PageClientImpl::beginTextRecognitionForVideoInElementFullscreen): (WebKit::PageClientImpl::cancelTextRecognitionForVideoInElementFullscreen): (WebKit::PageClientImpl::beginFullscreenVideoExtraction): Deleted. (WebKit::PageClientImpl::cancelFullscreenVideoExtraction): Deleted. (WebKit::PageClientImpl::isFullscreenVideoExtractionEnabled const): Deleted. (WebKit::PageClientImpl::beginElementFullscreenVideoExtraction): Deleted. (WebKit::PageClientImpl::cancelElementFullscreenVideoExtraction): Deleted. * Source/WebKit/UIProcess/ios/WKContentViewInteraction.h: * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView beginTextRecognitionForFullscreenVideo:playerViewController:]): (-[WKContentView cancelTextRecognitionForFullscreenVideo:]): (-[WKContentView isTextRecognitionInFullscreenVideoEnabled]): (-[WKContentView beginTextRecognitionForVideoInElementFullscreen:bounds:]): (-[WKContentView cancelTextRecognitionForVideoInElementFullscreen]): (-[WKContentView beginFullscreenVideoExtraction:playerViewController:]): Deleted. (-[WKContentView cancelFullscreenVideoExtraction:]): Deleted. (-[WKContentView isFullscreenVideoExtractionEnabled]): Deleted. (-[WKContentView beginElementFullscreenVideoExtraction:bounds:]): Deleted. (-[WKContentView cancelElementFullscreenVideoExtraction]): Deleted. * Source/WebKit/UIProcess/mac/PageClientImplMac.h: * Source/WebKit/UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::beginTextRecognitionForVideoInElementFullscreen): (WebKit::PageClientImpl::cancelTextRecognitionForVideoInElementFullscreen): (WebKit::PageClientImpl::beginElementFullscreenVideoExtraction): Deleted. (WebKit::PageClientImpl::cancelElementFullscreenVideoExtraction): Deleted. * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp: (WebKit::WebFullScreenManager::WebFullScreenManager): (WebKit::WebFullScreenManager::handleEvent): (WebKit::WebFullScreenManager::mainVideoElementTextRecognitionTimerFired): (WebKit::WebFullScreenManager::scheduleTextRecognitionForMainVideo): (WebKit::WebFullScreenManager::endTextRecognitionForMainVideoIfNeeded): (WebKit::WebFullScreenManager::setMainVideoElement): (WebKit::WebFullScreenManager::mainVideoElementExtractionTimerFired): Deleted.
[webkit-changes] [295360] trunk/Source
Title: [295360] trunk/Source Revision 295360 Author wenson_hs...@apple.com Date 2022-06-07 12:52:13 -0700 (Tue, 07 Jun 2022) Log Message Upstream WebKit support for Stage Manager on iPadOS https://bugs.webkit.org/show_bug.cgi?id=241372 rdar://94540740 Reviewed by Tim Horton. Upstream support for viewport and snapshotting behaviors that are specific to window resizing on iPad, when Stage Manager is enabled. In particular, this merges the existing `MULTITASKING_MODE` and `MAC_CATALYST_LIVE_RESIZE` feature flags into a single `UIKIT_RESIZABLE_WINDOWS` flag, which is used to guard both snapshotting and viewport code. * Source/WTF/wtf/PlatformHave.h: * Source/WebKit/Platform/spi/ios/UIKitSPI.h: * Source/WebKit/Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Source/WebKit/Shared/WebPageCreationParameters.h: * Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView dealloc]): * Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h: * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h: * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm: (-[WKWebView setFrame:]): (-[WKWebView setBounds:]): (-[WKWebView _registerForNotifications]): (-[WKWebView _processWillSwapOrDidExit]): (-[WKWebView didMoveToWindow]): (-[WKWebView _isWindowResizingEnabled]): (-[WKWebView _enhancedWindowingToggled:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): (-[WKWebView _multitaskingModeDidChange:]): Deleted. * Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm: (-[WKWebView _hasResizeAssertion]): * Source/WebKit/UIProcess/PageClient.h: (WebKit::PageClient::hasResizableWindows const): (WebKit::PageClient::isInMultitaskingMode const): Deleted. * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): (WebKit::WebPageProxy::setIsWindowResizingEnabled): (WebKit::WebPageProxy::setIsInMultitaskingMode): Deleted. * Source/WebKit/UIProcess/WebPageProxy.h: * Source/WebKit/UIProcess/ios/PageClientImplIOS.h: * Source/WebKit/UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::hasResizableWindows const): (WebKit::PageClientImpl::isInMultitaskingMode const): Deleted. * Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::isDesktopClassBrowsingRecommended const): * Source/WebKit/WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::setIsWindowResizingEnabled): (WebKit::WebPage::setIsInMultitaskingMode): Deleted. * Source/WebKit/WebProcess/WebPage/WebPage.h: * Source/WebKit/WebProcess/WebPage/WebPage.messages.in: * Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::shouldEnableViewportBehaviorsForResizableWindows const): (WebKit::WebPage::usesMultitaskingModeViewportBehaviors const): Deleted. Canonical link: https://commits.webkit.org/251369@main Modified Paths trunk/Source/WTF/wtf/PlatformHave.h trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h trunk/Source/WebKit/Shared/WebPageCreationParameters.cpp trunk/Source/WebKit/Shared/WebPageCreationParameters.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm trunk/Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm trunk/Source/WebKit/UIProcess/PageClient.h trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/ios/PageClientImplIOS.h trunk/Source/WebKit/UIProcess/ios/PageClientImplIOS.mm trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm Diff Modified: trunk/Source/WTF/wtf/PlatformHave.h (295359 => 295360) --- trunk/Source/WTF/wtf/PlatformHave.h 2022-06-07 18:38:05 UTC (rev 295359) +++ trunk/Source/WTF/wtf/PlatformHave.h 2022-06-07 19:52:13 UTC (rev 295360) @@ -1214,3 +1214,7 @@ || ((PLATFORM(IOS) || PLATFORM(MACCATALYST)) && __IPHONE_OS_VERSION_MAX_ALLOWED >= 16)) #define HAVE_VK_IMAGE_TRANSLATION_SUPPORT 1 #endif + +#if !defined(HAVE_UIKIT_RESIZABLE_WINDOWS) && PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 16 +#define HAVE_UIKIT_RESIZABLE_WINDOWS 1 +#endif Modified: trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h (295359 => 295360) --- trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2022-06-07 18:38:05 UTC (rev 295359) +++ trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2022-06-07 19:52:13 UTC (rev 295360) @@ -89,6 +89,7 @@ #import #import #import +#import #import #import #import @@ -149,6 +150,11 @@ #import #endif +#if HAVE(UIKIT_RESIZABLE_WINDOWS) +#import +#import +#endif + // FIXME: STAGING for rdar://75546704 Remove later. #define
[webkit-changes] [295347] trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
Title: [295347] trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
Revision 295347
Author wenson_hs...@apple.com
Date 2022-06-07 08:37:35 -0700 (Tue, 07 Jun 2022)
Log Message
Unreviewed, fix several failing API tests on iOS 15 after r295346
https://bugs.webkit.org/show_bug.cgi?id=241341
rdar://94446831
Rename a couple of strings that I missed in the original upstreaming patch. These tests ran normally
for me on iOS 16 simulator, since these system feature flags were enabled by default; however, iOS
15 relies on these feature flags being enabled for the web view through preferences.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm:
(-[TestWKWebView waitForImageAnalysisRequests:]):
Also, drive-by-fix a minor grammar error in a logging string.
(TestWebKitAPI::createWebViewWithTextRecognitionEnhancements):
Canonical link: https://commits.webkit.org/251362@main
Modified Paths
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm
Diff
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm (295346 => 295347)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm 2022-06-07 15:19:30 UTC (rev 295346)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/ImageAnalysisTests.mm 2022-06-07 15:37:35 UTC (rev 295347)
@@ -78,7 +78,7 @@
{
TestWebKitAPI::Util::waitForConditionWithLogging([&] {
return gDidProcessRequestCount == numberOfRequests;
-}, 3, @"Timed out waiting for %u image analysis to complete.", numberOfRequests);
+}, 3, @"Timed out waiting for %u image analysis requests to complete.", numberOfRequests);
[self waitForNextPresentationUpdate];
EXPECT_EQ(gDidProcessRequestCount, numberOfRequests);
@@ -154,7 +154,7 @@
RetainPtr configuration = [WKWebViewConfiguration _test_configurationWithTestPlugInClassName:@"WebProcessPlugInWithInternals" configureJSCForTesting:YES];
for (_WKInternalDebugFeature *feature in WKPreferences._internalDebugFeatures) {
NSString *key = feature.key;
-if ([key isEqualToString:@"TextRecognitionEnhancementsEnabled"] || [key isEqualToString:@"ImageAnalysisQueueEnabled"] || [key isEqualToString:@"RemoveBackgroundEnabled"])
+if ([key isEqualToString:@"TextRecognitionInVideosEnabled"] || [key isEqualToString:@"VisualTranslationEnabled"] || [key isEqualToString:@"RemoveBackgroundEnabled"])
[[configuration preferences] _setEnabled:YES forInternalDebugFeature:feature];
}
[configuration _setAttachmentElementEnabled:YES];
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295299] trunk
Title: [295299] trunk Revision 295299 Author wenson_hs...@apple.com Date 2022-06-06 15:08:33 -0700 (Mon, 06 Jun 2022) Log Message [iOS] Keyboard obscures file upload context menu when trying to attach a file in gmail.com https://bugs.webkit.org/show_bug.cgi?id=241320 rdar://84667910 Reviewed by Tim Horton. When composing a message on gmail.com, if a user taps the "Attach file" button in the bottom toolbar, Gmail's script programmatically clicks a hidden file input and then immediately focuses the editable body field. The context menu presents at the interaction location near the bottom of the viewport; however, if no hardware keyboard is attached, the software keyboard appears right afterwards, obscuring the context menu completely. To address this, teach `WKFileUploadPanel` to reposition its context menu when the keyboard is shown, if it might overlap with the bounds of the input view. * LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard-expected.txt: Added. * LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard.html: Added. Add a layout test to verify that focusing a text field with the software keyboard while presenting a file picker doesn't result in the file picker's context menu being obscured behind the keyboard. * LayoutTests/resources/ui-helper.js: (window.UIHelper.dismissMenu): (window.UIHelper.contextMenuRect): Add a couple of new UIHelper methods. * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _keyboardDidShow]): If the keyboard appears while the file upload panel is active, reposition the context menu if it overlaps with the new keyboard bounds. (-[WKContentView _zoomToFocusRectAfterShowingKeyboardIfNeeded]): Factor this existing logic out into a helper method. * Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h: * Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel contextMenuInteraction:willEndForConfiguration:animator:]): If the `_isRepositioningContextMenu` flag is set, avoid removing and destroying the context menu interaction. (-[WKFileUploadPanel ensureContextMenuInteraction]): Drive-by fix: adjust `-ensureContextMenuInteraction` so that it returns the either the existing or newly created context menu interaction. (-[WKFileUploadPanel repositionContextMenuIfNeeded]): Add a helper method to reposition the context menu by removing and re-presenting the context menu interaction without animation, only if it overlaps the input view bounds. While removing and presenting the context menu again, set a `_isRepositioningContextMenu` flag, such that (-[WKFileUploadPanel showDocumentPickerMenu]): * Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * Tools/TestRunnerShared/UIScriptContext/UIScriptController.h: (WTR::UIScriptController::contextMenuRect const): * Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm: (-[TestRunnerWKWebView _dismissAllContextMenuInteractions]): Adjust this helper to immediately cancel all context menu interactions without animation, so that context menu removal delegate methods don't bleed into subsequent tests. * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h: * Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptControllerIOS::menuRect const): Use the new `toObject` helper method. (WTR::UIScriptControllerIOS::contextMenuRect const): Add support for a new script controller method to return the context menu container view's bounds in window coordinates. Note that I'm using window coordinates here as opposed to root view coordinates, since the new test that uses this method needs to compare the context menu's position against the input view bounds in window coordinates. (WTR::UIScriptControllerIOS::toObject const): Add a helper method to convert the given `CGRect` into a _javascript_ object reference. Canonical link: https://commits.webkit.org/251344@main Modified Paths trunk/LayoutTests/resources/ui-helper.js trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h trunk/Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm trunk/Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl trunk/Tools/TestRunnerShared/UIScriptContext/UIScriptController.h trunk/Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm trunk/Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h trunk/Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm Added Paths trunk/LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard-expected.txt trunk/LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard.html Diff Added: trunk/LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard-expected.txt (0 => 295299) --- trunk/LayoutTests/fast/forms/ios/show-file-upload-context-menu-above-keyboard-expected.txt (rev 0) +++
[webkit-changes] [295290] trunk
Title: [295290] trunk Revision 295290 Author wenson_hs...@apple.com Date 2022-06-06 10:36:12 -0700 (Mon, 06 Jun 2022) Log Message REGRESSION (r291302): editing/secure-input tests fail when run while a password input is focused on the system https://bugs.webkit.org/show_bug.cgi?id=241324 rdar://94184618 Reviewed by Alexey Proskuryakov. The tests in `editing/secure-input` fail after the removal of `WebCoreTestShim` in r291302, if a secure text field is focused anywhere on the system while the tests are running. This is because we now call into the real system `IsSecureEventInputEnabled()` API during these tests, instead of the shimmed version for testing. Since interposing these API functions apparently doesn't work on M1 Macs, we can't use this technique to ensure that these tests are robust moving forward; instead, introduce and use testing- only SPI (and IPI) to consult whether or not we're currently editing a secure input. See below for more details. * Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h: * Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm: (-[WKWebView _secureEventInputEnabledForTesting]): Add testing-only SPI on WKWebView to return whether or not we're in a secure input, as an alternative to calling into the actual `IsSecureEventInputEnabled()` API. * Source/WebKitLegacy/WebKitLegacy.xcodeproj/project.pbxproj: * Source/WebKitLegacy/mac/WebView/WebHTMLView.mm: (-[WebHTMLView _secureEventInputEnabledForTesting]): * Source/WebKitLegacy/mac/WebView/WebHTMLViewForTestingMac.h: Copied from Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h. Add a testing-only header file that's internal (i.e. non-exported), but imported in DumpRenderTree through a Source-relative header include path. At the moment, this only contains a method to check whether or not we're currently editing a secure text input, as an alternative to calling into `IsSecureEventInputEnabled()`. * Tools/DumpRenderTree/TestRunner.cpp: (getSecureEventInputIsEnabledCallback): (TestRunner::isSecureEventInputEnabled const): Adjust DumpRenderTree to consult `-[WebHTMLView _secureEventInputEnabledForTesting]`. * Tools/DumpRenderTree/TestRunner.h: * Tools/DumpRenderTree/mac/Configurations/Base.xcconfig: Add a relative include path on DumpRenderTree, so that we can use `WebHTMLViewForTestingMac.h` in DumpRenderTree without having to introduce new WebKitLegacy SPI. * Tools/DumpRenderTree/mac/TestRunnerMac.mm: (TestRunner::isSecureEventInputEnabled const): * Tools/WebKitTestRunner/PlatformWebView.h: (WTR::PlatformWebView::platformView const): (WTR::PlatformWebView::platformWindow const): (WTR::PlatformWebView::platformView): Deleted. (WTR::PlatformWebView::platformWindow): Deleted. Mark `platformView` const so that it can be invoked from `isSecureEventInputEnabled`, and also mark `platformWindow` const for consistency. * Tools/WebKitTestRunner/TestInvocation.cpp: (WTR::TestInvocation::didReceiveSynchronousMessageFromInjectedBundle): * Tools/WebKitTestRunner/gtk/PlatformWebViewGtk.cpp: (WTR::PlatformWebView::isSecureEventInputEnabled const): * Tools/WebKitTestRunner/ios/PlatformWebViewIOS.mm: (WTR::PlatformWebView::isSecureEventInputEnabled const): * Tools/WebKitTestRunner/libwpe/PlatformWebViewLibWPE.cpp: (WTR::PlatformWebView::isSecureEventInputEnabled const): * Tools/WebKitTestRunner/mac/PlatformWebViewMac.mm: (WTR::PlatformWebView::isSecureEventInputEnabled const): Add a new `isSecureEventInputEnabled` method on the `PlatformWebView`, and adjust WebKitTestRunner to consult `-[WKWebView _secureEventInputEnabledForTesting]`. * Tools/WebKitTestRunner/win/PlatformWebViewWin.cpp: (WTR::PlatformWebView::isSecureEventInputEnabled const): Canonical link: https://commits.webkit.org/251336@main Modified Paths trunk/Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h trunk/Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm trunk/Source/WebKitLegacy/WebKitLegacy.xcodeproj/project.pbxproj trunk/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm trunk/Tools/DumpRenderTree/TestRunner.cpp trunk/Tools/DumpRenderTree/TestRunner.h trunk/Tools/DumpRenderTree/mac/Configurations/Base.xcconfig trunk/Tools/DumpRenderTree/mac/TestRunnerMac.mm trunk/Tools/WebKitTestRunner/PlatformWebView.h trunk/Tools/WebKitTestRunner/TestInvocation.cpp trunk/Tools/WebKitTestRunner/gtk/PlatformWebViewGtk.cpp trunk/Tools/WebKitTestRunner/ios/PlatformWebViewIOS.mm trunk/Tools/WebKitTestRunner/libwpe/PlatformWebViewLibWPE.cpp trunk/Tools/WebKitTestRunner/mac/PlatformWebViewMac.mm trunk/Tools/WebKitTestRunner/win/PlatformWebViewWin.cpp Added Paths trunk/Source/WebKitLegacy/mac/WebView/WebHTMLViewForTestingMac.h Diff Modified: trunk/Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h (295289 => 295290) --- trunk/Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h 2022-06-06 15:57:15 UTC (rev 295289) +++ trunk/Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h
[webkit-changes] [295289] trunk
Title: [295289] trunk
Revision 295289
Author wenson_hs...@apple.com
Date 2022-06-06 08:57:15 -0700 (Mon, 06 Jun 2022)
Log Message
[iOS 15] Unable to type in Google Docs with a hardware keyboard without refocusing editor
https://bugs.webkit.org/show_bug.cgi?id=241308
rdar://90755619
Reviewed by Tim Horton.
After the changes in r277265, we no longer call into `-reloadInputViews` when starting an input
session after programmatically focusing an editable container with `inputmode="none"`, with a
hardware keyboard attached. This is because `-_shouldShowKeyboardForElement:` returns `NO` (due to
inputmode none), so we bail early at this check:
```
if (!shouldShowInputView || information.elementType == WebKit::InputType::None) {
_page->setIsShowingInputViewForFocusedElement(false);
return;
}
```
As a result, UIKit never resets UIKeyboardImpl's input delegate, which should now be the
`WKContentView`, and thus never consults whether we require key events (`-requiresKeyEvents`), which
in turn means that `-handleKeyWebEvent:withCompletionHandler:` is never invoked on the content view,
so we never dispatch key events to the page.
In the normal, non-editable key event case, we lazily call `-reloadInputViews` in
`-_handleKeyUIEvent:` (which is called just before keyboard WebEvents start getting dispatched by
UIKit). However, since we're still focusing an editable element in this case, we don't end up going
down this codepath.
When the hardware keyboard is not connected, avoiding the call to `-reloadInputViews` is expected,
since we aren't showing a keyboard anyways due to the fact that the element was programmatically
focused (so the user has no way of typing or dispatching key events, in the first place).
And finally, when the `inputmode` is not none, `_isFocusingElementWithKeyboard` is set to `YES`, so
we begin the input session and call `-reloadInputViews` as normal.
It's only in this `inputmode=none` case with both the hardware keyboard attached and the editable
container being programmatically focused, where we end up in a state where the user can type with a
hardware keyboard, but we haven't informed UIKit that we should receive key events.
We can fix this by consulting a separate `-_shouldShowKeyboardForElementIgnoringInputMode:` instead
which allows us to follow the normal routine for focusing an editable element with `inputmode="none"`
which includes zooming to reveal the focused element if it's on-screen and not hidden, as well as
calling the related delegate methods; the only difference is that we avoid showing the UCB or
software keyboard, by returning `YES` from `-_disableAutomaticKeyboardUI` in this case.
* LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none-expected.txt: Added.
* LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none.html: Added.
Add a new layout test to simulate typing in Google Docs with a hardware keyboard (i.e., focus a
hidden contenteditable container with `inputmode="none"`), and verify that we dispatch key events to
the focused editable element.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _elementTypeRequiresAccessoryView:]):
(-[WKContentView _shouldShowKeyboardForElement:]):
(-[WKContentView _shouldShowKeyboardForElementIgnoringInputMode:]):
Split this helper method into two versions (one of which ignores `inputmode=none`). See above for
more details.
(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
Canonical link: https://commits.webkit.org/251335@main
Modified Paths
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Added Paths
trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none-expected.txt
trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none.html
Diff
Added: trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none-expected.txt (0 => 295289)
--- trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none-expected.txt 2022-06-06 15:57:15 UTC (rev 295289)
@@ -0,0 +1,13 @@
+This test verifies that key events are dispatched when performing a keypress in a programmatically focused hidden editable container with inputmode='none'. To manually run the test, load the page with a hardware keyboard attached and press the 'a' key.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+PASS Observed keydown with key: "a"
+PASS Observed keypress with key: "a"
+PASS Observed keyup with key: "a"
+PASS observedKeyUp became true
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: trunk/LayoutTests/fast/forms/ios/keydown-in-hidden-contenteditable-with-inputmode-none.html (0 => 295289)
---
[webkit-changes] [295223] trunk/Source/WebKit/UIProcess
Title: [295223] trunk/Source/WebKit/UIProcess
Revision 295223
Author wenson_hs...@apple.com
Date 2022-06-03 13:24:46 -0700 (Fri, 03 Jun 2022)
Log Message
Allow the element fullscreen security heuristic to ignore certain touches
https://bugs.webkit.org/show_bug.cgi?id=241068
Reviewed by Eric Carlson.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _shouldAvoidSecurityHeuristicScoreUpdates]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _shouldAvoidSecurityHeuristicScoreUpdates]):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
(-[WKFullScreenViewController _touchDetected:]):
Canonical link: https://commits.webkit.org/251278@main
Modified Paths
trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h
trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm
Diff
Modified: trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h (295222 => 295223)
--- trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h 2022-06-03 20:24:04 UTC (rev 295222)
+++ trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h 2022-06-03 20:24:46 UTC (rev 295223)
@@ -162,6 +162,8 @@
@property (nonatomic, readonly) WKWebViewContentProviderRegistry *_contentProviderRegistry;
@property (nonatomic, readonly) WKSelectionGranularity _selectionGranularity;
+@property (nonatomic, readonly) BOOL _shouldAvoidSecurityHeuristicScoreUpdates;
+
@property (nonatomic, readonly) BOOL _isBackground;
@property (nonatomic, readonly) BOOL _allowsDoubleTapGestures;
@property (nonatomic, readonly) BOOL _haveSetObscuredInsets;
Modified: trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm (295222 => 295223)
--- trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm 2022-06-03 20:24:04 UTC (rev 295222)
+++ trunk/Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm 2022-06-03 20:24:46 UTC (rev 295223)
@@ -40,7 +40,7 @@
#import "VideoFullscreenManagerProxy.h"
#import "ViewGestureController.h"
#import "WKBackForwardListItemInternal.h"
-#import "WKContentView.h"
+#import "WKContentViewInteraction.h"
#import "WKPasswordView.h"
#import "WKSafeBrowsingWarning.h"
#import "WKScrollView.h"
@@ -2742,6 +2742,11 @@
[super buildMenuWithBuilder:builder];
}
+- (BOOL)_shouldAvoidSecurityHeuristicScoreUpdates
+{
+return [_contentView _shouldAvoidSecurityHeuristicScoreUpdates];
+}
+
#if HAVE(UIFINDINTERACTION)
- (id)_searchableObject
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h (295222 => 295223)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h 2022-06-03 20:24:04 UTC (rev 295222)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h 2022-06-03 20:24:46 UTC (rev 295223)
@@ -753,6 +753,7 @@
@property (nonatomic, readonly) BOOL _shouldAvoidResizingWhenInputViewBoundsChange;
@property (nonatomic, readonly) BOOL _shouldAvoidScrollingWhenFocusedContentIsVisible;
@property (nonatomic, readonly) BOOL _shouldUseLegacySelectPopoverDismissalBehavior;
+@property (nonatomic, readonly) BOOL _shouldAvoidSecurityHeuristicScoreUpdates;
- (void)_didChangeLinkPreviewAvailability;
- (void)setContinuousSpellCheckingEnabled:(BOOL)enabled;
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (295222 => 295223)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-03 20:24:04 UTC (rev 295222)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2022-06-03 20:24:46 UTC (rev 295223)
@@ -11068,6 +11068,11 @@
{
}
+- (BOOL)_shouldAvoidSecurityHeuristicScoreUpdates
+{
+return NO;
+}
+
#endif
@end
Modified: trunk/Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm (295222 => 295223)
--- trunk/Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm 2022-06-03 20:24:04 UTC (rev 295222)
+++ trunk/Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm 2022-06-03 20:24:46 UTC (rev 295223)
@@ -33,7 +33,7 @@
#import "UIKitSPI.h"
#import "VideoFullscreenManagerProxy.h"
#import "WKFullscreenStackView.h"
-#import "WKWebViewInternal.h"
+#import "WKWebViewIOS.h"
#import "WebFullScreenManagerProxy.h"
#import "WebPageProxy.h"
#import
@@ -491,7 +491,7 @@
- (void)_touchDetected:(id)sender
{
ASSERT(_valid);
-if ([_touchGestureRecognizer state] == UIGestureRecognizerStateEnded) {
+if ([_touchGestureRecognizer state] == UIGestureRecognizerStateEnded && !self._webView._shouldAvoidSecurityHeuristicScoreUpdates) {
double score = _secheuristic.scoreOfNextTouch([_touchGestureRecognizer locationInView:self.view]);
if (score > _secheuristic.requiredScore())
[self _showPhishingAlert];
[webkit-changes] [295217] trunk/LayoutTests
Title: [295217] trunk/LayoutTests Revision 295217 Author wenson_hs...@apple.com Date 2022-06-03 12:30:11 -0700 (Fri, 03 Jun 2022) Log Message [iOS] editing/selection/ios/do-not-hide-selection-in-visible-container.html fails on iPhone 12 simulator https://bugs.webkit.org/show_bug.cgi?id=241270 rdar://86025461 Reviewed by Tim Horton. This test currently fails when run on iPhone 12 simulator. Due to the slightly wider screen size, the row of buttons at the top of the page no longer wraps to the next line, which in turn causes the output text to have one less space character when compared to the output on iPhone SE. To fix this, make the test robust against this difference by removing each button before the end of the test. This also causes the text ouput on iPad to now match the expected output on iPhone, so we no longer require test expectations that are specific to iPad vs. iPhone. * LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt: * LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container.html: * LayoutTests/platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt: Removed. Canonical link: https://commits.webkit.org/251274@main Modified Paths trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container.html Removed Paths trunk/LayoutTests/platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt Diff Modified: trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt (295216 => 295217) --- trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt 2022-06-03 17:11:25 UTC (rev 295216) +++ trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt 2022-06-03 19:30:11 UTC (rev 295217) @@ -1,5 +1,5 @@ -First field Second field Third field Fourth field + Verifies that native selection UI is not suppressed when focusing an input that is inside an empty container with `overflow: hidden`, but is positioned absolutely such that it is still visible. To manually verify, click on each of the four buttons to move focus into editable areas. After tapping the first and third buttons, you should not see a caret view; after tapping the second and fourth buttons, you should see a caret view. On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". Modified: trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container.html (295216 => 295217) --- trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container.html 2022-06-03 17:11:25 UTC (rev 295216) +++ trunk/LayoutTests/editing/selection/ios/do-not-hide-selection-in-visible-container.html 2022-06-03 19:30:11 UTC (rev 295217) @@ -60,6 +60,7 @@ await UIHelper.activateElementAndWaitForInputSession(buttonToTap); await ensureCaretIsVisible(expectedVisibility); document.activeElement.blur(); +buttonToTap.remove(); } await UIHelper.waitForKeyboardToHide(); Deleted: trunk/LayoutTests/platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt (295216 => 295217) --- trunk/LayoutTests/platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt 2022-06-03 17:11:25 UTC (rev 295216) +++ trunk/LayoutTests/platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt 2022-06-03 19:30:11 UTC (rev 295217) @@ -1,18 +0,0 @@ -First field Second field Third field Fourth field - -Verifies that native selection UI is not suppressed when focusing an input that is inside an empty container with `overflow: hidden`, but is positioned absolutely such that it is still visible. To manually verify, click on each of the four buttons to move focus into editable areas. After tapping the first and third buttons, you should not see a caret view; after tapping the second and fourth buttons, you should see a caret view. - -On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". - -Waiting for caret to hide. -PASS Caret was hidden. -Waiting for caret to show. -PASS Caret was shown. -Waiting for caret to hide. -PASS Caret was hidden. -Waiting for caret to show. -PASS Caret was shown. -PASS successfullyParsed is true - -TEST COMPLETE - ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295105] trunk
Title: [295105] trunk
Revision 295105
Author wenson_hs...@apple.com
Date 2022-06-01 14:42:09 -0700 (Wed, 01 Jun 2022)
Log Message
[macOS] Only allow the active, visible tab to trigger `-_focusWebView:`
https://bugs.webkit.org/show_bug.cgi?id=241108
rdar://93973632
Reviewed by Chris Dumez.
To address , Safari removed their implementation of the UI delegate
method `-_focusWebView:`, which is invoked when a webpage uses `window.open()` with a target, and
which Safari previously handled by making the web view the active tab. However, this breaks a valid
use case in which a webpage uses `window.open()` to open itself in a new tab, and later use it again
to return to the original tab. To address this, we'll restore Safari's implementation of the
`WKWebView` focus delegate method, but will change WebKit to only allow this method call to bubble
up into the client layer in the case where the page that's calling `window.open()` is already active
and visible.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::isInVisibleAndActivePage):
(WebCore::FrameLoader::loadFrameRequest):
(WebCore::createWindow):
* Source/WebCore/page/DOMWindow.cpp:
(WebCore::DOMWindow::focus):
Check that the opener (or source) frame that's triggering the call to `open()` is in a page that's
visible and active.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/mac/FocusWebView.mm: Added.
(TestWebKitAPI::TEST):
Add an API test to verify that `-_focusWebView:` is not called when opening a window once the web
page containing the frame that's calling `window.open()` is unparented from its window.
* Tools/TestWebKitAPI/Tests/mac/open-in-new-tab.html: Added.
* Tools/TestWebKitAPI/cocoa/TestUIDelegate.h:
* Tools/TestWebKitAPI/cocoa/TestUIDelegate.mm:
(-[TestUIDelegate _focusWebView:]):
Canonical link: https://commits.webkit.org/251200@main
Modified Paths
trunk/Source/WebCore/loader/FrameLoader.cpp
trunk/Source/WebCore/page/DOMWindow.cpp
trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
trunk/Tools/TestWebKitAPI/cocoa/TestUIDelegate.h
trunk/Tools/TestWebKitAPI/cocoa/TestUIDelegate.mm
Added Paths
trunk/Tools/TestWebKitAPI/Tests/mac/FocusWebView.mm
trunk/Tools/TestWebKitAPI/Tests/mac/open-in-new-tab.html
Diff
Modified: trunk/Source/WebCore/loader/FrameLoader.cpp (295104 => 295105)
--- trunk/Source/WebCore/loader/FrameLoader.cpp 2022-06-01 20:36:56 UTC (rev 295104)
+++ trunk/Source/WebCore/loader/FrameLoader.cpp 2022-06-01 21:42:09 UTC (rev 295105)
@@ -214,6 +214,12 @@
return frame.document() && frame.document()->isSandboxed(mask);
}
+static bool isInVisibleAndActivePage(const Frame& frame)
+{
+auto* page = frame.page();
+return page && page->isVisibleAndActive();
+}
+
class PageLevelForbidScope {
protected:
explicit PageLevelForbidScope(Page* page)
@@ -1277,7 +1283,7 @@
sourceFrame = _frame;
Frame* targetFrame = sourceFrame->loader().findFrameForNavigation(frameName);
if (targetFrame && targetFrame != sourceFrame) {
-if (Page* page = targetFrame->page())
+if (auto* page = targetFrame->page(); page && isInVisibleAndActivePage(*sourceFrame))
page->chrome().focus();
}
};
@@ -4127,7 +4133,7 @@
if (!request.frameName().isEmpty() && !isBlankTargetFrameName(request.frameName())) {
if (RefPtr frame = lookupFrame.loader().findFrameForNavigation(request.frameName(), openerFrame.document())) {
if (!isSelfTargetFrameName(request.frameName())) {
-if (Page* page = frame->page())
+if (auto* page = frame->page(); page && isInVisibleAndActivePage(openerFrame))
page->chrome().focus();
}
return frame;
Modified: trunk/Source/WebCore/page/DOMWindow.cpp (295104 => 295105)
--- trunk/Source/WebCore/page/DOMWindow.cpp 2022-06-01 20:36:56 UTC (rev 295104)
+++ trunk/Source/WebCore/page/DOMWindow.cpp 2022-06-01 21:42:09 UTC (rev 295105)
@@ -998,7 +998,13 @@
{
RefPtr frame = this->frame();
RefPtr openerFrame = frame ? frame->loader().opener() : nullptr;
-focus(openerFrame && openerFrame != frame && incumbentWindow.frame() == openerFrame);
+focus([&] {
+if (!openerFrame || openerFrame == frame || incumbentWindow.frame() != openerFrame)
+return false;
+
+auto* page = openerFrame->page();
+return page && page->isVisibleAndActive();
+}());
}
void DOMWindow::focus(bool allowFocus)
Modified: trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj (295104 => 295105)
--- trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj 2022-06-01 20:36:56 UTC (rev 295104)
+++ trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj 2022-06-01 21:42:09 UTC (rev 295105)
@@ -,6 +,8 @@
F491DBAE281DE0E80081705F /* image-controls.html in Copy Resources */ = {isa = PBXBuildFile; fileRef =
[webkit-changes] [295103] trunk/Source/WebKit
Title: [295103] trunk/Source/WebKit
Revision 295103
Author wenson_hs...@apple.com
Date 2022-06-01 13:17:33 -0700 (Wed, 01 Jun 2022)
Log Message
Avoid triggering image analysis when the user has disabled Live Text
https://bugs.webkit.org/show_bug.cgi?id=241193
Reviewed by Aditya Keerthi.
* Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.h:
* Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.mm:
(WebKit::canStartImageAnalysis):
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _startImageAnalysis:target:]):
Canonical link: https://commits.webkit.org/251198@main
Modified Paths
trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.h
trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.mm
trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
Diff
Modified: trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.h (295102 => 295103)
--- trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.h 2022-06-01 20:15:53 UTC (rev 295102)
+++ trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.h 2022-06-01 20:17:33 UTC (rev 295103)
@@ -53,6 +53,7 @@
bool textRecognitionEnhancementsSystemFeatureEnabled();
bool imageAnalysisQueueSystemFeatureEnabled();
bool isImageAnalysisMarkupSystemFeatureEnabled();
+bool canStartImageAnalysis(NSString *);
WebCore::TextRecognitionResult makeTextRecognitionResult(CocoaImageAnalysis *);
Modified: trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.mm (295102 => 295103)
--- trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.mm 2022-06-01 20:15:53 UTC (rev 295102)
+++ trunk/Source/WebKit/Platform/cocoa/ImageAnalysisUtilities.mm 2022-06-01 20:17:33 UTC (rev 295103)
@@ -145,6 +145,11 @@
#include
#else
+bool canStartImageAnalysis(NSString *)
+{
+return true;
+}
+
bool textRecognitionEnhancementsSystemFeatureEnabled()
{
#if ENABLE(IMAGE_ANALYSIS_ENHANCEMENTS)
Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm (295102 => 295103)
--- trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2022-06-01 20:15:53 UTC (rev 295102)
+++ trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2022-06-01 20:17:33 UTC (rev 295103)
@@ -39,6 +39,7 @@
#import "FullscreenClient.h"
#import "GlobalFindInPageState.h"
#import "IconLoadingDelegate.h"
+#import "ImageAnalysisUtilities.h"
#import "LegacySessionStateCoding.h"
#import "Logging.h"
#import "MediaUtilities.h"
@@ -2328,7 +2329,7 @@
#if ENABLE(IMAGE_ANALYSIS)
THROW_IF_SUSPENDED;
-if (!_page || !_page->preferences().imageAnalysisQueueEnabled())
+if (!_page || !_page->preferences().imageAnalysisQueueEnabled() || !WebKit::canStartImageAnalysis(source))
return;
_page->startImageAnalysis(source, target);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [295062] trunk
Title: [295062] trunk
Revision 295062
Author wenson_hs...@apple.com
Date 2022-05-31 13:19:12 -0700 (Tue, 31 May 2022)
Log Message
[macOS] Include text context menu actions when right clicking on selected Live Text in a link
https://bugs.webkit.org/show_bug.cgi?id=241069
rdar://91606522
Reviewed by Devin Rousso.
Currently, when right clicking selected text inside of an image that's inside of a link, we only
show context menu actions for the link and image. While it's still possible to copy this selected
text using the Menu Bar (Edit > Copy), this should be reflected in the context menu as well.
To fix this, we adjust a bit of macOS-specific logic in `ContextMenuController` to include the set
of text actions as well, in this scenario.
* LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy-expected.txt: Added.
* LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy.html: Added.
Add a layout test to verify the change.
* Source/WebCore/page/ContextMenuController.cpp:
(WebCore::ContextMenuController::populate):
Always show selected text options for selected Live Text. Additionally, simplify a bit of nearby
code to take advantage of "if statements with initializers".
Canonical link: https://commits.webkit.org/251157@main
Modified Paths
trunk/Source/WebCore/page/ContextMenuController.cpp
Added Paths
trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy-expected.txt
trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy.html
Diff
Added: trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy-expected.txt (0 => 295062)
--- trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy-expected.txt 2022-05-31 20:19:12 UTC (rev 295062)
@@ -0,0 +1,8 @@
+PASS getCopyContextMenuItem() is null
+PASS Selected text in image
+PASS getCopyContextMenuItem() is non-null.
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
+
Added: trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy.html (0 => 295062)
--- trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy.html (rev 0)
+++ trunk/LayoutTests/fast/images/text-recognition/mac/context-menu-for-image-in-link-contains-copy.html 2022-05-31 20:19:12 UTC (rev 295062)
@@ -0,0 +1,67 @@
+
+
+
+
+img {
+width: 400px;
+height: 400px;
+}
+
+div[contenteditable] {
+border: 1px solid tomato;
+}
+
+a {
+display: block;
+position: absolute;
+top: 0;
+left: 0;
+}
+
+
+
+
+
+