[webkit-changes] [238050] trunk
Title: [238050] trunk Revision 238050 Author wenson_hs...@apple.com Date 2018-11-09 12:16:32 -0800 (Fri, 09 Nov 2018) Log Message [Cocoa] Introduce WKWebView SPI to insert nested ordered and unordered lists https://bugs.webkit.org/show_bug.cgi?id=191410 Reviewed by Dean Jackson. Source/WebKit: Prefixes a few iOS-only SPI methods declared on WKWebView in r236867 with underscores, and also exposes some more cross-platform Cocoa editing SPI. Once the unprefixed SPI methods are no longer used by internal clients, these will need to be removed (see followup bug: webkit.org/b/191450). See below for more details. Covered by new and existing API tests in WKWebViewEditActions. * UIProcess/API/Cocoa/WKWebView.mm: Hoist the definition (and undefinition) of `FORWARD_ACTION_TO_WKCONTENTVIEW` to encompass both the WKWebView implementation and the WKWebView (WKPrivate) implementation. This allows us to use this macro when implementing SPI methods in the WKPrivate category, as well as methods that are part of the main WKWebView implementation. (-[WKWebView canPerformAction:withSender:]): (-[WKWebView targetForAction:withSender:]): Add forwarding for the new editing commands in -canPerformAction: and -targetForAction:. (-[WKWebView _toggleStrikeThrough:]): (-[WKWebView _increaseListLevel:]): (-[WKWebView _decreaseListLevel:]): (-[WKWebView _changeListType:]): (-[WKWebView _setFont:sender:]): (-[WKWebView _setFontSize:sender:]): (-[WKWebView _setTextColor:sender:]): Add definitions for the new editing methods on WKWebView, using macros (`WEBCORE_PRIVATE_COMMAND` on macOS and `FORWARD_ACTION_TO_WKCONTENTVIEW` on iOS) to help reduce the code duplication. (-[WKWebView _pasteAsQuotation:]): Deleted. Remove this method definition, which is now replaced by macros on iOS and macOS. * UIProcess/API/Cocoa/WKWebViewPrivate.h: Introduce the new SPI to WKWebView (WKPrivate), and add FIXMEs to remove old, unprefixed variants of the SPI. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::increaseListLevel): (WebKit::WebPageProxy::decreaseListLevel): (WebKit::WebPageProxy::changeListType): Add plumbing for these list editing commands. * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _increaseListLevelForWebView:]): (-[WKContentView _decreaseListLevelForWebView:]): (-[WKContentView _changeListTypeForWebView:]): (-[WKContentView _toggleStrikeThroughForWebView:]): (-[WKContentView _setFontForWebView:sender:]): (-[WKContentView _setFontSizeForWebView:sender:]): (-[WKContentView _setTextColorForWebView:sender:]): (-[WKContentView toggleStrikeThroughForWebView:]): (-[WKContentView setFontForWebView:sender:]): (-[WKContentView setFontSizeForWebView:sender:]): (-[WKContentView setTextColorForWebView:sender:]): (-[WKContentView canPerformActionForWebView:withSender:]): Check for the new action selectors here, and additionally add validation for `_pasteAsQuotation:`. Let the unprefixed versions of these methods simply call the prefixed versions (these method implementations will be removed in a followup once doing so would not affect any clients of WebKit). * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::increaseListLevel): (WebKit::WebPage::decreaseListLevel): (WebKit::WebPage::changeListType): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Add stubs for several list editing commands that are yet to be hooked up to WebCore. These will be implemented in a future patch. Tools: Move WKWebViewEditActions from iOS to WebKitCocoa, and enable the relevant WKWebViewEditActions tests on macOS. Additionally, add new API tests to verify that `-_pasteAsQuotation:` and `-_insertNested(Un)OrderedList:` are hooked up to their respective editing commands. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm: Renamed from Tools/TestWebKitAPI/Tests/ios/WKWebViewEditActions.mm. (-[TestWKWebView querySelectorExists:]): (-[TestWKWebView insertString:]): Add a helper method to insert a piece of text. This abstracts platform differences between iOS and macOS, by invoking the WKWebView directly on macOS and calling on the content view on iOS. (TestWebKitAPI::webViewForEditActionTesting): (TestWebKitAPI::TEST): Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
[webkit-changes] [238080] trunk
Title: [238080] trunk Revision 238080 Author wenson_hs...@apple.com Date 2018-11-11 17:39:27 -0800 (Sun, 11 Nov 2018) Log Message Implement a new edit command to change the enclosing list type https://bugs.webkit.org/show_bug.cgi?id=191487 Reviewed by Ryosuke Niwa. Source/WebCore: Add support for a new edit command that changes the type of the enclosing list element around the selection from unordered to ordered list and vice versa. This new edit command is exposed only to internal WebKit2 clients, via SPI on WKWebView (`-_changeListType:`). This is currently intended for use in Mail compose, but may also be adopted by legacy Notes in the future. As such, the behavior of this editing command mostly matches shipping behavior in Mail compose (which is currently implemented entirely by Mail). See below for more details. Test: editing/execCommand/change-list-type.html WKWebViewEditActions.ChangeListType * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * editing/ChangeListTypeCommand.cpp: Added. (WebCore::listConversionTypeForSelection): (WebCore::ChangeListTypeCommand::listConversionType): Helper that returns a potential list conversion command that may be executed at the given document's selection, if any exists. We also use existing logic from Mail here to determine which list to change, by walking up the DOM from the lowest common ancestor container of the current selection until we hit the first list element. (WebCore::ChangeListTypeCommand::createNewList): Helper method to create a new list element to replace the given list, and then clone element data from the given list to the new list. This addresses an existing bug in Mail, wherein changing list type for an enclosing list which contains inline style properties drops the inline styles, because existing logic in Mail that implements this editing command only copies the `class` attribute of the old list to the new list. (WebCore::ChangeListTypeCommand::doApply): Apply the edit command by running the following steps: - Find the enclosing list element, if any (see above). - Create a new list element of the opposite type as the enclosing list, and clone over element data from the list element being replaced. - Insert the new list next to the original list. - Move all children of the original list to the new list. - Remove the original list. - Set the selection to the end of the new list. * editing/ChangeListTypeCommand.h: Added. * editing/EditAction.h: Add a pair of new edit actions for conversion from unordered list to ordered list and vice versa. * editing/Editor.cpp: (WebCore::Editor::changeSelectionListType): Implement this by creating and applying a new ChangeListTypeCommand. (WebCore::Editor::canChangeSelectionListType): Deleted. Remove this for now, since there's no need for it until full support for edit command validation is implemented. * editing/Editor.h: * testing/Internals.cpp: (WebCore::Internals::changeSelectionListType): * testing/Internals.h: * testing/Internals.idl: Add internal hooks to change list type from layout tests. Source/WebKit: * UIProcess/WebEditCommandProxy.cpp: (WebKit::WebEditCommandProxy::nameForEditAction): Add undo/redo edit action strings for ConvertToOrderedList and ConvertToUnorderedList. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::increaseListLevel): (WebKit::WebPage::decreaseListLevel): (WebKit::WebPage::changeListType): Remove preflight checks for these list editing commands. These are not necessary because these commands fall back to being noops if these checks return false. This avoids an extraneous ancestor walk to determine the enclosing list element when changing list type. Source/WebKitLegacy/mac: Add undo/redo edit action strings for ConvertToOrderedList and ConvertToUnorderedList. * WebCoreSupport/WebEditorClient.mm: (undoNameForEditAction): Tools: Add a new API test to verify that `-[WKWebView _changeListType:]` is hooked up to the corresponding editing command in WebCore. See the new layout test for a test that exercises more nuanced corner cases. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm: (-[TestWKWebView setPosition:offset:]): (-[TestWKWebView setBase:baseOffset:extent:extentOffset:]): (TestWebKitAPI::webViewForEditActionTestingWithPageNamed): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/editable-nested-lists.html: Added. LayoutTests: Add a new layout test to verify that the list change type editing command can be used to swap between enclosing ordered and unordered lists. Also exercises undo, redo, changing list types under `pre` and `table` elements, and handling selection within nested list elements. * editing/execCommand/change-list-type-expected.txt: Added. * editing/execCommand/change-list-type.html: Added. Modified Paths trunk/LayoutTests/ChangeLog trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Sources.txt
[webkit-changes] [238146] trunk
Title: [238146] trunk Revision 238146 Author wenson_hs...@apple.com Date 2018-11-13 14:30:27 -0800 (Tue, 13 Nov 2018) Log Message [iOS] Do not show selection UI for editable elements with opacity near zero https://bugs.webkit.org/show_bug.cgi?id=191442 Reviewed by Simon Fraser. Source/WebCore: Tests: editing/selection/ios/do-not-zoom-to-focused-hidden-contenteditable.html editing/selection/ios/hide-selection-after-hiding-contenteditable.html editing/selection/ios/hide-selection-in-contenteditable-nested-transparency.html editing/selection/ios/hide-selection-in-hidden-contenteditable-frame.html editing/selection/ios/hide-selection-in-hidden-contenteditable.html * rendering/RenderObject.cpp: (WebCore::RenderObject::isTransparentRespectingParentFrames const): Add a helper function to determine whether a RenderObject is contained within a transparent layer, taking parent frames into account. A layer is considered transparent if its opacity is less than a small threshold (i.e. 0.01). Opacity on ancestor elements is applied multiplicatively. * rendering/RenderObject.h: Source/WebKit: Add support for suppressing native selection UI (for instance, selection highlight views, selection handles, and selection-related gestures) when the selection is inside a transparent editable element. This helps maintain compatibility with text editors that work by capturing key events and input events hidden contenteditable elements, and reflect these changes in different document or different part of the document. Since selection UI is rendered in the UI process on iOS using element geometry propagated from the web process, selection rendering is entirely decoupled from the process of painting in the web process. This means that if the editable root has an opacity of 0, we would correctly hide the caret and selection on macOS, but draw over the transparent element on iOS. When these hidden editable elements are focused, this often results in unwanted behaviors, such as double caret painting, native and custom selection UI from the page being drawn on top of one another, and the ability to change selection via tap and loupe gestures within hidden text. To fix this, we compute whether the focused element is transparent when an element is focused, or when the selection changes, and send this information over to the UI process via `AssistedNodeInformation` and `EditorState`. In the UI process, we then respect this information by suppressing the selection assistant if the focused element is transparent; this disables showing and laying out selection views, as well as gestures associated with selection overlays. However, this still allows for contextual autocorrection and spell checking. * Shared/AssistedNodeInformation.cpp: (WebKit::AssistedNodeInformation::encode const): (WebKit::AssistedNodeInformation::decode): * Shared/AssistedNodeInformation.h: * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): * Shared/EditorState.h: Add `elementIsTransparent` flags, and also add boilerplate IPC code. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _displayFormNodeInputView]): Prevent zooming to the focused element if the focused element is hidden. (-[WKContentView hasSelectablePositionAtPoint:]): (-[WKContentView pointIsNearMarkedText:]): (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): Don't allow these text interaction gestures to begin while suppressing the selection assistant. (-[WKContentView _startAssistingNode:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): When an element is focused, begin suppressing the selection assistant if the element is fully transparent. (-[WKContentView _stopAssistingNode]): When the focused element is blurred, reset state by ending selection assistant suppression (additionally reactivating the selection assistant if needed). This ensures that selection in non-editable text isn't broken after focusing a hidden editable element. (-[WKContentView _updateChangedSelection:]): If needed, suppress or un-suppress the selection assistant when the selection changes. On certain rich text editors, a combination of custom selection UI and native selection UI is used. For instance, on Microsoft Office 365, caret selections are rendered using the native caret view, but as soon as the selection becomes ranged, the editable root becomes fully transparent, and Office's selection UI takes over. (-[WKContentView _shouldSuppressSelectionCommands]): Override this UIKit SPI hook to suppress selection commands (e.g. the callout bar) when suppressing the selection assistant. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): (WebKit::WebPage::getAssistedNodeInformation): Compute and set `elementIsTransparent` using the assisted node. Tools: Add a couple of new testing helpers to UIScriptController. *
[webkit-changes] [237842] trunk
Title: [237842] trunk Revision 237842 Author wenson_hs...@apple.com Date 2018-11-05 20:07:36 -0800 (Mon, 05 Nov 2018) Log Message [iOS] Swatch appears squished and off-center in inputs of type color https://bugs.webkit.org/show_bug.cgi?id=191279 Reviewed by Tim Horton. Source/WebCore: This patch makes some small adjustments to color inputs on iOS to bring them closer to the intended design. See comments below for more details. Tests: fast/forms/color/color-input-uses-color-well-appearance.html fast/forms/color/input-appearance-color.html * css/html.css: Adjust the UA stylesheet for color inputs on iOS. * rendering/RenderTheme.cpp: (WebCore::RenderTheme::paintDecorations): When painting decorations for `ColorWellPart`, treat it as a standard button instead of the square button appearance. (WebCore::RenderTheme::colorInputStyleSheet const): Add `-webkit-appearance: color-well;` to the stylesheet for color inputs. Previously, this was special-cased on iOS, where color input elements had appearances of `textfield`; however, this patch makes some adjustments to RenderThemeIOS, allowing us to use `color-well` on iOS. * rendering/RenderTheme.h: (WebCore::RenderTheme::platformUsesColorWellAppearance const): Deleted. Remove this from RenderTheme. This is no longer necessary, since all platforms now use `-webkit-appearance: color-well;`. * rendering/RenderThemeIOS.h: * rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::adjustButtonStyle const): When painting buttons for color inputs, don't add rounded corners that are present by default for regular buttons. LayoutTests: * fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html: Added. * fast/forms/color/color-input-uses-color-well-appearance.html: Added. Add a test to verify that setting `-webkit-appearance: textfield;` on a color input causes the color input to render differently from a color input with a default appearance. * platform/ios-wk1/TestExpectations: * platform/ios/TestExpectations: In the WebKit2 port of iOS, enable a handful of color input tests that are currently disabled. * platform/ios/fast/forms/color/input-appearance-color-expected.txt: Rebaseline an existing test on iOS. Modified Paths trunk/LayoutTests/ChangeLog trunk/LayoutTests/platform/ios/TestExpectations trunk/LayoutTests/platform/ios/fast/forms/color/input-appearance-color-expected.txt trunk/LayoutTests/platform/ios-wk1/TestExpectations trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/css/html.css trunk/Source/WebCore/rendering/RenderTheme.cpp trunk/Source/WebCore/rendering/RenderTheme.h trunk/Source/WebCore/rendering/RenderThemeIOS.h trunk/Source/WebCore/rendering/RenderThemeIOS.mm Added Paths trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance.html Diff Modified: trunk/LayoutTests/ChangeLog (237841 => 237842) --- trunk/LayoutTests/ChangeLog 2018-11-06 02:30:47 UTC (rev 237841) +++ trunk/LayoutTests/ChangeLog 2018-11-06 04:07:36 UTC (rev 237842) @@ -1,3 +1,26 @@ +2018-11-05 Wenson Hsieh + +[iOS] Swatch appears squished and off-center in inputs of type color +https://bugs.webkit.org/show_bug.cgi?id=191279 + + +Reviewed by Tim Horton. + +* fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html: Added. +* fast/forms/color/color-input-uses-color-well-appearance.html: Added. + +Add a test to verify that setting `-webkit-appearance: textfield;` on a color input causes the color input to +render differently from a color input with a default appearance. + +* platform/ios-wk1/TestExpectations: +* platform/ios/TestExpectations: + +In the WebKit2 port of iOS, enable a handful of color input tests that are currently disabled. + +* platform/ios/fast/forms/color/input-appearance-color-expected.txt: + +Rebaseline an existing test on iOS. + 2018-11-05 Eric Carlson [MediaStream] An audio track should be muted when capture is interrupted by the OS. Added: trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html (0 => 237842) --- trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html (rev 0) +++ trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance-expected-mismatch.html 2018-11-06 04:07:36 UTC (rev 237842) @@ -0,0 +1 @@ + Added: trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance.html (0 => 237842) --- trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance.html (rev 0) +++ trunk/LayoutTests/fast/forms/color/color-input-uses-color-well-appearance.html 2018-11-06 04:07:36 UTC (rev 237842) @@ -0,0 +1 @@ + Modified: trunk/LayoutTests/platform/ios/TestExpectations (237841 =>
[webkit-changes] [238020] trunk/Source/WebKit
Title: [238020] trunk/Source/WebKit Revision 238020 Author wenson_hs...@apple.com Date 2018-11-08 22:49:35 -0800 (Thu, 08 Nov 2018) Log Message Unreviewed, try to fix the 32-bit macOS build * WebProcess/Plugins/PDF/PDFPlugin.mm: (WebKit::PDFPlugin::showDefinitionForAttributedString): Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm Diff Modified: trunk/Source/WebKit/ChangeLog (238019 => 238020) --- trunk/Source/WebKit/ChangeLog 2018-11-09 06:48:49 UTC (rev 238019) +++ trunk/Source/WebKit/ChangeLog 2018-11-09 06:49:35 UTC (rev 238020) @@ -1,3 +1,10 @@ +2018-11-08 Wenson Hsieh + +Unreviewed, try to fix the 32-bit macOS build + +* WebProcess/Plugins/PDF/PDFPlugin.mm: +(WebKit::PDFPlugin::showDefinitionForAttributedString): + 2018-11-08 Said Abou-Hallawa Add an SPI to allow WebView clients to add additional supported image formats Modified: trunk/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm (238019 => 238020) --- trunk/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm 2018-11-09 06:48:49 UTC (rev 238019) +++ trunk/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm 2018-11-09 06:49:35 UTC (rev 238020) @@ -1875,7 +1875,7 @@ NSRect rangeRect; -rangeRect.origin = point; +rangeRect.origin = NSMakePoint(point.x, point.y); CGFloat scaleFactor = PDFPlugin::scaleFactor(); rangeRect.size.height = string.size.height * scaleFactor; ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238188] trunk
Title: [238188] trunk Revision 238188 Author wenson_hs...@apple.com Date 2018-11-14 11:27:29 -0800 (Wed, 14 Nov 2018) Log Message [iOS] A few drag and drop tests are crashing after r238146 https://bugs.webkit.org/show_bug.cgi?id=191617 Reviewed by Dean Jackson. Source/WebKit: The notion of temporarily suppressing the selection assistant was introduced during iOS drag and drop development as a way of allowing both the selection view and dropped content snapshot to fade in simultaneously during a drop in an editable element. r238146 piggy-backs on this mechanism by changing selection suppression state when an element is focused, when the selection changes, and when an element is blurred, depending on whether the currently focused element is transparent. However, in the case where the selection assistant is suppressed due to a running drop animation, if focus moves to an element that is not fully transparent, we end up prematurely unsuppressing the text selection assistant. This subsequently causes selection UI to immediately show up after a drop instead of animating in alongside a snapshot of the inserted document fragment, if the drop moved focus to an editable element. A number of drag and drop tests on iOS exercised this codepath by dragging content into editable fields and/or moving content between editable elements in a web view. These tests began to crash due to selection views and the accompanying callout bar appearing earlier than usual, which triggers an unrelated UIKit assertion in . This patch fixes the failing tests by refactoring our selection assistant suppression code. Instead of maintaining a single `BOOL` flag indicating whether the selection is suppressed, we use an `OptionSet` of `SuppressSelectionAssistantReason`s, which (at the moment) only include (1) a running drop animation, and (2) focusing a transparent element. The text selection assistant is considered suppressed when either of the reasons apply. This allows us to correctly handle a drop animation that occurs simultaneously as an element is focused without unsuppressing the selection assistant early, and also allows us to handle selection assistant suppression in more nuanced ways, depending on the suppression reason. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView cleanupInteraction]): (-[WKContentView _displayFormNodeInputView]): Only prevent zooming to the focused element during drop if we're suppressing the selection assistant due to focusing a transparent element. In the case of a drop, we still want to allow scrolling and zooming. (-[WKContentView canShowNonEmptySelectionView]): (-[WKContentView hasSelectablePositionAtPoint:]): (-[WKContentView pointIsNearMarkedText:]): (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): (-[WKContentView _startAssistingKeyboard]): (-[WKContentView _startAssistingNode:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): (-[WKContentView _stopAssistingNode]): (-[WKContentView _updateChangedSelection:]): (-[WKContentView _shouldSuppressSelectionCommands]): (-[WKContentView _beginSuppressingSelectionAssistantForReason:]): (-[WKContentView _stopSuppressingSelectionAssistantForReason:]): Add helper methods for adding or removing selection assistant suppression reasons. When the last selection assistant suppression reason is removed, we activate the selection assistant, and conversely, when the first suppression reason is added, we deactivate the selection assistant. (-[WKContentView _didConcludeEditDataInteraction:]): (-[WKContentView _didPerformDragOperation:]): (-[WKContentView dropInteraction:performDrop:]): (-[WKContentView suppressAssistantSelectionView]): Deleted. (-[WKContentView setSuppressAssistantSelectionView:]): Deleted. Tools: Augment these crashing tests to verify that selection commands are suppressed during drop over editable elements via more robust means. These tests currently hit an assertion when revealing the callout bar too early, because TestWebKitAPI is not a UI application (see ). Instead of relying on this other bug, directly ask the text input whether it is suppressing selection commands during a drop, and remember the answer via DragAndDropSimulator. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (TestWebKitAPI::TEST): Add to the existing tests that started failing after r238146. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/cocoa/TestWKWebView.mm: (-[TestWKWebView textInputContentView]): * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm: (-[DragAndDropSimulator _resetSimulatedState]): (-[DragAndDropSimulator _webView:dataInteractionOperationWasHandled:forSession:itemProviders:]): * TestWebKitAPI/ios/UIKitSPI.h: Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Tools/ChangeLog
[webkit-changes] [238186] trunk
Title: [238186] trunk Revision 238186 Author wenson_hs...@apple.com Date 2018-11-14 11:00:04 -0800 (Wed, 14 Nov 2018) Log Message Source/WebKit: [Cocoa] [WebKit2] Hook up some more editing actions (-_pasteAndMatchStyle:, -makeTextWritingDirectionNatural:) https://bugs.webkit.org/show_bug.cgi?id=191605 Reviewed by Dean Jackson. Hook up a couple of editing actions on iOS and macOS. The `-pasteAndMatchStyle:` selector is privately declared in UIKit, but does not exist on macOS; as such, add `-_pasteAndMatchStyle:` as SPI on WKWebView, and additionally implement the unprefixed version, `-pasteAndMatchStyle:`, on iOS. Since `-makeTextWritingDirectionNatural:` is already declared on both iOS and macOS (SPI on UIResponder and API on macOS, respectively) we simply implement the unprefixed variant on both platforms. * Platform/spi/ios/UIKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView makeTextWritingDirectionNaturalForWebView:]): (-[WKContentView canPerformActionForWebView:withSender:]): Tools: [Cocoa] [WebKit2] Hook up some more editing actions (-pasteAndMatchStyle:, -makeTextWritingDirectionNatural:) https://bugs.webkit.org/show_bug.cgi?id=191605 Reviewed by Dean Jackson. Adds two new API tests to exercise -_pasteAndMatchStyle: and -makeTextWritingDirectionNatural:. * TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm: (-[TestWKWebView _synchronouslyExecuteEditCommand:argument:]): Deleted. * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/cocoa/TestWKWebView.mm: Pull `-_synchronouslyExecuteEditCommand:argument:` out of WKAttachmentTests and into shared code, in a new category on WKWebView declared in TestWKWebView. Also, fix an unrelated typo in a nearby category. (-[WKWebView _synchronouslyExecuteEditCommand:argument:]): * TestWebKitAPI/ios/UIKitSPI.h: Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.h trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h Diff Modified: trunk/Source/WebKit/ChangeLog (238185 => 238186) --- trunk/Source/WebKit/ChangeLog 2018-11-14 18:49:22 UTC (rev 238185) +++ trunk/Source/WebKit/ChangeLog 2018-11-14 19:00:04 UTC (rev 238186) @@ -1,3 +1,26 @@ +2018-11-14 Wenson Hsieh + +[Cocoa] [WebKit2] Hook up some more editing actions (-_pasteAndMatchStyle:, -makeTextWritingDirectionNatural:) +https://bugs.webkit.org/show_bug.cgi?id=191605 + + +Reviewed by Dean Jackson. + +Hook up a couple of editing actions on iOS and macOS. The `-pasteAndMatchStyle:` selector is privately declared +in UIKit, but does not exist on macOS; as such, add `-_pasteAndMatchStyle:` as SPI on WKWebView, and +additionally implement the unprefixed version, `-pasteAndMatchStyle:`, on iOS. + +Since `-makeTextWritingDirectionNatural:` is already declared on both iOS and macOS (SPI on UIResponder and API +on macOS, respectively) we simply implement the unprefixed variant on both platforms. + +* Platform/spi/ios/UIKitSPI.h: +* UIProcess/API/Cocoa/WKWebView.mm: +* UIProcess/API/Cocoa/WKWebViewPrivate.h: +* UIProcess/ios/WKContentViewInteraction.h: +* UIProcess/ios/WKContentViewInteraction.mm: +(-[WKContentView makeTextWritingDirectionNaturalForWebView:]): +(-[WKContentView canPerformActionForWebView:withSender:]): + 2018-11-14 Per Arne Vollan REGRESSION (WEBPROCESS_WINDOWSERVER_BLOCKING): requestAnimationFrame Stops Completing Modified: trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h (238185 => 238186) --- trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2018-11-14 18:49:22 UTC (rev 238185) +++ trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2018-11-14 19:00:04 UTC (rev 238186) @@ -1078,6 +1078,8 @@ @interface UIResponder () - (UIResponder *)firstResponder; +- (void)pasteAndMatchStyle:(id)sender; +- (void)makeTextWritingDirectionNatural:(id)sender; @end @interface _UINavigationInteractiveTransitionBase () Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm (238185 => 238186) --- trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2018-11-14 18:49:22 UTC (rev 238185) +++ trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2018-11-14 19:00:04 UTC (rev 238186) @@ -4331,7 +4331,8 @@
[webkit-changes] [237786] trunk/Tools
Title: [237786] trunk/Tools Revision 237786 Author wenson_hs...@apple.com Date 2018-11-04 13:19:44 -0800 (Sun, 04 Nov 2018) Log Message [Cocoa] Fold common UIScriptController functionality on macOS and iOS into UIScriptControllerCocoa.mm https://bugs.webkit.org/show_bug.cgi?id=191231 Reviewed by Simon Fraser. Moves some UIScriptController method implementations specific to iOS and macOS into UIScriptControllerCocoa, so it can be shared between iOS-family and macOS platforms. See below for more details. No change in behavior. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::overridePreference): Add a method stub for DumpRenderTree. * TestRunnerShared/UIScriptContext/UIScriptController.cpp: * WebKitTestRunner/UIScriptControllerCocoa.mm: (WTR::UIScriptController::doAsyncTask): (WTR::UIScriptController::setShareSheetCompletesImmediatelyWithResolution): Unify these method implementations. (WTR::UIScriptController::removeViewFromWindow): (WTR::UIScriptController::addViewToWindow): Move the macOS implementation to UIScriptControllerCocoa. On iOS, this method currently only adds the web view to the window, and does not attempt to invoke the given completion block; additionally, invoking the completion block after a presentation update (as done on macOS) causes pageoverlay/overlay-remove-reinsert-view.html to begin failing consistently. This patch does not attempt to change behavior, but adds a FIXME describing this. (WTR::UIScriptController::overridePreference): (WTR::UIScriptController::findString): (WTR::UIScriptController::contentsOfUserInterfaceItem const): Move these from UIScriptControllerMac to UIScriptControllerCocoa, so that it is now implemented on iOS as well. * WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::doAsyncTask): Deleted. (WTR::UIScriptController::setShareSheetCompletesImmediatelyWithResolution): Deleted. (WTR::UIScriptController::contentsOfUserInterfaceItem const): Deleted. (WTR::UIScriptController::findString): Deleted. (WTR::UIScriptController::removeViewFromWindow): Deleted. (WTR::UIScriptController::addViewToWindow): Deleted. * WebKitTestRunner/mac/UIScriptControllerMac.mm: (WTR::UIScriptController::doAsyncTask): Deleted. (WTR::UIScriptController::contentsOfUserInterfaceItem const): Deleted. (WTR::UIScriptController::overridePreference): Deleted. (WTR::UIScriptController::findString): Deleted. (WTR::UIScriptController::removeViewFromWindow): Deleted. (WTR::UIScriptController::addViewToWindow): Deleted. (WTR::UIScriptController::setShareSheetCompletesImmediatelyWithResolution): Deleted. Modified Paths trunk/Tools/ChangeLog trunk/Tools/DumpRenderTree/ios/UIScriptControllerIOS.mm trunk/Tools/TestRunnerShared/UIScriptContext/UIScriptController.cpp trunk/Tools/WebKitTestRunner/UIScriptControllerCocoa.mm trunk/Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm trunk/Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm Diff Modified: trunk/Tools/ChangeLog (237785 => 237786) --- trunk/Tools/ChangeLog 2018-11-04 16:38:36 UTC (rev 237785) +++ trunk/Tools/ChangeLog 2018-11-04 21:19:44 UTC (rev 237786) @@ -1,3 +1,57 @@ +2018-11-04 Wenson Hsieh + +[Cocoa] Fold common UIScriptController functionality on macOS and iOS into UIScriptControllerCocoa.mm +https://bugs.webkit.org/show_bug.cgi?id=191231 + +Reviewed by Simon Fraser. + +Moves some UIScriptController method implementations specific to iOS and macOS into UIScriptControllerCocoa, so +it can be shared between iOS-family and macOS platforms. See below for more details. + +No change in behavior. + +* DumpRenderTree/ios/UIScriptControllerIOS.mm: +(WTR::UIScriptController::overridePreference): + +Add a method stub for DumpRenderTree. + +* TestRunnerShared/UIScriptContext/UIScriptController.cpp: +* WebKitTestRunner/UIScriptControllerCocoa.mm: +(WTR::UIScriptController::doAsyncTask): +(WTR::UIScriptController::setShareSheetCompletesImmediatelyWithResolution): + +Unify these method implementations. + +(WTR::UIScriptController::removeViewFromWindow): +(WTR::UIScriptController::addViewToWindow): + +Move the macOS implementation to UIScriptControllerCocoa. On iOS, this method currently only adds the web view +to the window, and does not attempt to invoke the given completion block; additionally, invoking the completion +block after a presentation update (as done on macOS) causes pageoverlay/overlay-remove-reinsert-view.html to +begin failing consistently. This patch does not attempt to change behavior, but adds a FIXME describing this. + +(WTR::UIScriptController::overridePreference): +(WTR::UIScriptController::findString): +(WTR::UIScriptController::contentsOfUserInterfaceItem const): + +Move these from UIScriptControllerMac to UIScriptControllerCocoa, so that it is now implemented on iOS
[webkit-changes] [236854] trunk
Title: [236854] trunk
Revision 236854
Author wenson_hs...@apple.com
Date 2018-10-04 15:08:51 -0700 (Thu, 04 Oct 2018)
Log Message
[macOS] Fix some font attribute conversion bugs in preparation for "Font > Styles…" support in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=190289
Reviewed by Ryosuke Niwa.
Source/WebCore:
Makes some small adjustments to fix two bugs in font attribute conversion logic. See below for more detail.
Tests: FontManagerTests.AddFontShadowUsingFontOptions
FontManagerTests.AddAndRemoveColorsUsingFontOptions
* editing/FontAttributeChanges.cpp:
(WebCore::cssValueListForShadow):
* editing/cocoa/FontAttributesCocoa.mm:
Currently, we bail from adding a font shadow if the shadow's offset is empty. However, valid shadow offsets may
have negative dimensions, so a check for `isZero()` should be used instead.
(WebCore::FontAttributes::createDictionary const):
* platform/mac/WebCoreNSFontManagerExtras.mm:
Fall back to a transparent background color; this allows senders to remove the current background color by just
removing NSBackgroundColorAttributeName from the attribute dictionary, rather than explicitly setting it to the
transparent color (this scenario is exercised when using "Font > Styles…" to specify a font style without a
background color).
(WebCore::computedFontAttributeChanges):
Tools:
Add new API tests to exercise two corner cases when using NSFontOptions ("Font > Styles…") to change font
attributes at the current selection.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/TestWebKitAPI/mac/AppKitSPI.h:
* TestWebKitAPI/Tests/mac/FontManagerTests.mm:
(webViewForFontManagerTesting):
(TestWebKitAPI::TEST):
* TestWebKitAPI/mac/TestFontOptions.h: Copied from Source/WebCore/editing/cocoa/FontAttributesCocoa.mm.
* TestWebKitAPI/mac/TestFontOptions.mm: Added.
Introduce TestFontOptions, which wraps the shared NSFontOptions and swizzles `-sharedFontOptions` to return a
global instance of itself. TestFontOptions supports several testing helpers to add or remove font shadows,
foreground colors, and background colors.
(sharedFontOptionsForTesting):
(+[TestFontOptions sharedInstance]):
(-[TestFontOptions initWithFontOptions:]):
(-[TestFontOptions selectedAttributes]):
(-[TestFontOptions fontOptions]):
(-[TestFontOptions shadowWidth]):
(-[TestFontOptions setShadowWidth:]):
(-[TestFontOptions shadowHeight]):
(-[TestFontOptions setShadowHeight:]):
(-[TestFontOptions setShadowBlurRadius:]):
(-[TestFontOptions setHasShadow:]):
(-[TestFontOptions foregroundColor]):
(-[TestFontOptions setForegroundColor:]):
(-[TestFontOptions backgroundColor]):
(-[TestFontOptions setBackgroundColor:]):
(-[TestFontOptions _dispatchFontAttributeChanges]):
(-[TestFontOptions convertAttributes:]):
(-[TestFontOptions setSelectedAttributes:isMultiple:]):
(-[TestFontOptions forwardInvocation:]):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/editing/FontAttributeChanges.cpp
trunk/Source/WebCore/editing/cocoa/FontAttributesCocoa.mm
trunk/Source/WebCore/platform/mac/WebCoreNSFontManagerExtras.mm
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
trunk/Tools/TestWebKitAPI/Tests/TestWebKitAPI/mac/AppKitSPI.h
trunk/Tools/TestWebKitAPI/Tests/mac/FontManagerTests.mm
Added Paths
trunk/Tools/TestWebKitAPI/mac/TestFontOptions.h
trunk/Tools/TestWebKitAPI/mac/TestFontOptions.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (236853 => 236854)
--- trunk/Source/WebCore/ChangeLog 2018-10-04 21:54:14 UTC (rev 236853)
+++ trunk/Source/WebCore/ChangeLog 2018-10-04 22:08:51 UTC (rev 236854)
@@ -1,3 +1,33 @@
+2018-10-04 Wenson Hsieh
+
+[macOS] Fix some font attribute conversion bugs in preparation for "Font > Styles…" support in WebKit2
+https://bugs.webkit.org/show_bug.cgi?id=190289
+
+
+Reviewed by Ryosuke Niwa.
+
+Makes some small adjustments to fix two bugs in font attribute conversion logic. See below for more detail.
+
+Tests: FontManagerTests.AddFontShadowUsingFontOptions
+FontManagerTests.AddAndRemoveColorsUsingFontOptions
+
+* editing/FontAttributeChanges.cpp:
+(WebCore::cssValueListForShadow):
+* editing/cocoa/FontAttributesCocoa.mm:
+
+Currently, we bail from adding a font shadow if the shadow's offset is empty. However, valid shadow offsets may
+have negative dimensions, so a check for `isZero()` should be used instead.
+
+(WebCore::FontAttributes::createDictionary const):
+* platform/mac/WebCoreNSFontManagerExtras.mm:
+
+Fall back to a transparent background color; this allows senders to remove the current background color by just
+removing NSBackgroundColorAttributeName from the attribute dictionary, rather than explicitly setting it to the
+transparent color (this scenario is exercised when using "Font > Styles…" to specify a font style without a
+
[webkit-changes] [236867] trunk
Title: [236867] trunk Revision 236867 Author wenson_hs...@apple.com Date 2018-10-04 20:03:21 -0700 (Thu, 04 Oct 2018) Log Message [iOS] [WK2] Expose some more editing SPI on WKWebView https://bugs.webkit.org/show_bug.cgi?id=190232 Reviewed by Tim Horton. Source/WebKit: Exposes a few additional editing commands as SPI on WKWebView, by defining a new extension on WKWebView that also conforms to . This patch implements nearly all of the remaining unimplemented methods on UIResponderStandardEditActions, and the new extension augments this set of editing methods by adding additional editing helpers that don't currently exist on iOS (e.g. toggleStrikeThrough and insertUnorderedList). The names of these new methods have been largely been borrowed from their counterparts on macOS (see: `NSResponder.h`). The new edit actions are added in this patch on iOS are: ``` - (void)alignCenter:(id)sender; - (void)alignJustified:(id)sender; - (void)alignLeft:(id)sender; - (void)alignRight:(id)sender; - (void)indent:(id)sender; - (void)insertOrderedList:(id)sender; - (void)insertUnorderedList:(id)sender; - (void)outdent:(id)sender; - (void)toggleStrikeThrough:(id)sender; - (void)setFont:(UIFont *)font sender:(id)sender; - (void)setFontSize:(CGFloat)fontSize sender:(id)sender; - (void)setTextColor:(UIColor *)color sender:(id)sender; ``` Tests: WKWebViewEditActions.ListInsertion WKWebViewEditActions.ChangeIndentation WKWebViewEditActions.SetAlignment WKWebViewEditActions.ToggleStrikeThrough WKWebViewEditActions.ChangeFontSize WKWebViewEditActions.SetTextColor WKWebViewEditActions.SetFontFamily * Platform/spi/ios/UIKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView canPerformAction:withSender:]): Update this to handle the new editing actions. For now, we simply treat all of the new edit actions in the same way as we currently treat bold, italic and underline: that is, they are enabled only when the user is in a richly contenteditable element. (-[WKWebView setFont:sender:]): (-[WKWebView setFontSize:sender:]): Construct and send a set of FontChanges. (-[WKWebView setTextColor:sender:]): Invoke "ForeColor" with the serialized color representation. This allows us to handle `rgba()` color values, which hex format would not permit. * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add the new SPI. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::changeFontAttributes): (WebKit::WebPageProxy::changeFont): Pull logic for applying font and font attribute style changes out of macOS-specific code, and into platform-agnostic code in WebPage and WebPageProxy. * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentViewInteraction.h: Add the new supported editing commands as supported actions in WKWebView. The only new editing commands that aren't present in this list are -setFont:sender:, -setColor:sender:, and -setFontSize:sender: which are manually handled in places where the `FOR_EACH_WKCONTENTVIEW_ACTION` macro is otherwise used. In a followup, we could consider augmenting `FOR_EACH_WKCONTENTVIEW_ACTION` to handle actions with multiple arguments. * UIProcess/ios/WKContentViewInteraction.mm: Define a new helper macro here to define boilerplate implementations of the -…ForWebView edit command implementations that turn around and invoke `_page->executeEditCommand` with no additional arguments, and an edit command name matching that of the WebCore edit command. (-[WKContentView toggleStrikeThroughForWebView:]): (-[WKContentView increaseSizeForWebView:]): (-[WKContentView decreaseSizeForWebView:]): (-[WKContentView setFontForWebView:sender:]): (-[WKContentView setFontSizeForWebView:sender:]): (-[WKContentView setTextColorForWebView:sender:]): (-[WKContentView canPerformActionForWebView:sender:]): Add …ForWebView plumbing for the new editing actions, so they turn around and call into WKContentView by default, but behavior may be overridden in WKWebView. * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::changeFontAttributes): Deleted. (WebKit::WebPageProxy::changeFont): Deleted. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::changeFontAttributes): (WebKit::WebPage::changeFont): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::changeFontAttributes): Deleted. (WebKit::WebPage::changeFont): Deleted. Tools: Adds new API tests to exercise the new SPIs. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/WKWebViewEditActions.mm: Added. (-[TestWKWebView querySelectorExists:]): (TestWebKitAPI::webViewForEditActionTesting): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/mac/FontManagerTests.mm: (-[TestWKWebView collapseToStart]): Deleted. (-[TestWKWebView collapseToEnd]): Deleted. (-[TestWKWebView stylePropertyAtSelectionStart:]): Deleted. (-[TestWKWebView stylePropertyAtSelectionEnd:]): Deleted. * TestWebKitAPI/cocoa/TestWKWebView.h: *
[webkit-changes] [236865] trunk
Title: [236865] trunk Revision 236865 Author wenson_hs...@apple.com Date 2018-10-04 17:47:05 -0700 (Thu, 04 Oct 2018) Log Message [Cocoa] Add SPI to expose typing attributes at the current selection on WKWebView https://bugs.webkit.org/show_bug.cgi?id=190119 Reviewed by Tim Horton. Source/WebKit: Add support for new WebKit2 SPI to notify the UI delegate about font attributes when the editor state changes (e.g. due to selection changes, or executing an edit command). See below for more detail. Test: FontAttributes.FontAttributesAfterChangingSelection * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): * Shared/EditorState.h: Add a new optional `FontAttributes` member to EditorState's post-layout data. FontAttributes are computed and sent over IPC only if the UI delegate implements the new delegate hook which requires information about font attributes. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Add a new flag for the UI process to let a new web page know whether it should additionally compute font attributes when computing editor state. * UIProcess/API/APIUIClient.h: (API::UIClient::needsFontAttributes const): (API::UIClient::didChangeFontAttributes): * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _didChangeEditorState]): * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::setDelegate): (WebKit::UIDelegate::UIClient::didChangeFontAttributes): Call out to the UI delegate with a font attribute dictionary, created via FontAttributes on EditorState's post-layout data. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::setUIClient): Update whether or not the UI process needs to know about font attributes. The UI process only requires font attribute information if the UI delegate implements `-_webView:didChangeFontAttributes:`. (WebKit::WebPageProxy::setNeedsFontAttributes): (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::editorStateChanged): * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::editorStateChanged): Update the cached font attributes in the UI process when receiving a new editor state update. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_cpuLimit): (WebKit::WebPage::editorState const): (WebKit::WebPage::setNeedsFontAttributes): Add a new IPC hook to update whether or not the page should additionally compute font attributes. In the case where the UI delegate changes from something that does not require font attributes to one that does, we additionally schedule an editor state update. (WebKit::WebPage::updateFontAttributesAfterEditorStateChange): Private helper function to plumb FontAttributes to the UI client after an editor state change. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: Add a new API test that loads a document containing various rich text styles. This test moves the selection around the document and checks the last set of font attributes received via the new UI delegate hook. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/FontAttributes.mm: Added. (-[FontAttributesListener _webView:didChangeFontAttributes:]): (-[FontAttributesListener lastFontAttributes]): (-[TestWKWebView selectElementWithIdentifier:]): (-[TestWKWebView fontAttributesAfterNextPresentationUpdate]): (ColorExpectation::ColorExpectation): (ShadowExpectation::ShadowExpectation): (checkColor): (checkShadow): (checkFont): (webViewForTestingFontAttributes): * TestWebKitAPI/Tests/WebKitCocoa/rich-text-attributes.html: Added. Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Shared/EditorState.cpp trunk/Source/WebKit/Shared/EditorState.h trunk/Source/WebKit/Shared/WebPageCreationParameters.cpp trunk/Source/WebKit/Shared/WebPageCreationParameters.h trunk/Source/WebKit/UIProcess/API/APIUIClient.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/Cocoa/UIDelegate.h trunk/Source/WebKit/UIProcess/Cocoa/UIDelegate.mm trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm trunk/Source/WebKit/UIProcess/mac/WebPageProxyMac.mm trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj Added Paths trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/FontAttributes.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/rich-text-attributes.html Diff Modified:
[webkit-changes] [236955] trunk
Title: [236955] trunk
Revision 236955
Author wenson_hs...@apple.com
Date 2018-10-08 18:52:49 -0700 (Mon, 08 Oct 2018)
Log Message
[Cocoa] [WK2] Add support for text alignment and text lists in font attributes
https://bugs.webkit.org/show_bug.cgi?id=190342
Reviewed by Tim Horton.
Source/WebCore:
Adds support for computing and encoding information about text alignment and enclosing list elements in the font
attributes dictionary, exposed to the UI delegate on Cocoa platforms. This is exposed through NSParagraphStyle,
which contains properties for both `NSTextAlignment` and an array of enclosing `NSTextList` objects.
Test: FontAttributes.NestedTextListsWithHorizontalAlignment
FontAttributes.FontAttributesAfterChangingSelection
* editing/Editor.cpp:
(WebCore::editableTextListsAtPositionInDescendingOrder):
Add a helper function to ascend the DOM, starting at the given position, in search of enclosing list elements.
For each enclosing list element we find within the scope of the editable root, we create a `TextList`
representing the list element.
(WebCore::Editor::fontAttributesAtSelectionStart const):
Compute and set enclosing text lists and text alignment. For text alignment, we convert the initial text-align
value, `start`, to NSTextAlignmentNatural (the default text alignment type on Cocoa platforms); other values
then map to Left, Right, Center, and Justified as expected (taking direction into account).
* editing/FontAttributes.h:
(WebCore::TextList::encode const):
(WebCore::TextList::decode):
Introduce TextList, a platform-agnostic representation of an unordered or ordered list. On Cocoa, this can be
used to construct a corresponding NSTextList.
* editing/cocoa/FontAttributesCocoa.mm:
(WebCore::cocoaTextListMarkerName):
Attempt to map a WebCore list style type to a `NSTextListMarker*` constant. While most of the Cocoa marker
formats have a corresponding web-exposed list style type, many web-exposed types have no Cocoa equivalent; as
such, fall back to default marker formats: "{disc}" for unordered lists and "{decimal}" for ordered lists.
(WebCore::TextList::createTextList const):
(WebCore::FontAttributes::createDictionary const):
Include an NSParagraphStyle in the dictionary of font attributes that includes information about text alignment
and enclosing text lists (per Cocoa convention, in order from outermost list to innermost list).
Source/WebCore/PAL:
* pal/ios/UIKitSoftLink.h:
* pal/ios/UIKitSoftLink.mm:
Add NSParagraphStyle and NSTextList to the UIKit soft link header.
* pal/spi/cocoa/NSAttributedStringSPI.h:
* pal/spi/ios/UIKitSPI.h:
Add some SPI declarations for NSMutableParagraphStyle and NSTextList when building with a non-internal iOS SDK,
and import and when building with an internal iOS SDK.
Additionally, define some internal UIFoundation string constants that denote NSTextList marker formats. These
constants are API on macOS, but are neither exposed as API nor SPI on iOS.
Source/WebKit:
Add encoding and decoding for text alignment and text lists in FontAttributes.
* Shared/WebCoreArgumentCoders.cpp:
(IPC::ArgumentCoder::encode):
(IPC::ArgumentCoder::decode):
Tools:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKitCocoa/FontAttributes.mm:
Add a new API test to check that the font attributes dictionary contains the correct NSParagraphStyles when
moving the selection around text inside nested list elements.
(TestWebKitAPI::checkParagraphStyles):
Add a new helper to check an NSParagraphStyle against expected results.
(TestWebKitAPI::webViewForTestingFontAttributes):
Allow each test to pass in the name of the test page to load.
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKitCocoa/nested-lists.html: Added.
Add a new test page that contains text enclosed in multiple levels of unordered and ordered lists.
* TestWebKitAPI/Tests/WebKitCocoa/rich-text-attributes.html:
Remove `text-align: left` from one of these elements, to test for NSTextAlignmentNatural.
LayoutTests:
* editing/mac/attributed-string/attributed-string-for-typing-expected.txt:
* editing/mac/attributed-string/attributed-string-for-typing-with-color-filter-expected.txt:
* platform/mac-sierra/editing/mac/attributed-string/attributed-string-for-typing-expected.txt:
* platform/mac-sierra/editing/mac/attributed-string/attributed-string-for-typing-with-color-filter-expected.txt:
Rebaseline these two layout tests, now that typing attributes include an NSParagraphStyle.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/editing/mac/attributed-string/attributed-string-for-typing-expected.txt
trunk/LayoutTests/editing/mac/attributed-string/attributed-string-for-typing-with-color-filter-expected.txt
trunk/LayoutTests/platform/mac-sierra/editing/mac/attributed-string/attributed-string-for-typing-expected.txt
trunk/LayoutTests/platform/mac-sierra/editing/mac/attributed-string/attributed-string-for-typing-with-color-filter-expected.txt
[webkit-changes] [236951] trunk/Source/WebKit
Title: [236951] trunk/Source/WebKit Revision 236951 Author wenson_hs...@apple.com Date 2018-10-08 17:11:54 -0700 (Mon, 08 Oct 2018) Log Message Followup to r236942: Make input type=color an internal feature https://bugs.webkit.org/show_bug.cgi?id=189162 Rubber-stamped by Dean Jackson. I've learned from Dean that an internal feature is more suitable than an experimental feature in this scenario. * Shared/WebPreferences.yaml: Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Shared/WebPreferences.yaml Diff Modified: trunk/Source/WebKit/ChangeLog (236950 => 236951) --- trunk/Source/WebKit/ChangeLog 2018-10-09 00:07:24 UTC (rev 236950) +++ trunk/Source/WebKit/ChangeLog 2018-10-09 00:11:54 UTC (rev 236951) @@ -1,3 +1,14 @@ +2018-10-08 Wenson Hsieh + +Followup to r236942: Make input type=color an internal feature +https://bugs.webkit.org/show_bug.cgi?id=189162 + +Rubber-stamped by Dean Jackson. + +I've learned from Dean that an internal feature is more suitable than an experimental feature in this scenario. + +* Shared/WebPreferences.yaml: + 2018-10-08 Aditya Keerthi Make a runtime enabled (on-by-default) feature Modified: trunk/Source/WebKit/Shared/WebPreferences.yaml (236950 => 236951) --- trunk/Source/WebKit/Shared/WebPreferences.yaml 2018-10-09 00:07:24 UTC (rev 236950) +++ trunk/Source/WebKit/Shared/WebPreferences.yaml 2018-10-09 00:11:54 UTC (rev 236951) @@ -1392,6 +1392,6 @@ defaultValue: true humanReadableName: "Color Inputs" humanReadableDescription: "Enable input elements of type color" - category: experimental + category: internal webcoreBinding: RuntimeEnabledFeatures condition: ENABLE(INPUT_TYPE_COLOR) ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [236958] trunk/Tools
Title: [236958] trunk/Tools
Revision 236958
Author wenson_hs...@apple.com
Date 2018-10-08 20:28:31 -0700 (Mon, 08 Oct 2018)
Log Message
[macOS] API test DragAndDropTests.DropColor is failing on macOS 10.12
https://bugs.webkit.org/show_bug.cgi?id=190386
Reviewed by Ryosuke Niwa.
Unlike macOS 10.13 and 10.14, -[NSColor redColor] is not equivalent to a fully red color in sRGB on macOS 10.12.
Fix the test by dragging and dropping an NSColor that is equivalent to rgb(255, 0, 0) on all relevant versions
of macOS.
* TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm:
(TEST):
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm
Diff
Modified: trunk/Tools/ChangeLog (236957 => 236958)
--- trunk/Tools/ChangeLog 2018-10-09 02:37:24 UTC (rev 236957)
+++ trunk/Tools/ChangeLog 2018-10-09 03:28:31 UTC (rev 236958)
@@ -1,5 +1,19 @@
2018-10-08 Wenson Hsieh
+[macOS] API test DragAndDropTests.DropColor is failing on macOS 10.12
+https://bugs.webkit.org/show_bug.cgi?id=190386
+
+Reviewed by Ryosuke Niwa.
+
+Unlike macOS 10.13 and 10.14, -[NSColor redColor] is not equivalent to a fully red color in sRGB on macOS 10.12.
+Fix the test by dragging and dropping an NSColor that is equivalent to rgb(255, 0, 0) on all relevant versions
+of macOS.
+
+* TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm:
+(TEST):
+
+2018-10-08 Wenson Hsieh
+
[Cocoa] [WK2] Add support for text alignment and text lists in font attributes
https://bugs.webkit.org/show_bug.cgi?id=190342
Modified: trunk/Tools/TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm (236957 => 236958)
--- trunk/Tools/TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm 2018-10-09 02:37:24 UTC (rev 236957)
+++ trunk/Tools/TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm 2018-10-09 03:28:31 UTC (rev 236958)
@@ -78,7 +78,7 @@
{
NSPasteboard *pasteboard = [NSPasteboard pasteboardWithUniqueName];
[pasteboard declareTypes:@[NSColorPboardType] owner:nil];
-[[NSColor redColor] writeToPasteboard:pasteboard];
+[[NSColor colorWithRed:1 green:0 blue:0 alpha:1] writeToPasteboard:pasteboard];
auto simulator = adoptNS([[DragAndDropSimulator alloc] initWithWebViewFrame:NSMakeRect(0, 0, 400, 400)]);
TestWKWebView *webView = [simulator webView];
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [236770] trunk
Title: [236770] trunk
Revision 236770
Author wenson_hs...@apple.com
Date 2018-10-02 15:53:37 -0700 (Tue, 02 Oct 2018)
Log Message
[WebKit2] Format > Bold and Format > Italic don't toggle between bold and italic style
https://bugs.webkit.org/show_bug.cgi?id=179787
Reviewed by Tim Horton.
Source/WebKit:
Fixes the bug by relaxing our policy in WebViewImpl::updateFontManagerIfNeeded. Instead of updating only when
the font panel is visible, update when either the font panel is visible, or the selection is in a richly
editable area. In the latter case, an up-to-date NSFontManager state is needed in order for certain font
formatting menu items, such as bold and italic, to correctly toggle state.
Test: FontManagerTests.ToggleBoldAndItalicWithMenuItems
* UIProcess/Cocoa/WebViewImpl.h:
* UIProcess/Cocoa/WebViewImpl.mm:
(-[WKWindowVisibilityObserver observeValueForKeyPath:ofObject:change:context:]):
(WebKit::WebViewImpl::selectionDidChange):
(WebKit::WebViewImpl::updateFontManagerIfNeeded):
Rename updateFontPanelIfNeeded to updateFontManagerIfNeeded, to reflect the new behavior.
(WebKit::WebViewImpl::changeFontAttributesFromSender):
(WebKit::WebViewImpl::changeFontFromFontManager):
(WebKit::WebViewImpl::updateFontPanelIfNeeded): Deleted.
Tools:
Add a test to verify that NSFontManager's selected font is updated when applying italic and bold styles using
menu items.
* TestWebKitAPI/Tests/mac/FontManagerTests.mm:
(webViewForFontManagerTesting):
(menuItemCellForFontAction):
(TestWebKitAPI::TEST):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h
trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/mac/FontManagerTests.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (236769 => 236770)
--- trunk/Source/WebKit/ChangeLog 2018-10-02 22:53:33 UTC (rev 236769)
+++ trunk/Source/WebKit/ChangeLog 2018-10-02 22:53:37 UTC (rev 236770)
@@ -1,3 +1,30 @@
+2018-10-02 Wenson Hsieh
+
+[WebKit2] Format > Bold and Format > Italic don't toggle between bold and italic style
+https://bugs.webkit.org/show_bug.cgi?id=179787
+
+
+Reviewed by Tim Horton.
+
+Fixes the bug by relaxing our policy in WebViewImpl::updateFontManagerIfNeeded. Instead of updating only when
+the font panel is visible, update when either the font panel is visible, or the selection is in a richly
+editable area. In the latter case, an up-to-date NSFontManager state is needed in order for certain font
+formatting menu items, such as bold and italic, to correctly toggle state.
+
+Test: FontManagerTests.ToggleBoldAndItalicWithMenuItems
+
+* UIProcess/Cocoa/WebViewImpl.h:
+* UIProcess/Cocoa/WebViewImpl.mm:
+(-[WKWindowVisibilityObserver observeValueForKeyPath:ofObject:change:context:]):
+(WebKit::WebViewImpl::selectionDidChange):
+(WebKit::WebViewImpl::updateFontManagerIfNeeded):
+
+Rename updateFontPanelIfNeeded to updateFontManagerIfNeeded, to reflect the new behavior.
+
+(WebKit::WebViewImpl::changeFontAttributesFromSender):
+(WebKit::WebViewImpl::changeFontFromFontManager):
+(WebKit::WebViewImpl::updateFontPanelIfNeeded): Deleted.
+
2018-10-02 Alex Christensen
Remove ParsedURLString
Modified: trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h (236769 => 236770)
--- trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h 2018-10-02 22:53:33 UTC (rev 236769)
+++ trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h 2018-10-02 22:53:37 UTC (rev 236770)
@@ -323,7 +323,7 @@
void selectionDidChange();
void didBecomeEditable();
-void updateFontPanelIfNeeded();
+void updateFontManagerIfNeeded();
void changeFontFromFontManager();
void changeFontAttributesFromSender(id);
void changeFontColorFromSender(id);
Modified: trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm (236769 => 236770)
--- trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm 2018-10-02 22:53:33 UTC (rev 236769)
+++ trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm 2018-10-02 22:53:37 UTC (rev 236770)
@@ -374,7 +374,7 @@
}
if ([keyPath isEqualToString:@"visible"] && [NSFontPanel sharedFontPanelExists] && object == [NSFontPanel sharedFontPanel]) {
-_impl->updateFontPanelIfNeeded();
+_impl->updateFontManagerIfNeeded();
return;
}
if ([keyPath isEqualToString:@"contentLayoutRect"] || [keyPath isEqualToString:@"titlebarAppearsTransparent"])
@@ -2736,7 +2736,7 @@
void WebViewImpl::selectionDidChange()
{
-updateFontPanelIfNeeded();
+updateFontManagerIfNeeded();
if (!m_isHandlingAcceptedCandidate)
m_softSpaceRange = NSMakeRange(NSNotFound, 0);
#if HAVE(TOUCH_BAR)
@@ -2787,18 +2787,16 @@
});
}
-void WebViewImpl::updateFontPanelIfNeeded()
+void WebViewImpl::updateFontManagerIfNeeded()
{
-const EditorState& editorState =
[webkit-changes] [236724] trunk
Title: [236724] trunk Revision 236724 Author wenson_hs...@apple.com Date 2018-10-02 03:39:40 -0700 (Tue, 02 Oct 2018) Log Message [macOS] Implement a way for the UI process to request typing attributes at the current selection https://bugs.webkit.org/show_bug.cgi?id=189983 Reviewed by Ryosuke Niwa. Source/WebKit: Implements `-[WKWebView typingAttributesWithCompletionHandler:]`, which asynchronously retrieves an NSDictionary containing the typing attributes at the start of the current selection. This is a new asynchronous text input client hook on macOS that is needed in order to support NSInspectorBar on WKWebView. At a high level, this patch builds on top of refactoring done in r236445 to make it possible to send typing attributes from the web process to the UI process, and then adds plumbing in the WebKit2 client layer to surface typing attributes to WKWebView on macOS. Tests: FontManagerTests.TypingAttributesAfterSubscriptAndSuperscript FontManagerTests.ChangeTypingAttributesWithInspectorBar FontManagerTests.ChangeAttributesWithFontEffectsBox * Platform/spi/mac/AppKitSPI.h: * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder::encode): (IPC::ArgumentCoder::decode): Implement IPC coding support for FontAttributes. * Shared/WebCoreArgumentCoders.h: * Shared/mac/ArgumentCodersMac.h: * Shared/mac/ArgumentCodersMac.mm: (IPC::encode): (IPC::decode): Add the ability to encode and decode UIFont. This allows Cocoa platforms to send `FontAttributes.font` over IPC with a single call to IPC::encode/IPC::decode. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView typingAttributesWithCompletionHandler:]): Add plumbing to WebViewImpl. * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::selectionDidChange): Update the NSInspectorBar on selection change, but only if it is present and visible, and WKWebView is currently first responder. (WebKit::WebViewImpl::typingAttributesWithCompletionHandler): Call into WebPageProxy to retrieve FontAttributes from the web process, and invoke the callback with an NSDictionary constructed from the retrieved FontAttributes. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::requestFontAttributesAtSelectionStart): (WebKit::WebPageProxy::fontAttributesCallback): Add plumbing to retrieve FontAttributes from the web process at the current selection. Additionally, cache the font attributes to avoid doing extra work during subsequent requests. (WebKit::WebPageProxy::resetStateAfterProcessExited): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::cachedFontAttributesAtSelectionStart const): * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::editorStateChanged): * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::editorStateChanged): Invalidate cached font attributes. * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::requestFontAttributesAtSelectionStart): Use the currently focused frame's Editor to compute FontAttributes at the current selection, and send the computed FontAttributes back to the UI process. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: Adds new FontManagerTests that exercise -typingAttributesWithCompletionHandler:. See below for more detail. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/TestWebKitAPI/mac/AppKitSPI.h: * TestWebKitAPI/Tests/mac/FontManagerTests.mm: Add a new test that exercises font attribute modification via inspector bar. Also, add a new test that checks typing attributes when using subscript/superscript/unscript. Lastly, augment an existing NSFontPanel test to additionally check that shadowed text and strike-through are reflected in typing attributes. (-[FontManagerTestWKWebView inspectorBarItemIdentifiers]): (-[TestWKWebView typingAttributes]): Add a synchronous wrapper around `-typingAttributesWithCompletionHandler:` by spinning the runloop. (-[TestWKWebView collapseToStart]): (webViewForFontManagerTesting): (TestWebKitAPI::TEST): * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/mac/TestInspectorBar.h: Copied from Tools/TestWebKitAPI/Tests/TestWebKitAPI/mac/AppKitSPI.h. * TestWebKitAPI/mac/TestInspectorBar.mm: Added. Introduce subclasses of `__InspectorBarItemController` and `NSInspectorBar` for testing inspector bar interaction. (-[TestInspectorBarItemController initWithInspectorBar:]): (-[TestInspectorBarItemController inspectorBar]): (-[TestInspectorBarItemController updateSelectedAttributes]): (-[TestInspectorBar initWithWebView:]): (+[TestInspectorBar standardItemControllerClass]): (+[TestInspectorBar standardTextItemIdentifiers]): (-[TestInspectorBar _setStyleControlSelected:atIndex:]): (-[TestInspectorBar chooseFontSize:]): (-[TestInspectorBar chooseFontFamily:]): (-[TestInspectorBar _chooseColor:inColorWell:]): (-[TestInspectorBar chooseForegroundColor:]): (-[TestInspectorBar
[webkit-changes] [236691] trunk
Title: [236691] trunk
Revision 236691
Author wenson_hs...@apple.com
Date 2018-10-01 13:59:19 -0700 (Mon, 01 Oct 2018)
Log Message
[iOS] Add SPI to customize the input accessory view when focusing an element
https://bugs.webkit.org/show_bug.cgi?id=190152
Reviewed by Dan Bernstein.
Source/WebKit:
Adds SPI on WKFormInputSession to customize the input accessory view, alongside the input view. See below for
more details.
Test: KeyboardInputTests.CustomInputViewAndInputAccessoryView
* UIProcess/API/Cocoa/_WKFormInputSession.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKFormInputSession customInputAccessoryView]):
(-[WKFormInputSession setCustomInputAccessoryView:]):
Reload input views when the custom input accessory view changes.
(-[WKContentView requiresAccessoryView]):
If a custom input accessory view is specified, return YES.
(-[WKContentView inputAccessoryView]):
Return the custom input accessory view if present, and fall back to the default web form accessory view.
Tools:
Add an API test to verify that setting a custom input accessory view and custom input view on the form input
session when focusing an element overrides the first responder's (i.e. WKContentView's) `-inputView` and
`-inputAccessoryView`.
* TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
(webViewWithAutofocusedInput):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/ios/TestInputDelegate.h:
* TestWebKitAPI/Tests/ios/TestInputDelegate.mm:
(-[TestInputDelegate setWillStartInputSessionHandler:]):
(-[TestInputDelegate willStartInputSessionHandler]):
(-[TestInputDelegate _webView:willStartInputSession:]):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFormInputSession.h
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
trunk/Tools/TestWebKitAPI/Tests/ios/TestInputDelegate.h
trunk/Tools/TestWebKitAPI/Tests/ios/TestInputDelegate.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (236690 => 236691)
--- trunk/Source/WebKit/ChangeLog 2018-10-01 20:44:06 UTC (rev 236690)
+++ trunk/Source/WebKit/ChangeLog 2018-10-01 20:59:19 UTC (rev 236691)
@@ -1,3 +1,31 @@
+2018-10-01 Wenson Hsieh
+
+[iOS] Add SPI to customize the input accessory view when focusing an element
+https://bugs.webkit.org/show_bug.cgi?id=190152
+
+
+Reviewed by Dan Bernstein.
+
+Adds SPI on WKFormInputSession to customize the input accessory view, alongside the input view. See below for
+more details.
+
+Test: KeyboardInputTests.CustomInputViewAndInputAccessoryView
+
+* UIProcess/API/Cocoa/_WKFormInputSession.h:
+* UIProcess/ios/WKContentViewInteraction.mm:
+(-[WKFormInputSession customInputAccessoryView]):
+(-[WKFormInputSession setCustomInputAccessoryView:]):
+
+Reload input views when the custom input accessory view changes.
+
+(-[WKContentView requiresAccessoryView]):
+
+If a custom input accessory view is specified, return YES.
+
+(-[WKContentView inputAccessoryView]):
+
+Return the custom input accessory view if present, and fall back to the default web form accessory view.
+
2018-10-01 Sihui Liu
Remove StorageProcess
Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFormInputSession.h (236690 => 236691)
--- trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFormInputSession.h 2018-10-01 20:44:06 UTC (rev 236690)
+++ trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFormInputSession.h 2018-10-01 20:59:19 UTC (rev 236691)
@@ -41,6 +41,7 @@
#if TARGET_OS_IPHONE
@property (nonatomic, copy) NSString *accessoryViewCustomButtonTitle;
@property (nonatomic, strong) UIView *customInputView WK_API_AVAILABLE(ios(10.0));
+@property (nonatomic, strong) UIView *customInputAccessoryView WK_API_AVAILABLE(ios(WK_IOS_TBA));
@property (nonatomic, copy) NSArray *suggestions WK_API_AVAILABLE(ios(10.0));
@property (nonatomic) BOOL accessoryViewShouldNotShow WK_API_AVAILABLE(ios(10.0));
@property (nonatomic) BOOL forceSecureTextEntry WK_API_AVAILABLE(ios(10.0));
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (236690 => 236691)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-10-01 20:44:06 UTC (rev 236690)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-10-01 20:59:19 UTC (rev 236691)
@@ -293,6 +293,7 @@
WeakObjCPtr _contentView;
RetainPtr _focusedElementInfo;
RetainPtr _customInputView;
+RetainPtr _customInputAccessoryView;
RetainPtr> _suggestions;
BOOL _accessoryViewShouldNotShow;
BOOL _forceSecureTextEntry;
@@ -383,6 +384,20 @@
[_contentView reloadInputViews];
}
+- (UIView *)customInputAccessoryView
+{
+return _customInputAccessoryView.get();
+}
+
+- (void)setCustomInputAccessoryView:(UIView *)customInputAccessoryView
+{
+if (_customInputAccessoryView ==
[webkit-changes] [236634] trunk
Title: [236634] trunk Revision 236634 Author wenson_hs...@apple.com Date 2018-09-28 19:12:57 -0700 (Fri, 28 Sep 2018) Log Message No DOM API to instantiate an attachment for an img element https://bugs.webkit.org/show_bug.cgi?id=189934 Reviewed by Ryosuke Niwa. Source/WebCore: Adds support for HTMLAttachmentElement.getAttachmentIdentifier, a function that internal WebKit clients can use to ensure that an image element is backed by a unique _WKAttachment. See below for more details. Tests: WKAttachmentTests.AddAttachmentToConnectedImageElement WKAttachmentTests.ChangeFileWrapperForPastedImage WKAttachmentTests.ConnectImageWithAttachmentToDocument * dom/Document.cpp: (WebCore::Document::registerAttachmentIdentifier): Add a new hook to register an empty _WKAttachment in the UI process with a given identifier. Used when creating a new empty attachment to back an image element. * dom/Document.h: * editing/Editor.cpp: (WebCore::Editor::registerAttachmentIdentifier): (WebCore::Editor::notifyClientOfAttachmentUpdates): * editing/Editor.h: * html/HTMLAttachmentElement.cpp: (WebCore::HTMLAttachmentElement::getAttachmentIdentifier): Creates an attachment element to back the image element, if an attachment does not already exist, and returns the unique identifier. This also causes an empty corresponding _WKAttachment to be created in the client, whose file wrapper determines the contents of the image. (WebCore::HTMLAttachmentElement::ensureUniqueIdentifier): (WebCore::HTMLAttachmentElement::hasEnclosingImage const): (WebCore::HTMLAttachmentElement::updateEnclosingImageWithData): Add a helper that updates the source of the enclosing image element given a content type and image data, by creating a new blob and blob URL. * html/HTMLAttachmentElement.h: * html/HTMLAttachmentElement.idl: * html/HTMLImageElement.idl: Rename webkitAttachmentIdentifier to just attachmentIdentifier. * page/EditorClient.h: (WebCore::EditorClient::registerAttachmentIdentifier): (WebCore::EditorClient::didInsertAttachmentWithIdentifier): Source/WebKit: Makes some adjustments to support using _WKAttachment's file wrapper to change the contents of any image element hosting the attachment in its shadow root. To do this, we add some plumbing to allow the UI process to update an attachment element's enclosing image with data from its file wrapper. * UIProcess/API/APIAttachment.cpp: (API::Attachment::isEmpty const): (API::Attachment::enclosingImageData const): Helper method that creates a SharedBuffer representing image data for the attachment. Only returns a non-null value for attachment elements that are enclosed within an image. * UIProcess/API/APIAttachment.h: * UIProcess/API/Cocoa/APIAttachmentCocoa.mm: (API::Attachment::enclosingImageData const): (API::Attachment::isEmpty const): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _attachmentForIdentifier:]): Add new SPI to request a _WKAttachment for a given unique identifier. Currently, this is only used for testing. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::platformRegisterAttachment): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::updateAttachmentAttributes): (WebKit::WebPageProxy::registerAttachmentIdentifier): (WebKit::WebPageProxy::didInsertAttachmentWithIdentifier): Plumb whether or not the attachment is enclosed by an image from the web process to the UI process. (WebKit::WebPageProxy::didRemoveAttachmentWithIdentifier): (WebKit::WebPageProxy::didInsertAttachment): Deleted. (WebKit::WebPageProxy::didRemoveAttachment): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebEditorClient.cpp: (WebKit::WebEditorClient::registerAttachmentIdentifier): (WebKit::WebEditorClient::didInsertAttachmentWithIdentifier): Update attachment attributes after inserting an attachment. This ensures that an attachment that was created and later inserted via script into the document will be synced with state in the UI process, if the client has changed the contents of the attachment. * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::updateAttachmentAttributes): Plumb attachment data from the UI process to the web process. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: Adds 3 new API tests in WKAttachmentTests: `AddAttachmentToConnectedImageElement` verifies that an image element that's already in the document can gain an attachment element via `HTMLAttachmentElement.getAttachmentIdentifier`. `ChangeFileWrapperForPastedImage` verifies that an image that has been pasted produces a _WKAttachment in the UI process, and changing the file wrapper of that _WKAttachment changes the pasted image. `ConnectImageWithAttachmentToDocument` verifies that script can create an image element, ensure that it has an attachment, and set a file wrapper for the generated _WKAttachment.
[webkit-changes] [235504] trunk/Tools
Title: [235504] trunk/Tools
Revision 235504
Author wenson_hs...@apple.com
Date 2018-08-30 07:35:27 -0700 (Thu, 30 Aug 2018)
Log Message
[iOS] TestWebKitAPI.PasteImage tests are flaky failures
https://bugs.webkit.org/show_bug.cgi?id=185965
Reviewed by Andy Estes.
These tests pass reliably when run locally, but sometimes fail in automation when checking that the image
element with its "src" attribute set to a new blob URL has an empty size. It's possible that this is happening
because we're checking the size of the image element prior to image load after setting the blob URL; we can fix
this by waiting for the "load" event (which is also done in some of the other tests in this file).
* TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm:
(TEST):
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm
Diff
Modified: trunk/Tools/ChangeLog (235503 => 235504)
--- trunk/Tools/ChangeLog 2018-08-30 14:32:29 UTC (rev 235503)
+++ trunk/Tools/ChangeLog 2018-08-30 14:35:27 UTC (rev 235504)
@@ -1,3 +1,18 @@
+2018-08-30 Wenson Hsieh
+
+[iOS] TestWebKitAPI.PasteImage tests are flaky failures
+https://bugs.webkit.org/show_bug.cgi?id=185965
+
+Reviewed by Andy Estes.
+
+These tests pass reliably when run locally, but sometimes fail in automation when checking that the image
+element with its "src" attribute set to a new blob URL has an empty size. It's possible that this is happening
+because we're checking the size of the image element prior to image load after setting the blob URL; we can fix
+this by waiting for the "load" event (which is also done in some of the other tests in this file).
+
+* TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm:
+(TEST):
+
2018-08-30 Michael Catanzaro
Unreviewed, rolling out r235114.
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm (235503 => 235504)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm 2018-08-30 14:32:29 UTC (rev 235503)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteImage.mm 2018-08-30 14:35:27 UTC (rev 235504)
@@ -67,6 +67,7 @@
EXPECT_WK_STREQ("true", [webView stringByEvaluatingJavaScript:@"dataTransfer.files.includes(gifItem.file).toString()"]);
[webView stringByEvaluatingJavaScript:@"insertFileAsImage(gifItem.file)"];
+[webView waitForMessage:@"loaded"];
EXPECT_WK_STREQ("blob:", [webView stringByEvaluatingJavaScript:@"url = "" URL(imageElement.src); url.protocol"]);
EXPECT_WK_STREQ("400", [webView stringByEvaluatingJavaScript:@"imageElement.width"]);
}
@@ -89,6 +90,7 @@
EXPECT_WK_STREQ("true", [webView stringByEvaluatingJavaScript:@"dataTransfer.files.includes(jpegItem.file).toString()"]);
[webView stringByEvaluatingJavaScript:@"insertFileAsImage(jpegItem.file)"];
+[webView waitForMessage:@"loaded"];
EXPECT_WK_STREQ("blob:", [webView stringByEvaluatingJavaScript:@"url = "" URL(imageElement.src); url.protocol"]);
EXPECT_WK_STREQ("600", [webView stringByEvaluatingJavaScript:@"imageElement.width"]);
}
@@ -111,6 +113,7 @@
EXPECT_WK_STREQ("true", [webView stringByEvaluatingJavaScript:@"dataTransfer.files.includes(pngItem.file).toString()"]);
[webView stringByEvaluatingJavaScript:@"insertFileAsImage(pngItem.file)"];
+[webView waitForMessage:@"loaded"];
EXPECT_WK_STREQ("blob:", [webView stringByEvaluatingJavaScript:@"url = "" URL(imageElement.src); url.protocol"]);
EXPECT_WK_STREQ("200", [webView stringByEvaluatingJavaScript:@"imageElement.width"]);
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [236445] trunk/Source
Title: [236445] trunk/Source Revision 236445 Author wenson_hs...@apple.com Date 2018-09-24 17:17:29 -0700 (Mon, 24 Sep 2018) Log Message Refactor Editor::fontAttributesForSelectionStart to be platform-agnostic https://bugs.webkit.org/show_bug.cgi?id=189918 Work towards Reviewed by Tim Horton. Source/WebCore: Refactors the functionality in Editor::fontAttributesForSelectionStart to not be Cocoa-only. Rename this to fontAttributesAtSelectionStart (to be consistent with `EditingStyle::styleAtSelectionStart`) and move it from EditorCocoa.mm to Editor.cpp; instead of creating and populating an NSDictionary with font attribute information, create and populate a new `FontAttributes` struct that contains the same information. Cocoa clients in WebKitLegacy may then create an `NSDictionary` as needed from the `FontAttributes`. * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * editing/Editor.cpp: (WebCore::Editor::platformFontAttributesAtSelectionStart const): Add a hook to allow platforms to supply additional information in FontAttributes. On Cocoa, this adds a UIFont or NSFont to FontAttributes; otherwise, this is a no-op. (WebCore::Editor::fontAttributesAtSelectionStart const): * editing/Editor.h: * editing/FontAttributeChanges.cpp: (WebCore::cssValueListForShadow): * editing/FontAttributeChanges.h: (): Deleted. (WebCore::FontShadow::encode const): Deleted. (WebCore::FontShadow::decode): Deleted. * editing/FontAttributes.h: Added. Introduce a new struct that contains font attribute information. May be converted into an NSDictionary for use by Cocoa clients in WebKitLegacy and WebKit. In a future patch, this will become serializable over IPC for use in WebKit2. * editing/FontShadow.h: Added. Move FontShadow out into a separate header file, included in `FontAttributeChanges.h` and `FontAttributes.h`. (WebCore::FontShadow::encode const): (WebCore::FontShadow::decode): * editing/cocoa/EditorCocoa.mm: Add a helper function to convert a WebCore::Color to either `UIColor` on iOS or `NSColor` when AppKit is being used. (WebCore::Editor::platformFontAttributesAtSelectionStart const): (WebCore::Editor::getTextDecorationAttributesRespectingTypingStyle const): Deleted. Remove a helper function that was only used to compute text decoration attributes in fontAttributesForSelectionStart. (WebCore::Editor::fontAttributesForSelectionStart const): Deleted. * editing/cocoa/FontAttributesCocoa.mm: Added. (WebCore::FontAttributes::createDictionary const): * editing/cocoa/FontShadowCocoa.mm: Added. (WebCore::FontShadow::createShadow const): * editing/cocoa/HTMLConverter.mm: (_webKitBundle): (HTMLConverter::_colorForElement): (_platformColor): Deleted. Adopt platformColor(). * platform/graphics/cocoa/ColorCocoa.h: Added. * platform/graphics/cocoa/ColorCocoa.mm: Added. (WebCore::platformColor): * platform/graphics/metal/GPURenderPassDescriptorMetal.mm: Build fix due to changes in unified sources. * platform/mac/WebCoreNSFontManagerExtras.mm: (WebCore::computedFontAttributeChanges): * platform/mediastream/mac/RealtimeIncomingVideoSourceCocoa.mm: * platform/mediastream/mac/RealtimeIncomingVideoSourceCocoa.mm: More build fixes due to changes in unified sources. Source/WebCore/PAL: Add `+_disambiguated_due_to_CIImage_colorWithCGColor:` as a UIColor SPI definition. Also, import `UIColor_Private.h` directly when the Apple internal SDK is used. * pal/spi/ios/UIKitSPI.h: Source/WebKitLegacy/mac: Replace call sites of fontAttributesForSelectionStart() to fontAttributesAtSelectionStart().createDictionary(). * WebView/WebHTMLView.mm: (-[WebHTMLView _selectionStartFontAttributesAsRTF]): (-[WebHTMLView _updateFontPanel]): * WebView/WebView.mm: (-[WebView typingAttributes]): Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/PAL/ChangeLog trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h trunk/Source/WebCore/SourcesCocoa.txt trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj trunk/Source/WebCore/editing/Editor.cpp trunk/Source/WebCore/editing/Editor.h trunk/Source/WebCore/editing/FontAttributeChanges.cpp trunk/Source/WebCore/editing/FontAttributeChanges.h trunk/Source/WebCore/editing/cocoa/EditorCocoa.mm trunk/Source/WebCore/editing/cocoa/HTMLConverter.mm trunk/Source/WebCore/platform/graphics/metal/GPURenderPassDescriptorMetal.mm trunk/Source/WebCore/platform/mac/WebCoreNSFontManagerExtras.mm trunk/Source/WebCore/platform/mediastream/mac/RealtimeIncomingVideoSourceCocoa.h trunk/Source/WebCore/platform/mediastream/mac/RealtimeIncomingVideoSourceCocoa.mm trunk/Source/WebKitLegacy/mac/ChangeLog trunk/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm trunk/Source/WebKitLegacy/mac/WebView/WebView.mm Added Paths trunk/Source/WebCore/editing/FontAttributes.h trunk/Source/WebCore/editing/FontShadow.h trunk/Source/WebCore/editing/cocoa/FontAttributesCocoa.mm trunk/Source/WebCore/editing/cocoa/FontShadowCocoa.mm trunk/Source/WebCore/platform/graphics/cocoa/ColorCocoa.h
[webkit-changes] [236468] trunk/Source/WebCore
Title: [236468] trunk/Source/WebCore
Revision 236468
Author wenson_hs...@apple.com
Date 2018-09-25 11:59:38 -0700 (Tue, 25 Sep 2018)
Log Message
[iOS] Fix the open source iOS 12 build after r236445
https://bugs.webkit.org/show_bug.cgi?id=189953
Reviewed by Alex Christensen.
Source/WebCore:
Remove soft-linking macros from several sources in WebCore, and instead import UIKitSoftLink from PAL. This
allows different WebCore sources to soft-link UIKit (and its classes and symbols) without reimplementing
WebCore::UIKitLibrary.
* editing/cocoa/FontAttributesCocoa.mm:
* editing/cocoa/FontShadowCocoa.mm:
(WebCore::FontShadow::createShadow const):
* platform/graphics/cocoa/ColorCocoa.mm:
(WebCore::platformColor):
* platform/ios/PlatformScreenIOS.mm:
(WebCore::screenIsMonochrome):
(WebCore::screenHasInvertedColors):
(WebCore::screenSize):
(WebCore::availableScreenSize):
(WebCore::screenScaleFactor):
Source/WebCore/PAL:
Introduce a single UIKit soft-linking header in PAL.
* PAL.xcodeproj/project.pbxproj:
* pal/ios/UIKitSoftLink.h: Copied from Source/WebCore/platform/graphics/cocoa/ColorCocoa.mm.
* pal/ios/UIKitSoftLink.mm: Copied from Source/WebCore/platform/graphics/cocoa/ColorCocoa.mm.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/PAL/ChangeLog
trunk/Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj
trunk/Source/WebCore/editing/cocoa/FontAttributesCocoa.mm
trunk/Source/WebCore/editing/cocoa/FontShadowCocoa.mm
trunk/Source/WebCore/platform/graphics/cocoa/ColorCocoa.mm
trunk/Source/WebCore/platform/ios/PlatformScreenIOS.mm
Added Paths
trunk/Source/WebCore/PAL/pal/ios/
trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.h
trunk/Source/WebCore/PAL/pal/ios/UIKitSoftLink.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (236467 => 236468)
--- trunk/Source/WebCore/ChangeLog 2018-09-25 18:55:24 UTC (rev 236467)
+++ trunk/Source/WebCore/ChangeLog 2018-09-25 18:59:38 UTC (rev 236468)
@@ -1,3 +1,26 @@
+2018-09-25 Wenson Hsieh
+
+[iOS] Fix the open source iOS 12 build after r236445
+https://bugs.webkit.org/show_bug.cgi?id=189953
+
+Reviewed by Alex Christensen.
+
+Remove soft-linking macros from several sources in WebCore, and instead import UIKitSoftLink from PAL. This
+allows different WebCore sources to soft-link UIKit (and its classes and symbols) without reimplementing
+WebCore::UIKitLibrary.
+
+* editing/cocoa/FontAttributesCocoa.mm:
+* editing/cocoa/FontShadowCocoa.mm:
+(WebCore::FontShadow::createShadow const):
+* platform/graphics/cocoa/ColorCocoa.mm:
+(WebCore::platformColor):
+* platform/ios/PlatformScreenIOS.mm:
+(WebCore::screenIsMonochrome):
+(WebCore::screenHasInvertedColors):
+(WebCore::screenSize):
+(WebCore::availableScreenSize):
+(WebCore::screenScaleFactor):
+
2018-09-25 Thibault Saunier
[WPE][GTK][WebRTC] Fixup VP8 encoding support
Modified: trunk/Source/WebCore/PAL/ChangeLog (236467 => 236468)
--- trunk/Source/WebCore/PAL/ChangeLog 2018-09-25 18:55:24 UTC (rev 236467)
+++ trunk/Source/WebCore/PAL/ChangeLog 2018-09-25 18:59:38 UTC (rev 236468)
@@ -1,3 +1,16 @@
+2018-09-25 Wenson Hsieh
+
+[iOS] Fix the open source iOS 12 build after r236445
+https://bugs.webkit.org/show_bug.cgi?id=189953
+
+Reviewed by Alex Christensen.
+
+Introduce a single UIKit soft-linking header in PAL.
+
+* PAL.xcodeproj/project.pbxproj:
+* pal/ios/UIKitSoftLink.h: Copied from Source/WebCore/platform/graphics/cocoa/ColorCocoa.mm.
+* pal/ios/UIKitSoftLink.mm: Copied from Source/WebCore/platform/graphics/cocoa/ColorCocoa.mm.
+
2018-09-24 Wenson Hsieh
Refactor Editor::fontAttributesForSelectionStart to be platform-agnostic
Modified: trunk/Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj (236467 => 236468)
--- trunk/Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj 2018-09-25 18:55:24 UTC (rev 236467)
+++ trunk/Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj 2018-09-25 18:59:38 UTC (rev 236468)
@@ -108,6 +108,8 @@
1CCEE4F520D871930047B097 /* CoreUISPI.h in Headers */ = {isa = PBXBuildFile; fileRef = 1CCEE4F420D871930047B097 /* CoreUISPI.h */; };
1CCEE4F720D8743F0047B097 /* NSAppearanceSPI.h in Headers */ = {isa = PBXBuildFile; fileRef = 1CCEE4F620D8743F0047B097 /* NSAppearanceSPI.h */; };
2D02E93C2056FAA700A13797 /* AudioToolboxSPI.h in Headers */ = {isa = PBXBuildFile; fileRef = 2D02E93B2056FAA700A13797 /* AudioToolboxSPI.h */; };
+ 2E1342CC215AA10A007199D2 /* UIKitSoftLink.h in Headers */ = {isa = PBXBuildFile; fileRef = 2E1342CA215AA10A007199D2 /* UIKitSoftLink.h */; };
+ 2E1342CD215AA10A007199D2 /* UIKitSoftLink.mm in Sources */ = {isa = PBXBuildFile; fileRef = 2E1342CB215AA10A007199D2 /* UIKitSoftLink.mm */; };
31308B1420A21705003FB929 /* SystemPreviewSPI.h in Headers */ = {isa = PBXBuildFile; fileRef = 31308B1320A21705003FB929 /* SystemPreviewSPI.h
[webkit-changes] [238360] trunk
Title: [238360] trunk Revision 238360 Author wenson_hs...@apple.com Date 2018-11-17 22:17:44 -0800 (Sat, 17 Nov 2018) Log Message [iOS] Remove all usages of UIItemProvider, UIItemProviderReading, and related classes https://bugs.webkit.org/show_bug.cgi?id=191819 Reviewed by Dan Bernstein. Replace UIItemProvider (and related classes) with NSItemProvider. Source/WebCore: * platform/ios/PlatformPasteboardIOS.mm: (WebCore::registerItemToPasteboard): * platform/ios/WebItemProviderPasteboard.h: * platform/ios/WebItemProviderPasteboard.mm: (-[WebItemProviderDataRegistrar registerItemProvider:]): (-[WebItemProviderWritableObjectRegistrar initWithObject:]): (-[WebItemProviderWritableObjectRegistrar representingObject]): (-[WebItemProviderWritableObjectRegistrar registerItemProvider:]): (-[WebItemProviderRegistrationInfoList addRepresentingObject:]): (-[WebItemProviderRegistrationInfoList itemProvider]): (-[WebItemProviderPasteboard pasteboardTypes]): (-[WebItemProviderPasteboard _preLoadedDataConformingToType:forItemProviderAtIndex:]): (-[WebItemProviderPasteboard dataForPasteboardType:inItemSet:]): (allLoadableClasses): (classForTypeIdentifier): (-[WebItemProviderPasteboard valuesForPasteboardType:inItemSet:]): (-[WebItemProviderPasteboard numberOfFiles]): (-[WebItemProviderPasteboard itemProviderAtIndex:]): (-[WebItemProviderPasteboard enumerateItemProvidersWithBlock:]): * platform/mac/DragDataMac.mm: (WebCore::DragData::containsURL const): Source/WebCore/PAL: * pal/spi/ios/UIKitSPI.h: Source/WebKit: * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _itemsForBeginningOrAddingToSessionWithRegistrationList:stagedDragSource:]): (-[WKContentView dropInteraction:performDrop:]): Tools: * TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm: (platformCopyPNG): * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (-[NSItemProvider registerDataRepresentationForTypeIdentifier:withData:]): Replace usages of this deprecated method with `-registerDataRepresentationForTypeIdentifier:visibility:loadHandler:`. (checkEstimatedSize): (checkSuggestedNameAndEstimatedSize): (TestWebKitAPI::TEST): (-[UIItemProvider registerDataRepresentationForTypeIdentifier:withData:]): Deleted. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm: (-[MockDragDropSession canLoadObjectsOfClass:]): (-[MockDragDropSession canLoadObjectsOfClasses:]): (-[MockDropSession initWithProviders:location:window:allowMove:]): (-[MockDropSession canCreateItemsOfClass:]): (-[DragAndDropSimulator _advanceProgress]): (-[DragAndDropSimulator _webView:dataInteractionOperationWasHandled:forSession:itemProviders:]): (-[DragAndDropSimulator _webView:adjustedDataInteractionItemProvidersForItemProvider:representingObjects:additionalData:]): * TestWebKitAPI/ios/UIKitSPI.h: Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/PAL/ChangeLog trunk/Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h trunk/Source/WebCore/platform/ios/PlatformPasteboardIOS.mm trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.h trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm trunk/Source/WebCore/platform/mac/DragDataMac.mm trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm trunk/Tools/TestWebKitAPI/cocoa/DragAndDropSimulator.h trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h Diff Modified: trunk/Source/WebCore/ChangeLog (238359 => 238360) --- trunk/Source/WebCore/ChangeLog 2018-11-18 03:14:31 UTC (rev 238359) +++ trunk/Source/WebCore/ChangeLog 2018-11-18 06:17:44 UTC (rev 238360) @@ -1,3 +1,34 @@ +2018-11-17 Wenson Hsieh + +[iOS] Remove all usages of UIItemProvider, UIItemProviderReading, and related classes +https://bugs.webkit.org/show_bug.cgi?id=191819 + +Reviewed by Dan Bernstein. + +Replace UIItemProvider (and related classes) with NSItemProvider. + +* platform/ios/PlatformPasteboardIOS.mm: +(WebCore::registerItemToPasteboard): +* platform/ios/WebItemProviderPasteboard.h: +* platform/ios/WebItemProviderPasteboard.mm: +(-[WebItemProviderDataRegistrar registerItemProvider:]): +(-[WebItemProviderWritableObjectRegistrar initWithObject:]): +(-[WebItemProviderWritableObjectRegistrar representingObject]): +(-[WebItemProviderWritableObjectRegistrar registerItemProvider:]): +(-[WebItemProviderRegistrationInfoList addRepresentingObject:]): +(-[WebItemProviderRegistrationInfoList itemProvider]): +(-[WebItemProviderPasteboard pasteboardTypes]): +(-[WebItemProviderPasteboard _preLoadedDataConformingToType:forItemProviderAtIndex:]): +
[webkit-changes] [239573] trunk
Title: [239573] trunk Revision 239573 Author wenson_hs...@apple.com Date 2019-01-02 12:28:24 -0800 (Wed, 02 Jan 2019) Log Message REGRESSION (r239441): [iOS] Selection UI sometimes doesn't change after tapping "select all" in the callout bar https://bugs.webkit.org/show_bug.cgi?id=193070 Reviewed by Tim Horton. Source/WebKit: r239441 added logic to include an EditorState in the next layer tree commit when refocusing an element; this was done to ensure that after tapping an element that has already been programmatically focused, we still send up- to-date editor information to the UI process for the purposes of zooming to the selection rect, even if the selection in the DOM is unchanged, since other aspects of the editor state may have changed since the element was initially focused. We currently try to flag the next layer tree commit by setting `m_hasPendingEditorStateUpdate` to `true`. However, this is problematic since we aren't guaranteed in all cases that a compositing flush has been scheduled. In the case where it hasn't, we'll end up in a state where the editor state update flag has been set, yet the update will not make it over to the UI process until something happens that forces a layer tree commit (e.g. scrolling, pinch zooming). Worse still, if the selection is then programmatically changed from the web process, we will bail from sending a subsequent editor state update to the UI process because `WebPage` thinks that a pending editor state has already been scheduled. This manifests in selection UI not updating after tapping "Select All" in the callout bar, if the callout bar was brought up by tapping near the selection (since this refocuses the element). To fix this, we adjust this logic in `WebPage::elementDidRefocus` so that it sets the flag and then schedules a compositing flush, but only if the user is actually interacting with the focused element (i.e., if the page calls `focus` repeatedly, we won't continue to schedule compositing flushes). Test: editing/selection/ios/change-selection-after-tapping-focused-element.html * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::elementDidRefocus): (WebKit::WebPage::sendEditorStateUpdate): (WebKit::WebPage::scheduleFullEditorStateUpdate): Add a private helper method to schedule an editor state update by setting `m_hasPendingEditorStateUpdate` to `true` and then scheduling a compositing layer flush. Also, add a FIXME aluding to the fact that scheduling an entire compositing layer flush to send an editor state update is somewhat wasteful, and should be replaced by just scheduling this work to be done before the next frame (see: for more detail). We also use this helper method in a few places where we currently turn on the editor state flag and schedule a subsequent compositing flush. (WebKit::WebPage::sendPartialEditorStateAndSchedulePostLayoutUpdate): * WebProcess/WebPage/WebPage.h: LayoutTests: Add a test to ensure that selection UI is shown after tapping on a focused element and then changing the selection programmatically. * editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt: Added. * editing/selection/ios/change-selection-after-tapping-focused-element.html: Added. Modified Paths trunk/LayoutTests/ChangeLog trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h Added Paths trunk/LayoutTests/editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt trunk/LayoutTests/editing/selection/ios/change-selection-after-tapping-focused-element.html Diff Modified: trunk/LayoutTests/ChangeLog (239572 => 239573) --- trunk/LayoutTests/ChangeLog 2019-01-02 19:40:05 UTC (rev 239572) +++ trunk/LayoutTests/ChangeLog 2019-01-02 20:28:24 UTC (rev 239573) @@ -1,3 +1,17 @@ +2019-01-02 Wenson Hsieh + +REGRESSION (r239441): [iOS] Selection UI sometimes doesn't change after tapping "select all" in the callout bar +https://bugs.webkit.org/show_bug.cgi?id=193070 + + +Reviewed by Tim Horton. + +Add a test to ensure that selection UI is shown after tapping on a focused element and then changing the +selection programmatically. + +* editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt: Added. +* editing/selection/ios/change-selection-after-tapping-focused-element.html: Added. + 2019-01-02 Simon Fraser Handle calc() expressions in gradient color stops Added: trunk/LayoutTests/editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt (0 => 239573) --- trunk/LayoutTests/editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt (rev 0) +++ trunk/LayoutTests/editing/selection/ios/change-selection-after-tapping-focused-element-expected.txt 2019-01-02 20:28:24 UTC (rev 239573) @@ -0,0 +1,14 @@ +WebKit +Verifies that after tapping a
[webkit-changes] [239584] trunk
Title: [239584] trunk Revision 239584 Author wenson_hs...@apple.com Date 2019-01-02 20:00:47 -0800 (Wed, 02 Jan 2019) Log Message Add support for using the current text selection as the find string on iOS https://bugs.webkit.org/show_bug.cgi?id=193034 Reviewed by Tim Horton. Source/WebCore: Add support for "TakeFindStringFromSelection" on iOS. Unlike macOS, iOS does not have a notion of a "find pasteboard" like macOS; instead, we handle this editing command by sending the selection string to the UI process, where it is exposed via WebKit SPI so that clients that present find-in-page UI (i.e. MobileSafari) are able to trigger find-in-page with this string. Test: WebKit.UseSelectionAsFindString * editing/Editor.cpp: (WebCore::Editor::canCopyExcludingStandaloneImages const): Make this helper function cross-platform. * editing/Editor.h: * editing/EditorCommand.cpp: (WebCore::createCommandMap): * editing/cocoa/EditorCocoa.mm: (WebCore::Editor::takeFindStringFromSelection): Move this from EditorMac to EditorCocoa, and implement it on iOS by calling into the editor client to update the find string (see WebKit/ChangeLog for more details). * editing/mac/EditorMac.mm: (WebCore::Editor::canCopyExcludingStandaloneImages): Deleted. (WebCore::Editor::takeFindStringFromSelection): Deleted. * loader/EmptyClients.cpp: * page/EditorClient.h: Add a new editor client method to send the string for find-in-page to the UI process. Source/WebKit: * SourcesCocoa.txt: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _takeFindStringFromSelection:]): Provides a way to set the find string on iOS and macOS (an aside: takeFindStringFromSelection: already exists on macOS, but there is no equivalent protocol method on iOS, so this new SPI acts as a cross-platform way for WebKit clients to take the find string from the selection across all Cocoa platforms). (+[WKWebView _stringForFind]): (+[WKWebView _setStringForFind:]): Call into find-in-page helper functions. (-[WKWebView _findString:options:maxCount:]): On iOS, additionally update the find-in-page string when exercising the _findString:options:maxCount: SPI. This mirrors macOS behavior of updating the find pasteboard every time the find string changes; however, on macOS, this is implemented by the platform (in AppKit), whereas there's no platform find pasteboard on iOS, let alone logic to update it in UIKit. As such, we directly drive updates to the find string within WebKit. * UIProcess/API/Cocoa/WKWebViewPrivate.h: Add some new cross-platform find-in-page SPI. See above for more details. * UIProcess/Cocoa/GlobalFindInPageState.h: Added. * UIProcess/Cocoa/GlobalFindInPageState.mm: Added. (WebKit::findPasteboard): (WebKit::globalStringForFind): Fetch the string to use when finding text in the page. On macOS, this accesses the AppKit find pasteboard; on iOS, this instead returns the current global find string. (WebKit::updateStringForFind): Sets the global find string. Uses the find pasteboard on macOS, and sets the global find string on iOS. (WebKit::stringForFind): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: Add plumbing to allow WebEditorClient to deliver the update the global find string in the UI process. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::updateStringForFind): * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm: (WebKit::WebEditorClient::updateStringForFind): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateStringForFind): Source/WebKitLegacy/mac: Add a method stub for WebKitLegacy. * WebCoreSupport/WebEditorClient.h: Tools: Add a new API test to verify that the new WebKit SPI (_stringForFind, _takeFindStringFromSelection:, and _setStringForFind) works as expected. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/UseSelectionAsFindString.mm: Added. Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/Editor.cpp trunk/Source/WebCore/editing/Editor.h trunk/Source/WebCore/editing/EditorCommand.cpp trunk/Source/WebCore/editing/cocoa/EditorCocoa.mm trunk/Source/WebCore/editing/mac/EditorMac.mm trunk/Source/WebCore/loader/EmptyClients.cpp trunk/Source/WebCore/page/EditorClient.h trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/SourcesCocoa.txt trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/WebPageProxy.messages.in trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm trunk/Source/WebKit/WebKit.xcodeproj/project.pbxproj trunk/Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h trunk/Source/WebKit/WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
[webkit-changes] [240159] trunk/Source/WebKit
Title: [240159] trunk/Source/WebKit
Revision 240159
Author wenson_hs...@apple.com
Date 2019-01-18 11:10:04 -0800 (Fri, 18 Jan 2019)
Log Message
Remove some last vestiges of assisted node terminology in WebKit
https://bugs.webkit.org/show_bug.cgi?id=193572
Reviewed by Tim Horton.
* UIProcess/API/Cocoa/_WKFocusedElementInfo.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView gestureRecognizerShouldBegin:]):
(-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):
(-[WKContentView _showKeyboard]):
(-[WKContentView _hideKeyboard]):
Add a FIXME about invoking `-reloadInputViews` on watchOS when the focused element is blurred.
(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
(-[WKContentView _elementDidBlur]):
(-[WKContentView updateCurrentFocusedElementInformation:]):
(-[WKContentView _startAssistingKeyboard]): Deleted.
(-[WKContentView _stopAssistingKeyboard]): Deleted.
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::getFocusedElementInformation):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFocusedElementInfo.h
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (240158 => 240159)
--- trunk/Source/WebKit/ChangeLog 2019-01-18 18:44:54 UTC (rev 240158)
+++ trunk/Source/WebKit/ChangeLog 2019-01-18 19:10:04 UTC (rev 240159)
@@ -1,3 +1,27 @@
+2019-01-18 Wenson Hsieh
+
+Remove some last vestiges of assisted node terminology in WebKit
+https://bugs.webkit.org/show_bug.cgi?id=193572
+
+Reviewed by Tim Horton.
+
+* UIProcess/API/Cocoa/_WKFocusedElementInfo.h:
+* UIProcess/ios/WKContentViewInteraction.mm:
+(-[WKContentView gestureRecognizerShouldBegin:]):
+(-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):
+(-[WKContentView _showKeyboard]):
+(-[WKContentView _hideKeyboard]):
+
+Add a FIXME about invoking `-reloadInputViews` on watchOS when the focused element is blurred.
+
+(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
+(-[WKContentView _elementDidBlur]):
+(-[WKContentView updateCurrentFocusedElementInformation:]):
+(-[WKContentView _startAssistingKeyboard]): Deleted.
+(-[WKContentView _stopAssistingKeyboard]): Deleted.
+* WebProcess/WebPage/ios/WebPageIOS.mm:
+(WebKit::WebPage::getFocusedElementInformation):
+
2019-01-18 Youenn Fablet
Add a new SPI to request for cache storage quota increase
Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFocusedElementInfo.h (240158 => 240159)
--- trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFocusedElementInfo.h 2019-01-18 18:44:54 UTC (rev 240158)
+++ trunk/Source/WebKit/UIProcess/API/Cocoa/_WKFocusedElementInfo.h 2019-01-18 19:10:04 UTC (rev 240159)
@@ -58,9 +58,9 @@
};
/**
- * The _WKFocusedElementInfo provides basic information about an element
- * that has been focused (either programmatically or through user interaction)
- * but has not yet been assisted.
+ * The _WKFocusedElementInfo provides basic information about an element that
+ * has been focused (either programmatically or through user interaction) but
+ * is not causing any input UI (e.g. keyboard, date picker, etc.) to be shown.
*/
@protocol _WKFocusedElementInfo
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (240158 => 240159)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-01-18 18:44:54 UTC (rev 240158)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-01-18 19:10:04 UTC (rev 240159)
@@ -1736,7 +1736,7 @@
if (hasFocusedElement(_focusedElementInformation)) {
// Request information about the position with sync message.
-// If the assisted node is the same, prevent the gesture.
+// If the focused element is the same, prevent the gesture.
if (![self ensurePositionInformationIsUpToDate:WebKit::InteractionInformationRequest(WebCore::roundedIntPoint(point))])
return NO;
if (_positionInformation.nodeAtPositionIsFocusedElement)
@@ -1746,7 +1746,7 @@
if (gestureRecognizer == _highlightLongPressGestureRecognizer) {
if (hasFocusedElement(_focusedElementInformation)) {
-// This is a different node than the assisted one.
+// This is a different element than the focused one.
// Prevent the gesture if there is no node.
// Allow the gesture if it is a node that wants highlight or if there is an action for it.
if (!_positionInformation.isElement)
@@ -1885,7 +1885,7 @@
return NO;
#endif
-// If we're currently editing an assisted node, only allow the selection to move within that
[webkit-changes] [239931] trunk
Title: [239931] trunk Revision 239931 Author wenson_hs...@apple.com Date 2019-01-14 12:09:58 -0800 (Mon, 14 Jan 2019) Log Message [iOS] Expose SPI to access the current sentence boundary and selection state https://bugs.webkit.org/show_bug.cgi?id=193398 Reviewed by Dean Jackson. Source/WebKit: Expose SPI on WKWebView for internal clients to grab information about attributes at the current selection; so far, this only includes whether the selection is a caret or a range, and whether or not the start of the selection is at the start of a new sentence. Test: EditorStateTests.ObserveSelectionAttributeChanges * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): * Shared/EditorState.h: Add a new bit in EditorState on iOS to compute whether or not the start of the selection is at the start of a new sentence. This is computed and set when sending post-layout data in `WebPageIOS.mm`. * UIProcess/API/Cocoa/WKWebView.mm: (selectionAttributes): (-[WKWebView _didChangeEditorState]): (-[WKWebView _selectionAttributes]): Make the new SPI property support KVO by invoking `-willChangeValueForKey:` and `-didChangeValueForKey:` whenever the selection attributes change. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): Tools: Add an API test to verify that an SPI client can observe changes in the `@"_selectionAttributes"` key path on WKWebView, and that inserting text, deleting, and changing the selection cause selection attributes to change as expected. * TestWebKitAPI/EditingTestHarness.h: * TestWebKitAPI/EditingTestHarness.mm: (-[EditingTestHarness moveBackward]): (-[EditingTestHarness moveForward]): (-[EditingTestHarness moveForwardAndExpectEditorStateWith:]): Add a couple of new helper methods on EditingTestHarness. * TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm: (-[SelectionChangeObserver initWithWebView:]): (-[SelectionChangeObserver webView]): (-[SelectionChangeObserver observeValueForKeyPath:ofObject:change:context:]): (-[SelectionChangeObserver currentSelectionAttributes]): Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Shared/EditorState.cpp trunk/Source/WebKit/Shared/EditorState.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/EditingTestHarness.h trunk/Tools/TestWebKitAPI/EditingTestHarness.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm Diff Modified: trunk/Source/WebKit/ChangeLog (239930 => 239931) --- trunk/Source/WebKit/ChangeLog 2019-01-14 19:21:50 UTC (rev 239930) +++ trunk/Source/WebKit/ChangeLog 2019-01-14 20:09:58 UTC (rev 239931) @@ -1,3 +1,37 @@ +2019-01-14 Wenson Hsieh + +[iOS] Expose SPI to access the current sentence boundary and selection state +https://bugs.webkit.org/show_bug.cgi?id=193398 + + +Reviewed by Dean Jackson. + +Expose SPI on WKWebView for internal clients to grab information about attributes at the current selection; so +far, this only includes whether the selection is a caret or a range, and whether or not the start of the +selection is at the start of a new sentence. + +Test: EditorStateTests.ObserveSelectionAttributeChanges + +* Shared/EditorState.cpp: +(WebKit::EditorState::PostLayoutData::encode const): +(WebKit::EditorState::PostLayoutData::decode): +* Shared/EditorState.h: + +Add a new bit in EditorState on iOS to compute whether or not the start of the selection is at the start of a +new sentence. This is computed and set when sending post-layout data in `WebPageIOS.mm`. + +* UIProcess/API/Cocoa/WKWebView.mm: +(selectionAttributes): +(-[WKWebView _didChangeEditorState]): +(-[WKWebView _selectionAttributes]): + +Make the new SPI property support KVO by invoking `-willChangeValueForKey:` and `-didChangeValueForKey:` +whenever the selection attributes change. + +* UIProcess/API/Cocoa/WKWebViewPrivate.h: +* WebProcess/WebPage/ios/WebPageIOS.mm: +(WebKit::WebPage::platformEditorState const): + 2019-01-14 Carlos Garcia Campos Unreviewed. Update OptionsGTK.cmake and NEWS for 2.23.3 release Modified: trunk/Source/WebKit/Shared/EditorState.cpp (239930 => 239931) --- trunk/Source/WebKit/Shared/EditorState.cpp 2019-01-14 19:21:50 UTC (rev 239930) +++ trunk/Source/WebKit/Shared/EditorState.cpp 2019-01-14 20:09:58 UTC (rev 239931) @@ -132,6 +132,7 @@ encoder << hasPlainText; encoder << elementIsTransparentOrFullyClipped; encoder << caretColor; +encoder << atStartOfSentence; #endif #if PLATFORM(MAC) encoder << candidateRequestStartPosition; @@ -191,6 +192,8 @@
[webkit-changes] [240301] trunk/Tools
Title: [240301] trunk/Tools Revision 240301 Author wenson_hs...@apple.com Date 2019-01-22 15:21:45 -0800 (Tue, 22 Jan 2019) Log Message [iOS] Multiple WKWebViewAutofillTests are flaky failures https://bugs.webkit.org/show_bug.cgi?id=189165 Reviewed by Tim Horton. These tests are currently flaky because they expect an invocation of "Element.blur()" in the web process to immediately dispatch an IPC message to notify the UI process that the element has been blurred. In particular, the -textInputHasAutofillContext helper assumes that waiting for the next remote layer tree commit in the UI process in sufficient to ensure that any previous action that blurred the focused element in the web process would make its way to the UI process by the time the layer tree commit is finished. However, WebPage::elementDidBlur sends its IPC message to the UI process asynchronously, using callOnMainThread. This means that if a layer tree flush was already scheduled in the web process before the element was blurred, the element blur IPC message to the UI process will lose the race against the layer tree commit, and the test will fail because it asks for -_autofillContext too early. To fix this, we tweak these tests to actually wait until the intended input session change triggered by script is handled in the UI process. * TestWebKitAPI/Tests/ios/WKWebViewAutofillTests.mm: Tweak some of these tests to wait for input session changes before checking for the presence of an autofill context. The only exception is an existing test that doesn't allow programmatic focus to begin input sessions by default; to fix this test, we simply wait for _WKInputDelegate to be invoked, instead of waiting for a new input session. (-[AutofillTestView textInputHasAutofillContext]): Remove the incorrect presentation update here. This helper now assumes that the UI process is up to date. * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/cocoa/TestWKWebView.mm: (nextInputSessionChangeCount): Monotonically increasing identifier that's incremented whenever an input session is started in the UI process. This includes changing the focused element from one to another. (-[TestWKWebView initWithFrame:configuration:addToWindow:]): (-[TestWKWebView didStartFormControlInteraction]): (-[TestWKWebView didEndFormControlInteraction]): (-[TestWKWebView evaluateJavaScriptAndWaitForInputSessionToChange:]): Add a helper to evaluate _javascript_ and wait for this script to cause some change in the input session. This handles three cases: (1) changing focus from an element that doesn't require an input session to one that does, (2) changing focus between elements that require input sessions, and (3) changing focus from an input session that doesn't require an input session to one that doesn't. Modified Paths trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/ios/WKWebViewAutofillTests.mm trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.h trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm Diff Modified: trunk/Tools/ChangeLog (240300 => 240301) --- trunk/Tools/ChangeLog 2019-01-22 23:08:36 UTC (rev 240300) +++ trunk/Tools/ChangeLog 2019-01-22 23:21:45 UTC (rev 240301) @@ -1,3 +1,53 @@ +2019-01-22 Wenson Hsieh + +[iOS] Multiple WKWebViewAutofillTests are flaky failures +https://bugs.webkit.org/show_bug.cgi?id=189165 + + +Reviewed by Tim Horton. + +These tests are currently flaky because they expect an invocation of "Element.blur()" in the web process to +immediately dispatch an IPC message to notify the UI process that the element has been blurred. In particular, +the -textInputHasAutofillContext helper assumes that waiting for the next remote layer tree commit in the UI +process in sufficient to ensure that any previous action that blurred the focused element in the web process +would make its way to the UI process by the time the layer tree commit is finished. + +However, WebPage::elementDidBlur sends its IPC message to the UI process asynchronously, using callOnMainThread. +This means that if a layer tree flush was already scheduled in the web process before the element was blurred, +the element blur IPC message to the UI process will lose the race against the layer tree commit, and the test +will fail because it asks for -_autofillContext too early. + +To fix this, we tweak these tests to actually wait until the intended input session change triggered by script +is handled in the UI process. + +* TestWebKitAPI/Tests/ios/WKWebViewAutofillTests.mm: + +Tweak some of these tests to wait for input session changes before checking for the presence of an autofill +context. The only exception is an existing test that doesn't allow programmatic focus to begin input sessions +by default; to fix this test, we simply wait for _WKInputDelegate to be invoked, instead of waiting for a new +input
[webkit-changes] [240315] trunk/Source/WebCore
Title: [240315] trunk/Source/WebCore
Revision 240315
Author wenson_hs...@apple.com
Date 2019-01-22 18:06:53 -0800 (Tue, 22 Jan 2019)
Log Message
Add some bindings-related bookkeeping to UndoManager and UndoItem
https://bugs.webkit.org/show_bug.cgi?id=193111
Reviewed by Ryosuke Niwa.
This patch is work in progress towards supporting `UndoManager.addItem()`. Here, we add helper methods to
UndoItem and UndoManager which later patches will exercise, as well as introduce some custom bindings to
properly handle the case where UndoItems are given anonymous _javascript_ functions (see below for more details).
No new tests, because there is no script-observable change in behavior yet. When `addItems()` is hooked up, I
will write a test to verify that the undo and redo _javascript_ functions survive garbage collection.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/JSUndoItemCustom.cpp:
(WebCore::JSUndoItem::visitAdditionalChildren):
Have each JSUndoItem visit its undo and redo callback functions to ensure that the _javascript_ wrapper objects
for these functions are not garbage collected underneath the item.
(WebCore::JSUndoItemOwner::isReachableFromOpaqueRoots):
Consider the undo item wrapper reachable from opaque roots if it is associated with its UndoManager's Document.
This ensures that if script isn't holding on to a reference to the wrapper (for instance, by calling
`UndoManager.addItem(new UndoItem({ ... }))`), we still protect the corresponding JSUndoItem as long as the
UndoManager's Document is alive. In the case where the undo item is not associated with a document, either (1)
script is keeping a reference to it, in which case it will be trivially reachable, or (2) script won't be able
to observe the destruction of the wrapper anyways (e.g. calling `new UndoItem({ ... })` by itself).
* dom/Document.cpp:
(WebCore::Document::prepareForDestruction):
Invalidate all undo items when the document is about to go away.
* page/UndoItem.cpp:
(WebCore::UndoItem::setUndoManager):
(WebCore::UndoItem::invalidate):
(WebCore::UndoItem::isValid const):
Add a few helpers, to be used in a future patch. We consider an UndoItem valid if it has been added to an
UndoManager, and is thus associated with a document.
(WebCore::UndoItem::document const):
* page/UndoItem.h:
* page/UndoItem.idl:
* page/UndoManager.cpp:
(WebCore::UndoManager::UndoManager):
(WebCore::UndoManager::addItem):
Have an UndoManager keep its UndoItems alive. These UndoItems remain in this set until either the document will
be destroyed, or the corresponding undo action is no longer needed because the platform undo stack has changed
(this latter behavior is yet to be implemented).
(WebCore::UndoManager::removeItem):
(WebCore::UndoManager::removeAllItems):
* page/UndoManager.h:
(WebCore::UndoManager::UndoManager): Deleted.
* page/scrolling/ScrollingTreeScrollingNode.cpp:
Unified build fix.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Sources.txt
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/page/UndoItem.h
trunk/Source/WebCore/page/UndoItem.idl
trunk/Source/WebCore/page/UndoManager.cpp
trunk/Source/WebCore/page/UndoManager.h
Added Paths
trunk/Source/WebCore/bindings/js/JSUndoItemCustom.cpp
trunk/Source/WebCore/page/UndoItem.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (240314 => 240315)
--- trunk/Source/WebCore/ChangeLog 2019-01-23 01:46:01 UTC (rev 240314)
+++ trunk/Source/WebCore/ChangeLog 2019-01-23 02:06:53 UTC (rev 240315)
@@ -1,3 +1,67 @@
+2019-01-22 Wenson Hsieh
+
+Add some bindings-related bookkeeping to UndoManager and UndoItem
+https://bugs.webkit.org/show_bug.cgi?id=193111
+
+
+Reviewed by Ryosuke Niwa.
+
+This patch is work in progress towards supporting `UndoManager.addItem()`. Here, we add helper methods to
+UndoItem and UndoManager which later patches will exercise, as well as introduce some custom bindings to
+properly handle the case where UndoItems are given anonymous _javascript_ functions (see below for more details).
+
+No new tests, because there is no script-observable change in behavior yet. When `addItems()` is hooked up, I
+will write a test to verify that the undo and redo _javascript_ functions survive garbage collection.
+
+* Sources.txt:
+* WebCore.xcodeproj/project.pbxproj:
+* bindings/js/JSUndoItemCustom.cpp:
+(WebCore::JSUndoItem::visitAdditionalChildren):
+
+Have each JSUndoItem visit its undo and redo callback functions to ensure that the _javascript_ wrapper objects
+for these functions are not garbage collected underneath the item.
+
+(WebCore::JSUndoItemOwner::isReachableFromOpaqueRoots):
+
+Consider the undo item wrapper reachable from opaque roots if it is associated with its UndoManager's Document.
+This ensures that if script
[webkit-changes] [240352] trunk
Title: [240352] trunk
Revision 240352
Author wenson_hs...@apple.com
Date 2019-01-23 12:09:54 -0800 (Wed, 23 Jan 2019)
Log Message
[iOS] fast/events/touch/ios/hover-when-style-change-is-async.html times out
https://bugs.webkit.org/show_bug.cgi?id=193182
Reviewed by Tim Horton.
Source/WebKit:
Fix an existing bug where blurring an element doesn't always un-suppress text interactions.
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _elementDidBlur]):
Tools:
This test was timing out because one of its preceding tests (drag-to-autoscroll-in-single-line-editable.html)
long presses and drags to select text, but does not end the touch by lifting up; subsequently, the tap gesture
recognizer isn't fired when simulating a tap in hover-when-style-change-is-async.html.
To fix this, tweak the test runner to make it safe for tests to end while touching the web view without
preventing later tests from recognizing gestures.
* WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
Cancel all touches in the UIApplication when resetting to a consistent state between tests.
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
trunk/Tools/ChangeLog
trunk/Tools/WebKitTestRunner/ios/TestControllerIOS.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (240351 => 240352)
--- trunk/Source/WebKit/ChangeLog 2019-01-23 19:29:18 UTC (rev 240351)
+++ trunk/Source/WebKit/ChangeLog 2019-01-23 20:09:54 UTC (rev 240352)
@@ -1,3 +1,16 @@
+2019-01-23 Wenson Hsieh
+
+[iOS] fast/events/touch/ios/hover-when-style-change-is-async.html times out
+https://bugs.webkit.org/show_bug.cgi?id=193182
+
+
+Reviewed by Tim Horton.
+
+Fix an existing bug where blurring an element doesn't always un-suppress text interactions.
+
+* UIProcess/ios/WKContentViewInteraction.mm:
+(-[WKContentView _elementDidBlur]):
+
2019-01-23 Michael Catanzaro
Minor improvements to NetworkProcess
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (240351 => 240352)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-01-23 19:29:18 UTC (rev 240351)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-01-23 20:09:54 UTC (rev 240352)
@@ -4660,6 +4660,7 @@
if (!_isChangingFocus) {
[self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTransparentOrFullyClipped];
+[self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTooSmall];
_didAccessoryTabInitiateFocus = NO;
}
}
Modified: trunk/Tools/ChangeLog (240351 => 240352)
--- trunk/Tools/ChangeLog 2019-01-23 19:29:18 UTC (rev 240351)
+++ trunk/Tools/ChangeLog 2019-01-23 20:09:54 UTC (rev 240352)
@@ -1,3 +1,23 @@
+2019-01-23 Wenson Hsieh
+
+[iOS] fast/events/touch/ios/hover-when-style-change-is-async.html times out
+https://bugs.webkit.org/show_bug.cgi?id=193182
+
+
+Reviewed by Tim Horton.
+
+This test was timing out because one of its preceding tests (drag-to-autoscroll-in-single-line-editable.html)
+long presses and drags to select text, but does not end the touch by lifting up; subsequently, the tap gesture
+recognizer isn't fired when simulating a tap in hover-when-style-change-is-async.html.
+
+To fix this, tweak the test runner to make it safe for tests to end while touching the web view without
+preventing later tests from recognizing gestures.
+
+* WebKitTestRunner/ios/TestControllerIOS.mm:
+(WTR::TestController::platformResetStateToConsistentValues):
+
+Cancel all touches in the UIApplication when resetting to a consistent state between tests.
+
2019-01-23 Jonathan Bedard
webkitpy: Use correct config for --iphone-simulator and --ipad-simulator
Modified: trunk/Tools/WebKitTestRunner/ios/TestControllerIOS.mm (240351 => 240352)
--- trunk/Tools/WebKitTestRunner/ios/TestControllerIOS.mm 2019-01-23 19:29:18 UTC (rev 240351)
+++ trunk/Tools/WebKitTestRunner/ios/TestControllerIOS.mm 2019-01-23 20:09:54 UTC (rev 240352)
@@ -115,6 +115,7 @@
{
cocoaResetStateToConsistentValues(options);
+[[UIApplication sharedApplication] _cancelAllTouches];
[[UIDevice currentDevice] setOrientation:UIDeviceOrientationPortrait animated:NO];
m_inputModeSwizzlers.clear();
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [240342] trunk/Source
Title: [240342] trunk/Source Revision 240342 Author wenson_hs...@apple.com Date 2019-01-23 09:30:05 -0800 (Wed, 23 Jan 2019) Log Message Introduce UndoStep::label() and adopt it in WebKitLegacy and WebKit https://bugs.webkit.org/show_bug.cgi?id=193706 Reviewed by Ryosuke Niwa. Source/WebCore: Refactors some existing logic when registering undoable actions, such that we propagate the undoable action's label string instead of the EditAction to the client layer. This will help make handling of CustomUndoStep's undo/redo label simpler, as the client layer won't need to worry about managing an EditAction and undo/redo label simultaneously. There should be no change in behavior. * editing/CompositeEditCommand.cpp: (WebCore::EditCommandComposition::label const): * editing/CompositeEditCommand.h: * editing/CustomUndoStep.cpp: (WebCore::CustomUndoStep::label const): * editing/CustomUndoStep.h: * editing/EditAction.cpp: (WebCore::undoRedoLabel): (WebCore::nameForUndoRedo): Deleted. * editing/EditAction.h: Rename nameForUndoRedo to undoRedoLabel, and remove the WEBCORE_EXPORT since it's no longer needed in WebKit or WebKitLegacy. * editing/UndoStep.h: Add UndoStep::label(). While EditCommandComposition implements this by mapping its EditAction to a localized string, CustomUndoStep implements this by returning the undoable action label provided by script. Source/WebKit: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::registerEditCommand): * UIProcess/WebEditCommandProxy.cpp: (WebKit::WebEditCommandProxy::WebEditCommandProxy): * UIProcess/WebEditCommandProxy.h: Drive-by tweak: make WebEditCommandProxy's backpointer to its WebPageProxy a WeakPtr instead of a raw pointer. Additionally, call clear() instead of setting m_page to 0 upon invalidation. Also, turn the WebPageProxy* argument into a WebPageProxy&, since the WebPageProxy must exist when it creates a new WebEditCommandProxy. (WebKit::WebEditCommandProxy::create): (WebKit::WebEditCommandProxy::label const): (WebKit::WebEditCommandProxy::invalidate): (WebKit::WebEditCommandProxy::editAction const): Deleted. Adjust UI-side logic to just handle the undo/redo label, rather than map the edit action to a localized string. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::registerEditCommandForUndo): (WebKit::WebPageProxy::resetState): Tweak this to use std::exchange instead of copying all the WebEditCommandProxy RefPtrs into a separate Vector and then iterating over the Vector. * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: Adjust this so that we only send the undo/redo label over IPC, rather than the edit action type. * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::registerEditCommand): * WebProcess/WebCoreSupport/WebEditorClient.cpp: (WebKit::WebEditorClient::registerUndoStep): Source/WebKitLegacy/mac: Use UndoStep::label(). * WebCoreSupport/WebEditorClient.h: * WebCoreSupport/WebEditorClient.mm: (-[WebUndoStep initWithUndoStep:]): (+[WebUndoStep stepWithUndoStep:]): (WebEditorClient::registerUndoOrRedoStep): (WebEditorClient::registerUndoStep): (WebEditorClient::registerRedoStep): Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/CompositeEditCommand.cpp trunk/Source/WebCore/editing/CompositeEditCommand.h trunk/Source/WebCore/editing/CustomUndoStep.cpp trunk/Source/WebCore/editing/CustomUndoStep.h trunk/Source/WebCore/editing/EditAction.cpp trunk/Source/WebCore/editing/EditAction.h trunk/Source/WebCore/editing/UndoStep.h trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm trunk/Source/WebKit/UIProcess/WebEditCommandProxy.cpp trunk/Source/WebKit/UIProcess/WebEditCommandProxy.h trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/WebPageProxy.messages.in trunk/Source/WebKit/UIProcess/ios/PageClientImplIOS.mm trunk/Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp trunk/Source/WebKitLegacy/mac/ChangeLog trunk/Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.mm Diff Modified: trunk/Source/WebCore/ChangeLog (240341 => 240342) --- trunk/Source/WebCore/ChangeLog 2019-01-23 17:26:50 UTC (rev 240341) +++ trunk/Source/WebCore/ChangeLog 2019-01-23 17:30:05 UTC (rev 240342) @@ -1,3 +1,35 @@ +2019-01-23 Wenson Hsieh + +Introduce UndoStep::label() and adopt it in WebKitLegacy and WebKit +https://bugs.webkit.org/show_bug.cgi?id=193706 + + +Reviewed by Ryosuke Niwa. + +Refactors some existing logic when registering undoable actions, such that we propagate the undoable action's +label string instead of the EditAction to the client layer. This will help make handling of CustomUndoStep's +undo/redo label simpler, as the client layer won't need to worry about managing an EditAction and undo/redo +label simultaneously. There should be no change in behavior. + +* editing/CompositeEditCommand.cpp:
[webkit-changes] [240139] trunk
Title: [240139] trunk Revision 240139 Author wenson_hs...@apple.com Date 2019-01-17 20:15:24 -0800 (Thu, 17 Jan 2019) Log Message [iOS] Content offset jumps erratically when autoscrolling near scroll view content inset areas https://bugs.webkit.org/show_bug.cgi?id=193494 Reviewed by Simon Fraser and Tim Horton. Source/WebCore: When computing the content offset to scroll to when revealing a given rect in content coordinates, we currently just use the unobscured content rect. As a result, when scrolling to reveal a rect, we'll clamp the final scroll position such that only content is visible. For example, when asked to reveal the rect `(0, 0, 1, 1)`, we adjust the scroll position to be the origin. However, consider the case where a client (e.g. Mail on iOS) has added a content inset to the web view's scroll view. If we're asked to reveal a rect that is outside the content area but within a content inset, we will still end up clamping the scroll position to the unobscured rect. This manifests in a bug where selecting text and autoscrolling in iOS Mail compose while the scroll view is scrolled all the way to the top to reveal the To/Cc/ Subject fields causes the content offset to jump to the origin, rather than staying at (0, -topContentInset). To fix this, we teach `RenderLayer::scrollRectToVisible` about content insets that are visible. Rather than use the content rects as-is, expand to encompass visible content insets as well. This ensures that revealing a position which is already visible won't cause us to scroll away the content inset area and only show the unobscured rect. Tests: editing/selection/ios/autoscroll-with-top-content-inset.html fast/scrolling/ios/scroll-into-view-with-top-content-inset.html * page/FrameView.cpp: (WebCore::FrameView::unobscuredContentRectExpandedByContentInsets const): Introduce a helper method that expands the unobscured content rect to include surrounding content insets. * page/FrameView.h: * page/Page.h: (WebCore::Page::contentInsets const): (WebCore::Page::setContentInsets): * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): (WebCore::RenderLayer::getRectToExpose const): Source/WebKit: Adds `contentInsets` to `VisibleContentRectUpdateInfo`. This keeps track of the visible content insets surrounding the unobscured content rect. See WebCore ChangeLog for more details. * Shared/VisibleContentRectUpdateInfo.cpp: (WebKit::VisibleContentRectUpdateInfo::encode const): (WebKit::VisibleContentRectUpdateInfo::decode): (WebKit::operator<<): * Shared/VisibleContentRectUpdateInfo.h: (WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo): (WebKit::VisibleContentRectUpdateInfo::contentInsets const): (WebKit::operator==): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _computedObscuredInset]): (-[WKWebView _computedContentInset]): (-[WKWebView _computedUnobscuredSafeAreaInset]): We don't care about source compatibility with iOS 10 and below anymore, so we should change these >= iOS 11 target checks to simply `PLATFORM(IOS)`. (-[WKWebView _updateVisibleContentRects]): Compute the visible content insets on all sides of the unobscured content rect. These insets are scaled to content coordinates. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (floatBoxExtent): Add a helper to convert `UIEdgeInsets` to `WebCore::FloatBoxExtent`, and use it in a few places below. (-[WKContentView didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): (-[WKContentView didUpdateVisibleRect:unobscuredRect:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): Deleted. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateVisibleContentRects): Update the Page's content insets. Tools: Add a new test option to add a top content inset to the test runner's WKWebView's scroll view, and automatically scroll to reveal this top content inset area when beginning the test (i.e., scroll to (0, -topContentInset)). * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::contentOffsetX const): (WTR::UIScriptController::contentOffsetY const): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::contentOffsetX const): (WTR::UIScriptController::contentOffsetY const): * TestRunnerShared/UIScriptContext/UIScriptController.h: Also add new UIScriptController methods to ask for the content offset of the platform scroll view. * WebKitTestRunner/TestController.cpp: (WTR::updateTestOptionsFromTestHeader): * WebKitTestRunner/TestOptions.h:
[webkit-changes] [240328] trunk/Source/WebCore
Title: [240328] trunk/Source/WebCore
Revision 240328
Author wenson_hs...@apple.com
Date 2019-01-22 22:10:45 -0800 (Tue, 22 Jan 2019)
Log Message
Introduce CustomUndoStep.h and CustomUndoStep.cpp
https://bugs.webkit.org/show_bug.cgi?id=193704
Reviewed by Ryosuke Niwa.
This patch is more work in progress towards supporting `UndoManager.addItem()`. Here, we introduce a helper
class, CustomUndoStep, that holds a weak reference to a script-defined UndoItem. See below for more details.
No change in behavior.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* editing/CustomUndoStep.cpp:
(WebCore::CustomUndoStep::CustomUndoStep):
Subclass UndoStep.
(WebCore::CustomUndoStep::unapply):
(WebCore::CustomUndoStep::reapply):
If possible, invoke the UndoItem's undo and redo handlers.
(WebCore::CustomUndoStep::isValid const):
* editing/CustomUndoStep.h:
* editing/EditingStyle.cpp:
* editing/InsertEditableImageCommand.cpp:
(WebCore::InsertEditableImageCommand::doApply):
Unified build fixes.
* page/UndoItem.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Sources.txt
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
trunk/Source/WebCore/editing/EditingStyle.cpp
trunk/Source/WebCore/editing/InsertEditableImageCommand.cpp
trunk/Source/WebCore/page/UndoItem.h
Added Paths
trunk/Source/WebCore/editing/CustomUndoStep.cpp
trunk/Source/WebCore/editing/CustomUndoStep.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (240327 => 240328)
--- trunk/Source/WebCore/ChangeLog 2019-01-23 05:55:08 UTC (rev 240327)
+++ trunk/Source/WebCore/ChangeLog 2019-01-23 06:10:45 UTC (rev 240328)
@@ -1,3 +1,38 @@
+2019-01-22 Wenson Hsieh
+
+Introduce CustomUndoStep.h and CustomUndoStep.cpp
+https://bugs.webkit.org/show_bug.cgi?id=193704
+
+
+Reviewed by Ryosuke Niwa.
+
+This patch is more work in progress towards supporting `UndoManager.addItem()`. Here, we introduce a helper
+class, CustomUndoStep, that holds a weak reference to a script-defined UndoItem. See below for more details.
+
+No change in behavior.
+
+* Sources.txt:
+* WebCore.xcodeproj/project.pbxproj:
+* editing/CustomUndoStep.cpp:
+(WebCore::CustomUndoStep::CustomUndoStep):
+
+Subclass UndoStep.
+
+(WebCore::CustomUndoStep::unapply):
+(WebCore::CustomUndoStep::reapply):
+
+If possible, invoke the UndoItem's undo and redo handlers.
+
+(WebCore::CustomUndoStep::isValid const):
+* editing/CustomUndoStep.h:
+* editing/EditingStyle.cpp:
+* editing/InsertEditableImageCommand.cpp:
+(WebCore::InsertEditableImageCommand::doApply):
+
+Unified build fixes.
+
+* page/UndoItem.h:
+
2019-01-22 Simon Fraser
Adding a child to a ScrollingStateNode needs to trigger a tree state commit
Modified: trunk/Source/WebCore/Sources.txt (240327 => 240328)
--- trunk/Source/WebCore/Sources.txt 2019-01-23 05:55:08 UTC (rev 240327)
+++ trunk/Source/WebCore/Sources.txt 2019-01-23 06:10:45 UTC (rev 240328)
@@ -952,6 +952,7 @@
editing/ChangeListTypeCommand.cpp
editing/CompositeEditCommand.cpp
editing/CreateLinkCommand.cpp
+editing/CustomUndoStep.cpp
editing/DeleteFromTextNodeCommand.cpp
editing/DeleteSelectionCommand.cpp
editing/DictationAlternative.cpp
Modified: trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj (240327 => 240328)
--- trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2019-01-23 05:55:08 UTC (rev 240327)
+++ trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2019-01-23 06:10:45 UTC (rev 240328)
@@ -15131,6 +15131,8 @@
F4D9817E2195FBF6008230FC /* ChangeListTypeCommand.cpp */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.cpp.cpp; path = ChangeListTypeCommand.cpp; sourceTree = ""; };
F4E1965A21F2395000285078 /* JSUndoItemCustom.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = JSUndoItemCustom.cpp; sourceTree = ""; };
F4E1965F21F26E4E00285078 /* UndoItem.cpp */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.cpp.cpp; path = UndoItem.cpp; sourceTree = ""; };
+ F4E1966121F27D3C00285078 /* CustomUndoStep.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = CustomUndoStep.h; sourceTree = ""; };
+ F4E1966221F27D3D00285078 /* CustomUndoStep.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = CustomUndoStep.cpp; sourceTree = ""; };
F4E57EDA213F3F5F004EA98E /* FontAttributeChanges.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; path = FontAttributeChanges.h; sourceTree = ""; };
F4E57EDF213F434A004EA98E /* WebCoreNSFontManagerExtras.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; path = WebCoreNSFontManagerExtras.h; sourceTree = ""; };
F4E57EE0213F434A004EA98E /* WebCoreNSFontManagerExtras.mm */ = {isa = PBXFileReference;
[webkit-changes] [239107] trunk/Source/WebCore
Title: [239107] trunk/Source/WebCore
Revision 239107
Author wenson_hs...@apple.com
Date 2018-12-12 09:06:49 -0800 (Wed, 12 Dec 2018)
Log Message
[iOS] A few API tests are failing after r239086
https://bugs.webkit.org/show_bug.cgi?id=192608
Reviewed by Zalan Bujtas.
These test failures were caused by a missing Vector size check in `Pasteboard::readFilePaths` before accessing
the first item. Fix this by adding a helper method on PasteboardItemInfo to grab the file path for the highest
fidelity pasteboard item (returning the null string if there are none), and use this in a few places that grab
the highest fidelity path using Vector::first().
While `Pasteboard::readRespectingUTIFidelities` does have a bounds check before accessing the list of paths,
this patch still replaces it with a call to `pathForHighestFidelityItem()`, so that the intent is more clear.
* platform/PasteboardItemInfo.h:
(WebCore::PasteboardItemInfo::pathForHighestFidelityItem const):
* platform/ios/PasteboardIOS.mm:
(WebCore::Pasteboard::readRespectingUTIFidelities):
(WebCore::Pasteboard::readFilePaths):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/PasteboardItemInfo.h
trunk/Source/WebCore/platform/ios/PasteboardIOS.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (239106 => 239107)
--- trunk/Source/WebCore/ChangeLog 2018-12-12 17:05:41 UTC (rev 239106)
+++ trunk/Source/WebCore/ChangeLog 2018-12-12 17:06:49 UTC (rev 239107)
@@ -1,3 +1,24 @@
+2018-12-12 Wenson Hsieh
+
+[iOS] A few API tests are failing after r239086
+https://bugs.webkit.org/show_bug.cgi?id=192608
+
+Reviewed by Zalan Bujtas.
+
+These test failures were caused by a missing Vector size check in `Pasteboard::readFilePaths` before accessing
+the first item. Fix this by adding a helper method on PasteboardItemInfo to grab the file path for the highest
+fidelity pasteboard item (returning the null string if there are none), and use this in a few places that grab
+the highest fidelity path using Vector::first().
+
+While `Pasteboard::readRespectingUTIFidelities` does have a bounds check before accessing the list of paths,
+this patch still replaces it with a call to `pathForHighestFidelityItem()`, so that the intent is more clear.
+
+* platform/PasteboardItemInfo.h:
+(WebCore::PasteboardItemInfo::pathForHighestFidelityItem const):
+* platform/ios/PasteboardIOS.mm:
+(WebCore::Pasteboard::readRespectingUTIFidelities):
+(WebCore::Pasteboard::readFilePaths):
+
2018-12-12 Carlos Garcia Campos
Unreviewed. Fix WPE build after r239101.
Modified: trunk/Source/WebCore/platform/PasteboardItemInfo.h (239106 => 239107)
--- trunk/Source/WebCore/platform/PasteboardItemInfo.h 2018-12-12 17:05:41 UTC (rev 239106)
+++ trunk/Source/WebCore/platform/PasteboardItemInfo.h 2018-12-12 17:06:49 UTC (rev 239107)
@@ -55,6 +55,15 @@
return pathsForFileUpload[index];
}
+String pathForHighestFidelityItem() const
+{
+if (pathsForFileUpload.isEmpty())
+return { };
+
+ASSERT(!pathsForFileUpload.first().isEmpty());
+return pathsForFileUpload.first();
+}
+
template void encode(Encoder&) const;
template static std::optional decode(Decoder&);
};
Modified: trunk/Source/WebCore/platform/ios/PasteboardIOS.mm (239106 => 239107)
--- trunk/Source/WebCore/platform/ios/PasteboardIOS.mm 2018-12-12 17:05:41 UTC (rev 239106)
+++ trunk/Source/WebCore/platform/ios/PasteboardIOS.mm 2018-12-12 17:06:49 UTC (rev 239107)
@@ -294,9 +294,10 @@
for (NSUInteger index = 0, numberOfItems = strategy.getPasteboardItemsCount(m_pasteboardName); index < numberOfItems; ++index) {
#if ENABLE(ATTACHMENT_ELEMENT)
auto info = strategy.informationForItemAtIndex(index, m_pasteboardName);
-bool canReadAttachment = policy == WebContentReadingPolicy::AnyType && RuntimeEnabledFeatures::sharedFeatures().attachmentElementEnabled() && !info.pathsForFileUpload.isEmpty();
+auto attachmentFilePath = info.pathForHighestFidelityItem();
+bool canReadAttachment = policy == WebContentReadingPolicy::AnyType && RuntimeEnabledFeatures::sharedFeatures().attachmentElementEnabled() && !attachmentFilePath.isEmpty();
if (canReadAttachment && info.preferredPresentationStyle == PasteboardItemPresentationStyle::Attachment) {
-reader.readFilePaths({ info.pathsForFileUpload.first() });
+reader.readFilePaths({ WTFMove(attachmentFilePath) });
continue;
}
#endif
@@ -317,7 +318,7 @@
}
#if ENABLE(ATTACHMENT_ELEMENT)
if (canReadAttachment && result == ReaderResult::DidNotReadType)
-reader.readFilePaths({ info.pathsForFileUpload.first() });
+reader.readFilePaths({ WTFMove(attachmentFilePath) });
#endif
}
}
@@ -459,7 +460,7 @@
auto& strategy =
[webkit-changes] [239039] trunk
Title: [239039] trunk Revision 239039 Author wenson_hs...@apple.com Date 2018-12-10 12:27:59 -0800 (Mon, 10 Dec 2018) Log Message [iOS] Caret is obscured by finger when dragging over an editable element https://bugs.webkit.org/show_bug.cgi?id=192499 Reviewed by Tim Horton. Source/WebCore: * page/DragActions.h: Move DragHandlingMethod to DragActions.h, and drive-by fix some minor issues (i.e. make a couple of enum classes use 8 bits, fix the indentation levels, and update the copyright year). Also add `EnumTraits` for DragHandlingMethod so that it may be encoded over IPC. * page/DragController.cpp: (WebCore::dragIsHandledByDocument): Simplify this helper function. (WebCore::DragController::tryDocumentDrag): * page/DragController.h: Expose the current DragHandlingMethod via a const getter method. (WebCore::DragController::dragHandlingMethod const): Source/WebKit: Add support for setting the `precise` property of `UIDropProposal` to YES when dragging over an editable area. When enabled, this property shifts the drop location up by a small amount, allowing the user to see the drop caret (currently, this is not the case, and it's difficult to drop text at a precise location on iOS). Changes are covered by adding to existing API tests. * Scripts/webkit/messages.py: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: Add a new version of `-_webView:willUpdateDataInteractionOperationToOperation:forSession:` that receives and returns a UIDropProposal, so that Mail can more easily port over existing logic in its legacy-WebKit-based compose implementation. iOS Safari is currently the only client of this private delegate, so the old version can be easily removed once Safari adopts this new version. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didPerformDragControllerAction): Add plumbing to send the latest drag handling method from WebPage to WebPageProxy. (WebKit::WebPageProxy::resetCurrentDragInformation): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::currentDragHandlingMethod const): * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dropInteraction:sessionDidUpdate:]): Call the new UI delegate hook when determining the drop proposal to return to UIKit. Additionally set the `precise` bit on the drop proposal in the case where the drop handling method is either "editing rich text" or "editing plain text". * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::performDragControllerAction): * WebProcess/WebPage/WebPage.h: Tools: Augment some existing API tests to check that the `precise` flag is either on or off on `UIDropProposal`. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm: (-[DragAndDropSimulator _resetSimulatedState]): (-[DragAndDropSimulator lastKnownDropProposal]): Rename `currentDropProposal` to `lastKnownDropProposal`, and expose it as a readonly property. (-[DragAndDropSimulator _concludeDropAndPerformOperationIfNecessary]): (-[DragAndDropSimulator _advanceProgress]): (-[DragAndDropSimulator setShowCustomActionSheetBlock:]): (-[DragAndDropSimulator showCustomActionSheetBlock]): (-[DragAndDropSimulator setConvertItemProvidersBlock:]): (-[DragAndDropSimulator convertItemProvidersBlock]): (-[DragAndDropSimulator setOverridePerformDropBlock:]): (-[DragAndDropSimulator overridePerformDropBlock]): (-[DragAndDropSimulator setOverrideDragUpdateBlock:]): (-[DragAndDropSimulator overrideDragUpdateBlock]): (-[DragAndDropSimulator setDropCompletionBlock:]): (-[DragAndDropSimulator dropCompletionBlock]): Refactor these properties to return and take normal Objective-C blocks, rather than `BlockPtr`s. However, use `BlockPtr` instance variables to manage the lifetimes of these blocks. (-[DragAndDropSimulator _webView:willUpdateDropProposalToProposal:forSession:]): (-[DragAndDropSimulator _webView:willUpdateDataInteractionOperationToOperation:forSession:]): Deleted. Update this to use the new WebKit delegate hook for overriding the drop proposal. Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/page/DragActions.h trunk/Source/WebCore/page/DragController.cpp trunk/Source/WebCore/page/DragController.h trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Scripts/webkit/messages.py trunk/Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/UIProcess/WebPageProxy.messages.in trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm trunk/Tools/TestWebKitAPI/cocoa/DragAndDropSimulator.h trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm Diff Modified: trunk/Source/WebCore/ChangeLog (239038 => 239039) ---
[webkit-changes] [239184] trunk
Title: [239184] trunk Revision 239184 Author wenson_hs...@apple.com Date 2018-12-13 15:25:20 -0800 (Thu, 13 Dec 2018) Log Message [iOS] Support dropping contact card data (public.vcard) in editable content https://bugs.webkit.org/show_bug.cgi?id=192570 Reviewed by Tim Horton. Source/WebCore: Adds support for accepting vCard (.vcf) data via drop on iOS. See below for more details. Tests: DragAndDropTests.ExternalSourceContactIntoEditableAreas DragAndDropTests.ExternalSourceMapItemAndContactToUploadArea DragAndDropTests.ExternalSourceMapItemIntoEditableAreas WKAttachmentTestsIOS.InsertDroppedContactAsAttachment WKAttachmentTestsIOS.InsertDroppedMapItemAsAttachment * editing/WebContentReader.h: * editing/cocoa/WebContentReaderCocoa.mm: (WebCore::attachmentForFilePath): Pull out logic to create an attachment from a file path out into a static helper. Use this in `readFilePaths` as well as `readVirtualContactFile`. (WebCore::WebContentReader::readFilePaths): (WebCore::WebContentReader::readVirtualContactFile): Add a pasteboard reading method that reads a vCard file (with an optional URL) as web content. The resulting fragment consists of either an anchor and an attachment element, or just an attachment element if the URL is empty. In the case of an `MKMapItem`, the URL is populated, so we generate both elements; when dragging a contact, there is no associated URL, so we only have an attachment. * platform/Pasteboard.h: * platform/ios/PasteboardIOS.mm: (WebCore::Pasteboard::readPasteboardWebContentDataForType): Augment this to take the current `PasteboardItemInfo` as well; use this item information to get a file path for "public.vcard" data, which is then passed on to the web content reader. Additionally, by returning `ReaderResult::DidNotReadType` here, we prevent the web content reader from extracting the plain text contents of the vCard and dumping it as plain text in the editable element (this would otherwise happen, since "public.vcard" conforms to "public.text"). (WebCore::Pasteboard::read): (WebCore::Pasteboard::readRespectingUTIFidelities): * platform/ios/WebItemProviderPasteboard.mm: (-[NSItemProvider web_fileUploadContentTypes]): Prevent the "com.apple.mapkit.map-item" UTI from being considered as file upload content. This special case is tricky, since "com.apple.mapkit.map-item" conforms to "public.content", yet its corresponding data is only suitable for deserialization into an `MKMapItem`. Tools: * TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm: Add API tests to verify that registering `MKMapItem`s and `CNContact`s to item providers and dropping them in attachment-enabled rich text editable areas inserts attachment elements (and in the case of `MKMapItem`, additionally inserts a link). * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (TestWebKitAPI::createMapItemForTesting): (TestWebKitAPI::createContactItemForTesting): Add API tests to verify that dropping map items and contact items into rich and plain editable areas behaves as expected (in the case where a URL is present, e.g. dropping a map item, we insert the URL as an anchor, and when there is no other suitable representation in the item provider, we do nothing at all, which is the case for the dropped `CNContact`). Also, add a test to verify that drag and drop can be used to upload these items as .vcf files. Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/WebContentReader.h trunk/Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm trunk/Source/WebCore/platform/Pasteboard.h trunk/Source/WebCore/platform/ios/PasteboardIOS.mm trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm Diff Modified: trunk/Source/WebCore/ChangeLog (239183 => 239184) --- trunk/Source/WebCore/ChangeLog 2018-12-13 23:20:35 UTC (rev 239183) +++ trunk/Source/WebCore/ChangeLog 2018-12-13 23:25:20 UTC (rev 239184) @@ -1,3 +1,53 @@ +2018-12-13 Wenson Hsieh + +[iOS] Support dropping contact card data (public.vcard) in editable content +https://bugs.webkit.org/show_bug.cgi?id=192570 + + +Reviewed by Tim Horton. + +Adds support for accepting vCard (.vcf) data via drop on iOS. See below for more details. + +Tests: DragAndDropTests.ExternalSourceContactIntoEditableAreas +DragAndDropTests.ExternalSourceMapItemAndContactToUploadArea +DragAndDropTests.ExternalSourceMapItemIntoEditableAreas +WKAttachmentTestsIOS.InsertDroppedContactAsAttachment +WKAttachmentTestsIOS.InsertDroppedMapItemAsAttachment + +* editing/WebContentReader.h: +* editing/cocoa/WebContentReaderCocoa.mm: +(WebCore::attachmentForFilePath): + +Pull out logic to create an attachment from a file path out into a static
[webkit-changes] [239314] trunk
Title: [239314] trunk Revision 239314 Author wenson_hs...@apple.com Date 2018-12-17 20:04:44 -0800 (Mon, 17 Dec 2018) Log Message [iOS] Focusing a large editable element always scrolls to the top of the element https://bugs.webkit.org/show_bug.cgi?id=192745 Reviewed by Tim Horton. Source/WebKit: Currently, when focusing form controls or editable elements, we try to scroll such that the focused element rect is centered within the visible area. In the case of very large focusable elements whose dimensions exceed the width or height of the visible area, we instead scroll such that the top left point of the element is at the top left corner of the visible area. However, this results in unnecessary scrolling if the top of the element is already near the top of the visible area. For WebKit2-based rich text editors that have an editable body element with a top content inset that contains additional content, this means we will always scroll the additional content away when focusing the editable body. To avoid this behavior, adjust focused element zooming logic for editable elements that are too large to be centered in the visible area, such that we only scroll the top left position of the focused element to the top half or top right of the visible area, respectively. This reduces the amount of scrolling when focusing large editable elements, while still making it clear which element is being focused. * Platform/spi/ios/UIKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): Make some small adjustments to improve the readability of this method by using `clampTo` instead of clamping values by comparing and setting values. Also, fix an existing bug wherein focusable elements that are meant to be centered within the visible area are currently offset by half the difference between the bottom inset amount and the top inset amount, in the case where the `_obscuredInsets` SPI is used to specify content insets for the web view (i.e., MobileSafari). * UIProcess/API/Cocoa/WKWebViewInternal.h: Make a couple of arguments `const FloatRect&` instead of just `FloatRect`. LayoutTests: Add a new layout test to verify that we don't scroll unnecessarily when focusing a tall editable element, whose top offset is already near the top of the viewport. * editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt: Added. * editing/selection/ios/no-scrolling-when-focusing-large-editable-area.html: Added. Modified Paths trunk/LayoutTests/ChangeLog trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h Added Paths trunk/LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt trunk/LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area.html Diff Modified: trunk/LayoutTests/ChangeLog (239313 => 239314) --- trunk/LayoutTests/ChangeLog 2018-12-18 03:52:53 UTC (rev 239313) +++ trunk/LayoutTests/ChangeLog 2018-12-18 04:04:44 UTC (rev 239314) @@ -1,3 +1,17 @@ +2018-12-17 Wenson Hsieh + +[iOS] Focusing a large editable element always scrolls to the top of the element +https://bugs.webkit.org/show_bug.cgi?id=192745 + + +Reviewed by Tim Horton. + +Add a new layout test to verify that we don't scroll unnecessarily when focusing a tall editable element, whose +top offset is already near the top of the viewport. + +* editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt: Added. +* editing/selection/ios/no-scrolling-when-focusing-large-editable-area.html: Added. + 2018-12-17 Ryosuke Niwa offsetLeft and offsetParent should adjust across shadow boundaries Added: trunk/LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt (0 => 239314) --- trunk/LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt (rev 0) +++ trunk/LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt 2018-12-18 04:04:44 UTC (rev 239314) @@ -0,0 +1,6 @@ +Here's to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They're not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can't do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. + +This test verifies that we avoid unnecessary scrolling when focusing
[webkit-changes] [239318] trunk/Source/WebKit
Title: [239318] trunk/Source/WebKit
Revision 239318
Author wenson_hs...@apple.com
Date 2018-12-17 21:23:10 -0800 (Mon, 17 Dec 2018)
Log Message
Unreviewed, fix the iOSMac engineering build again
After r239311, `WebProcessProxy::fullKeyboardAccessEnabled` in `WebProcessProxyIOS.mm` attempts to use
`WKFullKeyboardAccessWatcher`, which is guarded by `ENABLE(FULL_KEYBOARD_ACCESS)`. However, on iOSMac,
`ENABLE(FULL_KEYBOARD_ACCESS)` is 0. Fix the build by putting access to `WKFullKeyboardAccessWatcher` behind
`ENABLE(FULL_KEYBOARD_ACCESS)`.
* UIProcess/ios/WebProcessProxyIOS.mm:
(WebKit::WebProcessProxy::fullKeyboardAccessEnabled):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/ios/WebProcessProxyIOS.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (239317 => 239318)
--- trunk/Source/WebKit/ChangeLog 2018-12-18 04:39:35 UTC (rev 239317)
+++ trunk/Source/WebKit/ChangeLog 2018-12-18 05:23:10 UTC (rev 239318)
@@ -1,5 +1,17 @@
2018-12-17 Wenson Hsieh
+Unreviewed, fix the iOSMac engineering build again
+
+After r239311, `WebProcessProxy::fullKeyboardAccessEnabled` in `WebProcessProxyIOS.mm` attempts to use
+`WKFullKeyboardAccessWatcher`, which is guarded by `ENABLE(FULL_KEYBOARD_ACCESS)`. However, on iOSMac,
+`ENABLE(FULL_KEYBOARD_ACCESS)` is 0. Fix the build by putting access to `WKFullKeyboardAccessWatcher` behind
+`ENABLE(FULL_KEYBOARD_ACCESS)`.
+
+* UIProcess/ios/WebProcessProxyIOS.mm:
+(WebKit::WebProcessProxy::fullKeyboardAccessEnabled):
+
+2018-12-17 Wenson Hsieh
+
Unreviewed, fix the iOSMac engineering build
`generateRequestID()` is only invoked from code under `ENABLE(MEDIA_STREAM)`; move it under this guard to avoid
Modified: trunk/Source/WebKit/UIProcess/ios/WebProcessProxyIOS.mm (239317 => 239318)
--- trunk/Source/WebKit/UIProcess/ios/WebProcessProxyIOS.mm 2018-12-18 04:39:35 UTC (rev 239317)
+++ trunk/Source/WebKit/UIProcess/ios/WebProcessProxyIOS.mm 2018-12-18 05:23:10 UTC (rev 239318)
@@ -35,7 +35,11 @@
bool WebProcessProxy::fullKeyboardAccessEnabled()
{
+#if ENABLE(FULL_KEYBOARD_ACCESS)
return [WKFullKeyboardAccessWatcher fullKeyboardAccessEnabled];
+#else
+return NO;
+#endif
}
} // namespace WebKit
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239321] trunk/Source/WebKit
Title: [239321] trunk/Source/WebKit
Revision 239321
Author wenson_hs...@apple.com
Date 2018-12-17 22:30:34 -0800 (Mon, 17 Dec 2018)
Log Message
Tap highlights should not be shown on iOSMac
https://bugs.webkit.org/show_bug.cgi?id=192797
Reviewed by Tim Horton.
WKWebViews in iOSMac should avoid painting tap highlights, since tap highlights are not present in the rest of
the macOS platform. Simply disable this functionality by bailing in `-[WKContentView _showTapHighlight]`.
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _showTapHighlight]):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (239320 => 239321)
--- trunk/Source/WebKit/ChangeLog 2018-12-18 05:49:32 UTC (rev 239320)
+++ trunk/Source/WebKit/ChangeLog 2018-12-18 06:30:34 UTC (rev 239321)
@@ -1,5 +1,19 @@
2018-12-17 Wenson Hsieh
+Tap highlights should not be shown on iOSMac
+https://bugs.webkit.org/show_bug.cgi?id=192797
+
+
+Reviewed by Tim Horton.
+
+WKWebViews in iOSMac should avoid painting tap highlights, since tap highlights are not present in the rest of
+the macOS platform. Simply disable this functionality by bailing in `-[WKContentView _showTapHighlight]`.
+
+* UIProcess/ios/WKContentViewInteraction.mm:
+(-[WKContentView _showTapHighlight]):
+
+2018-12-17 Wenson Hsieh
+
Unreviewed, fix the iOSMac engineering build again
After r239311, `WebProcessProxy::fullKeyboardAccessEnabled` in `WebProcessProxyIOS.mm` attempts to use
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (239320 => 239321)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-18 05:49:32 UTC (rev 239320)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-18 06:30:34 UTC (rev 239321)
@@ -1256,6 +1256,10 @@
- (void)_showTapHighlight
{
auto shouldPaintTapHighlight = [&](const WebCore::FloatRect& rect) {
+#if PLATFORM(IOSMAC)
+UNUSED_PARAM(rect);
+return NO;
+#else
static const float highlightPaintThreshold = 0.3; // 30%
float highlightArea = 0;
for (auto highlightQuad : _tapHighlightInformation.quads) {
@@ -1265,6 +1269,7 @@
return false;
}
return highlightArea < rect.area() * highlightPaintThreshold;
+#endif
};
if (!shouldPaintTapHighlight(_page->unobscuredContentRect()) && !_showDebugTapHighlightsForFastClicking)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239317] trunk/Source/WebKit
Title: [239317] trunk/Source/WebKit
Revision 239317
Author wenson_hs...@apple.com
Date 2018-12-17 20:39:35 -0800 (Mon, 17 Dec 2018)
Log Message
Unreviewed, fix the iOSMac engineering build
`generateRequestID()` is only invoked from code under `ENABLE(MEDIA_STREAM)`; move it under this guard to avoid
an unused function warning.
* UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp
Diff
Modified: trunk/Source/WebKit/ChangeLog (239316 => 239317)
--- trunk/Source/WebKit/ChangeLog 2018-12-18 04:17:58 UTC (rev 239316)
+++ trunk/Source/WebKit/ChangeLog 2018-12-18 04:39:35 UTC (rev 239317)
@@ -1,3 +1,12 @@
+2018-12-17 Wenson Hsieh
+
+Unreviewed, fix the iOSMac engineering build
+
+`generateRequestID()` is only invoked from code under `ENABLE(MEDIA_STREAM)`; move it under this guard to avoid
+an unused function warning.
+
+* UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
+
2018-12-17 David Kilzer
clang-tidy: Fix unnecessary object copy in CPUMonitor::setCPULimit()
Modified: trunk/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp (239316 => 239317)
--- trunk/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp 2018-12-18 04:17:58 UTC (rev 239316)
+++ trunk/Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp 2018-12-18 04:39:35 UTC (rev 239317)
@@ -41,7 +41,6 @@
#if ENABLE(MEDIA_STREAM)
static const MediaProducer::MediaStateFlags activeCaptureMask = MediaProducer::HasActiveAudioCaptureDevice | MediaProducer::HasActiveVideoCaptureDevice;
-#endif
static uint64_t generateRequestID()
{
@@ -48,6 +47,7 @@
static uint64_t uniqueRequestID = 1;
return uniqueRequestID++;
}
+#endif
UserMediaPermissionRequestManagerProxy::UserMediaPermissionRequestManagerProxy(WebPageProxy& page)
: m_page(page)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239337] trunk
Title: [239337] trunk Revision 239337 Author wenson_hs...@apple.com Date 2018-12-18 07:37:10 -0800 (Tue, 18 Dec 2018) Log Message Calling setValue() while typing should invoke -textDidChangeInTextField in the injected bundle https://bugs.webkit.org/show_bug.cgi?id=192785 Reviewed by Tim Horton. Source/WebCore: Makes a minor adjustment in `TextFieldInputType::setValue` to consider value changes as "user editing", if we're currently processing a keystroke from the user. This is useful for certain private clients, such as Safari, that need to know when the user is typing in a text form control, but the page is preventing default text insertion behavior and instead updating values programmatically. Test: fast/forms/call-text-did-change-in-text-field-when-typing.html * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::setValue): LayoutTests: Add a test to verify that: 1. When typing in a focused field, the injected bundle method is invoked. 2. When changing the value of the focused field under non-typing user interaction, the method isn't invoked. 3. When changing the value of the focused field programmatically without user gesture, the method isn't invoked. * TestExpectations: * fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt: Added. * fast/forms/call-text-did-change-in-text-field-when-typing.html: Added. * platform/wk2/TestExpectations: Modified Paths trunk/LayoutTests/ChangeLog trunk/LayoutTests/TestExpectations trunk/LayoutTests/platform/wk2/TestExpectations trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/html/TextFieldInputType.cpp Added Paths trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing.html Diff Modified: trunk/LayoutTests/ChangeLog (239336 => 239337) --- trunk/LayoutTests/ChangeLog 2018-12-18 15:30:25 UTC (rev 239336) +++ trunk/LayoutTests/ChangeLog 2018-12-18 15:37:10 UTC (rev 239337) @@ -1,3 +1,21 @@ +2018-12-18 Wenson Hsieh + +Calling setValue() while typing should invoke -textDidChangeInTextField in the injected bundle +https://bugs.webkit.org/show_bug.cgi?id=192785 + + +Reviewed by Tim Horton. + +Add a test to verify that: +1. When typing in a focused field, the injected bundle method is invoked. +2. When changing the value of the focused field under non-typing user interaction, the method isn't invoked. +3. When changing the value of the focused field programmatically without user gesture, the method isn't invoked. + +* TestExpectations: +* fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt: Added. +* fast/forms/call-text-did-change-in-text-field-when-typing.html: Added. +* platform/wk2/TestExpectations: + 2018-12-17 Jiewen Tan [Mac] Layout Test http/wpt/webauthn/public-key-credential-create-success-hid.https.html and http/wpt/webauthn/public-key-credential-get-success-hid.https.html are flaky Modified: trunk/LayoutTests/TestExpectations (239336 => 239337) --- trunk/LayoutTests/TestExpectations 2018-12-18 15:30:25 UTC (rev 239336) +++ trunk/LayoutTests/TestExpectations 2018-12-18 15:37:10 UTC (rev 239337) @@ -129,6 +129,7 @@ http/tests/navigation/process-swap-window-open.html [ Skip ] http/tests/navigation/useragent-reload.php [ Skip ] storage/indexeddb/modern/opendatabase-after-storage-crash.html [ Skip ] +fast/forms/call-text-did-change-in-text-field-when-typing.html [ Skip ] # Only Mac and iOS have an implementation of UIScriptController::doAsyncTask(). fast/harness/uiscriptcontroller [ Skip ] Added: trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt (0 => 239337) --- trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt (rev 0) +++ trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing-expected.txt 2018-12-18 15:37:10 UTC (rev 239337) @@ -0,0 +1,19 @@ + +Verifies that programmatically changing text field values with user interaction invokes the -didChangeInTextField injected bundle method. This test requires WebKitTestRunner. + +On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". + +1. Changing text field value with user typing gesture: +Text did change in text field. +The value of the text field is: "a" + +2. Changing text field value with non-typing user gesture: +PASS buttonClicked became true +The value of the text field is: "ab" + +3. Changing text field value without user gesture: +The value of the text field is: "abc" +PASS successfullyParsed is true + +TEST COMPLETE + Added: trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing.html (0 => 239337) --- trunk/LayoutTests/fast/forms/call-text-did-change-in-text-field-when-typing.html (rev 0) +++
[webkit-changes] [239441] trunk
Title: [239441] trunk Revision 239441 Author wenson_hs...@apple.com Date 2018-12-20 08:28:55 -0800 (Thu, 20 Dec 2018) Log Message [iOS] Focusing an editable element should scroll to reveal the selection https://bugs.webkit.org/show_bug.cgi?id=192802 Reviewed by Tim Horton. Source/WebKit: Currently, when tapping on an editable element, logic in -[WKWebView _zoomToFocusRect:…:] attempts to adjust the visible viewport such that the rect containing the selection is visible. However, AssistedNodeInformation's selectionRect is used here, which (as the FIXME in WebPage::getAssistedNodeInformation notes) is either the last touch location, or the top left of the element if the touch location is outside of the element's bounding rect. This leads to confusing and undesirable behavior when tapping near the bottom of a large contenteditable element to focus it, since the actual selection will end up near the top of the element, yet we'll try to scroll to reveal the bottom of the element, which causes the visible selection to scroll offscreen. Notably, this affects scenarios involving editable web views embedded in apps, such as Mail compose. Right now, we use the last touch location as an approximation for the selection rect because the selection may have not yet been updated at the moment when focus moves into an editable element. To fix this, we defer the process of zooming to the focused element rect until after the selection changes and the UI process is updated with information about the new selection rects. Test: editing/selection/ios/selection-is-visible-after-focusing-editable-area.html * Shared/AssistedNodeInformation.cpp: (WebKit::AssistedNodeInformation::encode const): (WebKit::AssistedNodeInformation::decode): * Shared/AssistedNodeInformation.h: Rename selectionRect to elementInteractionLocation, to more accurately reflect its value and purpose. This isn't strictly always the last touch location, since we may default to the focused element location instead if the last touch location is outside of the element rect. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): Tweak a constant that determines the minimum amount of margin to leave between the selection rect and the edge of the window when scrolling to reveal the focused element. Previously, this was larger than necessary to accomodate for the fact that the "selection rect" used when zooming to the focused element did not take the actual selection into account at all, and was simply a 1 by 1 rect; this meant that the margin needed to be large enough to exceed the usual height of a text caret in editable content. Since we now use the real selection rect, we can be much less generous with this margin. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView cleanupInteraction]): (-[WKContentView observeValueForKeyPath:ofObject:change:context:]): Don't additionally update the selection in the middle of triggering zooming to the focused element; on particular versions of iOS, this now attempts to scroll the selection rect on-screen, which then conflicts with zooming to reveal the focused element. (-[WKContentView _zoomToRevealFocusedElement]): Renamed from _displayFormNodeInputView to _zoomToRevealFocusedElement, to make the purpose of this function more clear. Additionally, pull logic to update the accessory view out of this method, so that it's strictly concerned with zooming to the focused element. (-[WKContentView inputView]): Add a FIXME describing the implications of zooming to the focused element in the implementation of -inputView. See also: . (-[WKContentView accessoryTab:]): Fix a subtle issue when keeping track of _didAccessoryTabInitiateFocus. Currently, this is set to YES in -accessoryTab: and unset in _displayFormNodeInputView, but since _displayFormNodeInputView may be invoked multiple times for the same focused element (see: -inputView), we might end up zooming to the focused element with _didAccessoryTabInitiateFocus set to NO, even though we initiated focus with the previous/next buttons. Instead, temporarily set a different ivar, _isChangingFocusUsingAccessoryTab, to YES in -accessoryTab:, and unset it in the completion handler after the focused element has changed. Then, when we _startAssistingNode:, set _didAccessoryTabInitiateFocus to _isChangingFocusUsingAccessoryTab. This ensures that the correctness of _didAccessoryTabInitiateFocus isn't tied to the number of times -[WKContentView inputView] is invoked when focusing an element. (shouldZoomToRevealSelectionRect): (rectToRevealWhenZoomingToFocusedElement): Add a helper method to determine the selection rect to use when zooming to reveal the focused element. ASSERTs that we have post-layout data in the EditorState. (-[WKContentView
[webkit-changes] [239482] trunk/LayoutTests
Title: [239482] trunk/LayoutTests
Revision 239482
Author wenson_hs...@apple.com
Date 2018-12-20 17:32:14 -0800 (Thu, 20 Dec 2018)
Log Message
[iOS] Some layout tests are failing after r239441
https://bugs.webkit.org/show_bug.cgi?id=192957
Reviewed by Simon Fraser.
Fix several failing layout tests after r239441.
* fast/events/ios/click-event-while-editing-node.html:
This test started failing after r239441 because it taps the bottom of the editable element, and then expects
WebKit to scroll the web view up to reveal the touched location. This was exactly the bug that r239441 fixed, so
we should just make this test no longer depend on the broken behavior.
* fast/forms/ios/focus-long-textarea-expected.txt:
* fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt:
Rebaseline a couple of test expectations to account for the change in margin around the selection rect, in
-[WKWebView _zoomToFocusRect:…:].
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/fast/events/ios/click-event-while-editing-node.html
trunk/LayoutTests/fast/forms/ios/focus-long-textarea-expected.txt
trunk/LayoutTests/fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt
Diff
Modified: trunk/LayoutTests/ChangeLog (239481 => 239482)
--- trunk/LayoutTests/ChangeLog 2018-12-21 01:29:54 UTC (rev 239481)
+++ trunk/LayoutTests/ChangeLog 2018-12-21 01:32:14 UTC (rev 239482)
@@ -1,3 +1,25 @@
+2018-12-20 Wenson Hsieh
+
+[iOS] Some layout tests are failing after r239441
+https://bugs.webkit.org/show_bug.cgi?id=192957
+
+
+Reviewed by Simon Fraser.
+
+Fix several failing layout tests after r239441.
+
+* fast/events/ios/click-event-while-editing-node.html:
+
+This test started failing after r239441 because it taps the bottom of the editable element, and then expects
+WebKit to scroll the web view up to reveal the touched location. This was exactly the bug that r239441 fixed, so
+we should just make this test no longer depend on the broken behavior.
+
+* fast/forms/ios/focus-long-textarea-expected.txt:
+* fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt:
+
+Rebaseline a couple of test expectations to account for the change in margin around the selection rect, in
+-[WKWebView _zoomToFocusRect:…:].
+
2018-12-20 Jiewen Tan
[WebAuthN] Remove hash from Client Data
Modified: trunk/LayoutTests/fast/events/ios/click-event-while-editing-node.html (239481 => 239482)
--- trunk/LayoutTests/fast/events/ios/click-event-while-editing-node.html 2018-12-21 01:29:54 UTC (rev 239481)
+++ trunk/LayoutTests/fast/events/ios/click-event-while-editing-node.html 2018-12-21 01:32:14 UTC (rev 239482)
@@ -24,8 +24,8 @@
if (window.testRunner) {
testRunner.dumpAsText();
jsTestIsAsync = true;
-UIHelper.activateAndWaitForInputSessionAt(50, 300).then(() => {
-UIHelper.tapAt(50, 300).then(() => {
+UIHelper.activateAndWaitForInputSessionAt(50, 200).then(() => {
+UIHelper.tapAt(50, 200).then(() => {
shouldBeEqualToString("document.getElementById('clicks').textContent", `${clickCount}`);
finishJSTest();
});
Modified: trunk/LayoutTests/fast/forms/ios/focus-long-textarea-expected.txt (239481 => 239482)
--- trunk/LayoutTests/fast/forms/ios/focus-long-textarea-expected.txt 2018-12-21 01:29:54 UTC (rev 239481)
+++ trunk/LayoutTests/fast/forms/ios/focus-long-textarea-expected.txt 2018-12-21 01:32:14 UTC (rev 239482)
@@ -3,4 +3,4 @@
tap location { x: 38.000, y: 664.000 }
scale 1.455
-visibleRect { left: 0.000, top: 506.294, width: 219.979, height: 376.713 }
+visibleRect { left: 0.000, top: 498.045, width: 219.979, height: 376.713 }
Modified: trunk/LayoutTests/fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt (239481 => 239482)
--- trunk/LayoutTests/fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt 2018-12-21 01:29:54 UTC (rev 239481)
+++ trunk/LayoutTests/fast/forms/ios/zoom-after-input-tap-wide-input-expected.txt 2018-12-21 01:32:14 UTC (rev 239482)
@@ -3,4 +3,4 @@
tap location { x: 328.000, y: 862.000 }
scale 1.455
-visibleRect { left: 122.707, top: 776.803, width: 219.980, height: 376.715 }
+visibleRect { left: 114.458, top: 776.803, width: 219.980, height: 376.715 }
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239547] trunk/Source/WebKit
Title: [239547] trunk/Source/WebKit Revision 239547 Author wenson_hs...@apple.com Date 2018-12-23 21:07:01 -0800 (Sun, 23 Dec 2018) Log Message [iOS] Remove some unnecessary editing SPI after https://bugs.webkit.org/show_bug.cgi?id=193019 Reviewed by Dan Bernstein. Remove these SPI method declarations, as well as method forwarding in WKContentView. Mail was the only adoptee of these methods; after , they have moved to the underscore-prefixed versions, so we we have no need for these erroneously-named SPI methods anymore. There is no change in behavior; verified this through existing API tests (WKWebViewEditActions), as well as building iOS Mail against WebKit with these changes to WKWebViewPrivate.h. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView canPerformAction:withSender:]): (-[WKWebView targetForAction:withSender:]): (-[WKWebView _setFont:sender:]): (-[WKWebView _setFontSize:sender:]): (-[WKWebView _setTextColor:sender:]): (-[WKWebView setFont:sender:]): Deleted. (-[WKWebView setTextColor:sender:]): Deleted. (-[WKWebView setFontSize:sender:]): Deleted. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView canPerformActionForWebView:withSender:]): (-[WKContentView setFontForWebView:sender:]): Deleted. (-[WKContentView setFontSizeForWebView:sender:]): Deleted. (-[WKContentView setTextColorForWebView:sender:]): Deleted. Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm Diff Modified: trunk/Source/WebKit/ChangeLog (239546 => 239547) --- trunk/Source/WebKit/ChangeLog 2018-12-23 23:51:30 UTC (rev 239546) +++ trunk/Source/WebKit/ChangeLog 2018-12-24 05:07:01 UTC (rev 239547) @@ -1,5 +1,35 @@ 2018-12-23 Wenson Hsieh +[iOS] Remove some unnecessary editing SPI after +https://bugs.webkit.org/show_bug.cgi?id=193019 + +Reviewed by Dan Bernstein. + +Remove these SPI method declarations, as well as method forwarding in WKContentView. Mail was the only adoptee +of these methods; after , they have moved to the underscore-prefixed versions, so we +we have no need for these erroneously-named SPI methods anymore. There is no change in behavior; verified this +through existing API tests (WKWebViewEditActions), as well as building iOS Mail against WebKit with these +changes to WKWebViewPrivate.h. + +* UIProcess/API/Cocoa/WKWebView.mm: +(-[WKWebView canPerformAction:withSender:]): +(-[WKWebView targetForAction:withSender:]): +(-[WKWebView _setFont:sender:]): +(-[WKWebView _setFontSize:sender:]): +(-[WKWebView _setTextColor:sender:]): +(-[WKWebView setFont:sender:]): Deleted. +(-[WKWebView setTextColor:sender:]): Deleted. +(-[WKWebView setFontSize:sender:]): Deleted. +* UIProcess/API/Cocoa/WKWebViewPrivate.h: +* UIProcess/ios/WKContentViewInteraction.h: +* UIProcess/ios/WKContentViewInteraction.mm: +(-[WKContentView canPerformActionForWebView:withSender:]): +(-[WKContentView setFontForWebView:sender:]): Deleted. +(-[WKContentView setFontSizeForWebView:sender:]): Deleted. +(-[WKContentView setTextColorForWebView:sender:]): Deleted. + +2018-12-23 Wenson Hsieh + Fix fast/ruby/ruby-base-merge-block-children-crash-2.html after r239543 https://bugs.webkit.org/show_bug.cgi?id=193015 Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm (239546 => 239547) --- trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2018-12-23 23:51:30 UTC (rev 239546) +++ trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm 2018-12-24 05:07:01 UTC (rev 239547) @@ -1445,9 +1445,6 @@ FOR_EACH_WKCONTENTVIEW_ACTION(FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW) FOR_EACH_PRIVATE_WKCONTENTVIEW_ACTION(FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW) -FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(setTextColor:sender) -FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(setFontSize:sender) -FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(setFont:sender) FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(_setTextColor:sender) FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(_setFontSize:sender) FORWARD_CANPERFORMACTION_TO_WKCONTENTVIEW(_setFont:sender) @@ -1465,9 +1462,6 @@ FOR_EACH_WKCONTENTVIEW_ACTION(FORWARD_TARGETFORACTION_TO_WKCONTENTVIEW) FOR_EACH_PRIVATE_WKCONTENTVIEW_ACTION(FORWARD_TARGETFORACTION_TO_WKCONTENTVIEW) -FORWARD_TARGETFORACTION_TO_WKCONTENTVIEW(setTextColor:sender) -FORWARD_TARGETFORACTION_TO_WKCONTENTVIEW(setFontSize:sender) -FORWARD_TARGETFORACTION_TO_WKCONTENTVIEW(setFont:sender)
[webkit-changes] [239546] trunk/Source/WebKit
Title: [239546] trunk/Source/WebKit Revision 239546 Author wenson_hs...@apple.com Date 2018-12-23 15:51:30 -0800 (Sun, 23 Dec 2018) Log Message Fix fast/ruby/ruby-base-merge-block-children-crash-2.html after r239543 https://bugs.webkit.org/show_bug.cgi?id=193015 Reviewed by Tim Horton. Fix the crash by gracefully handling integer overflow when computing the area of a very large editable element. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): (-[WKContentView _updateChangedSelection:]): Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm Diff Modified: trunk/Source/WebKit/ChangeLog (239545 => 239546) --- trunk/Source/WebKit/ChangeLog 2018-12-23 10:46:38 UTC (rev 239545) +++ trunk/Source/WebKit/ChangeLog 2018-12-23 23:51:30 UTC (rev 239546) @@ -1,3 +1,17 @@ +2018-12-23 Wenson Hsieh + +Fix fast/ruby/ruby-base-merge-block-children-crash-2.html after r239543 +https://bugs.webkit.org/show_bug.cgi?id=193015 + + +Reviewed by Tim Horton. + +Fix the crash by gracefully handling integer overflow when computing the area of a very large editable element. + +* UIProcess/ios/WKContentViewInteraction.mm: +(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): +(-[WKContentView _updateChangedSelection:]): + 2018-12-22 Wenson Hsieh [iOS] Suppress native selection behaviors when focusing a very small editable element Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (239545 => 239546) --- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-23 10:46:38 UTC (rev 239545) +++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-23 23:51:30 UTC (rev 239546) @@ -4476,7 +4476,8 @@ else [self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTransparent]; -if (information.elementRect.area() < minimumFocusedElementAreaForSuppressingSelectionAssistant) +auto elementArea = information.elementRect.area(); +if (!elementArea.hasOverflowed() && elementArea < minimumFocusedElementAreaForSuppressingSelectionAssistant) [self _beginSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTooSmall]; else [self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTooSmall]; @@ -5013,7 +5014,8 @@ else [self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTransparent]; -if (postLayoutData.focusedElementRect.area() < minimumFocusedElementAreaForSuppressingSelectionAssistant) +auto elementArea = postLayoutData.focusedElementRect.area(); +if (!elementArea.hasOverflowed() && elementArea < minimumFocusedElementAreaForSuppressingSelectionAssistant) [self _beginSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTooSmall]; else [self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTooSmall]; ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239543] trunk
Title: [239543] trunk Revision 239543 Author wenson_hs...@apple.com Date 2018-12-22 22:38:24 -0800 (Sat, 22 Dec 2018) Log Message [iOS] Suppress native selection behaviors when focusing a very small editable element https://bugs.webkit.org/show_bug.cgi?id=193005 Reviewed by Tim Horton. Source/WebKit: In r238146, I added a mechanism to detect when the selection is hidden within transparent editable elements, and used this to suppress native selection on iOS (such as selection handles, highlight, callout bar, etc.) to avoid conflicts between the page's editing UI and the platform. However, one additional technique observed on some websites involves hiding the selection by moving it into a tiny (1x1) editable element. Here, we currently still present a callout bar with editing actions, as well as show a selection caret or handles on iOS. To fix this, we extend the mechanism added in r238146 by also suppressing the selection assistant in the case where the editable element's area is beneath a tiny minimum threshold. Test: editing/selection/ios/hide-selection-in-tiny-contenteditable.html * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): (WebKit::operator<<): * Shared/EditorState.h: Rename selectionClipRect to focusedElementRect. We currently propagate the bounds of the focused element to the UI process through EditorState updates, but only for the purpose of returning it in the computed selection clip rect; instead, rename this member to something more general-purpose, so we can also use it when determining whether to suppress the selection assistant. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _candidateRect]): * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::handleRequestedCandidates): * UIProcess/ios/WKContentViewInteraction.h: Add a new SuppressSelectionAssistantReason that corresponds to focusing tiny editable elements. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _zoomToRevealFocusedElement]): (-[WKContentView _selectionClipRect]): (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): (-[WKContentView _updateChangedSelection:]): Check the size of the focused element, and begin or stop suppressing the selection assistant accordingly. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::platformEditorState const): LayoutTests: Add a new layout test to verify that native selection UI is suppressed when focusing a tiny (1px by 1px) editable element. * editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt: Added. * editing/selection/ios/hide-selection-in-tiny-contenteditable.html: Added. * resources/ui-helper.js: (window.UIHelper.zoomToScale): Modified Paths trunk/LayoutTests/ChangeLog trunk/LayoutTests/resources/ui-helper.js trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Shared/EditorState.cpp trunk/Source/WebKit/Shared/EditorState.h trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm trunk/Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm Added Paths trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable.html Diff Modified: trunk/LayoutTests/ChangeLog (239542 => 239543) --- trunk/LayoutTests/ChangeLog 2018-12-23 01:09:21 UTC (rev 239542) +++ trunk/LayoutTests/ChangeLog 2018-12-23 06:38:24 UTC (rev 239543) @@ -1,3 +1,19 @@ +2018-12-22 Wenson Hsieh + +[iOS] Suppress native selection behaviors when focusing a very small editable element +https://bugs.webkit.org/show_bug.cgi?id=193005 + + +Reviewed by Tim Horton. + +Add a new layout test to verify that native selection UI is suppressed when focusing a tiny (1px by 1px) +editable element. + +* editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt: Added. +* editing/selection/ios/hide-selection-in-tiny-contenteditable.html: Added. +* resources/ui-helper.js: +(window.UIHelper.zoomToScale): + 2018-12-20 Yusuke Suzuki [JSC] Implement "well-formed JSON.stringify" proposal Added: trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt (0 => 239543) --- trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt (rev 0) +++ trunk/LayoutTests/editing/selection/ios/hide-selection-in-tiny-contenteditable-expected.txt 2018-12-23 06:38:24 UTC (rev 239543) @@ -0,0 +1,18 @@ +Focus the editor +abcdefg +Verifies that
[webkit-changes] [239053] trunk
Title: [239053] trunk
Revision 239053
Author wenson_hs...@apple.com
Date 2018-12-10 14:18:10 -0800 (Mon, 10 Dec 2018)
Log Message
[iOS] Unable to upload data that conforms to "public.item" but not "public.content"
https://bugs.webkit.org/show_bug.cgi?id=192555
Reviewed by Tim Horton.
Source/WebCore:
Add support for uploading content that conforms to "public.item" via drag and drop. Currently, iOS WebKit only
supports data that conforms to "public.content", but there exist several types of files that conform to
"public.item" but not "public.content". See below for more detail.
Test: DragAndDropTests.ExternalSourcePKCS12ToSingleFileInput
* platform/ios/PasteboardIOS.mm:
(WebCore::Pasteboard::supportedFileUploadPasteboardTypes):
Update this to include "public.item", and remove "public.folder", which is now redundant because "public.folder"
conforms to "public.item".
* platform/ios/WebItemProviderPasteboard.mm:
(-[NSItemProvider web_containsFileURLAndFileUploadContent]):
Pull out the "contains content that is supported for file uploads" part of this helper method into a separate
method, and use it within `-web_containsFileURLAndFileUploadContent`. Note that this prevents "public.url"-
conformant data from being uploaded as files (i.e., we never want to upload a URL string *itself* as a file).
Drawing this distinction ensures that we don't confuse item providers that contain just a URL as files when
dropping into a file upload area or file input (see API test: ExternalSourceZIPArchiveAndURLToSingleFileInput
for an example of this corner case).
(-[NSItemProvider web_containsFileUploadContent]):
(-[WebItemProviderPasteboard numberOfFiles]):
Refactor this to use `-web_containsFileUploadContent`.
Tools:
Add a test to verify that `.p12` files may be uploaded as files via drag and drop. "com.rsa.pkcs-12" is an
example of a data type that conforms to "public.item", but not "public.content"; before this patch, we would
only support uploading "public.content", so files such as these would not be accepted when dropping into file
inputs, or be exposed as files on DataTransfer.
* TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm:
(TestWebKitAPI::TEST):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/ios/PasteboardIOS.mm
trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (239052 => 239053)
--- trunk/Source/WebCore/ChangeLog 2018-12-10 22:10:48 UTC (rev 239052)
+++ trunk/Source/WebCore/ChangeLog 2018-12-10 22:18:10 UTC (rev 239053)
@@ -1,3 +1,38 @@
+2018-12-10 Wenson Hsieh
+
+[iOS] Unable to upload data that conforms to "public.item" but not "public.content"
+https://bugs.webkit.org/show_bug.cgi?id=192555
+
+
+Reviewed by Tim Horton.
+
+Add support for uploading content that conforms to "public.item" via drag and drop. Currently, iOS WebKit only
+supports data that conforms to "public.content", but there exist several types of files that conform to
+"public.item" but not "public.content". See below for more detail.
+
+Test: DragAndDropTests.ExternalSourcePKCS12ToSingleFileInput
+
+* platform/ios/PasteboardIOS.mm:
+(WebCore::Pasteboard::supportedFileUploadPasteboardTypes):
+
+Update this to include "public.item", and remove "public.folder", which is now redundant because "public.folder"
+conforms to "public.item".
+
+* platform/ios/WebItemProviderPasteboard.mm:
+(-[NSItemProvider web_containsFileURLAndFileUploadContent]):
+
+Pull out the "contains content that is supported for file uploads" part of this helper method into a separate
+method, and use it within `-web_containsFileURLAndFileUploadContent`. Note that this prevents "public.url"-
+conformant data from being uploaded as files (i.e., we never want to upload a URL string *itself* as a file).
+Drawing this distinction ensures that we don't confuse item providers that contain just a URL as files when
+dropping into a file upload area or file input (see API test: ExternalSourceZIPArchiveAndURLToSingleFileInput
+for an example of this corner case).
+
+(-[NSItemProvider web_containsFileUploadContent]):
+(-[WebItemProviderPasteboard numberOfFiles]):
+
+Refactor this to use `-web_containsFileUploadContent`.
+
2018-12-10 Chris Dumez
Add SPI to allow the client to set the user-agent at main frame level, from the UIProcess
Modified: trunk/Source/WebCore/platform/ios/PasteboardIOS.mm (239052 => 239053)
--- trunk/Source/WebCore/platform/ios/PasteboardIOS.mm 2018-12-10 22:10:48 UTC (rev 239052)
+++ trunk/Source/WebCore/platform/ios/PasteboardIOS.mm 2018-12-10 22:18:10 UTC (rev 239053)
@@ -345,7 +345,7 @@
NSArray *Pasteboard::supportedFileUploadPasteboardTypes()
{
-return @[
[webkit-changes] [239052] trunk/Source/WebKit
Title: [239052] trunk/Source/WebKit Revision 239052 Author wenson_hs...@apple.com Date 2018-12-10 14:10:48 -0800 (Mon, 10 Dec 2018) Log Message Unreviewed, fix the iOS build after r239039. https://bugs.webkit.org/show_bug.cgi?id=192568 * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dropInteraction:sessionDidUpdate:]): Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm Diff Modified: trunk/Source/WebKit/ChangeLog (239051 => 239052) --- trunk/Source/WebKit/ChangeLog 2018-12-10 22:03:13 UTC (rev 239051) +++ trunk/Source/WebKit/ChangeLog 2018-12-10 22:10:48 UTC (rev 239052) @@ -1,3 +1,11 @@ +2018-12-10 Wenson Hsieh + +Unreviewed, fix the iOS build after r239039. +https://bugs.webkit.org/show_bug.cgi?id=192568 + +* UIProcess/ios/WKContentViewInteraction.mm: +(-[WKContentView dropInteraction:sessionDidUpdate:]): + 2018-12-10 Alex Christensen Fix WatchOS build. Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (239051 => 239052) --- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-10 22:03:13 UTC (rev 239051) +++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2018-12-10 22:10:48 UTC (rev 239052) @@ -5895,7 +5895,7 @@ auto proposal = adoptNS([[UIDropProposal alloc] initWithDropOperation:static_cast(operation)]); auto dragHandlingMethod = _page->currentDragHandlingMethod(); -[proposal setPrecise:dragHandlingMethod == DragHandlingMethod::EditPlainText || dragHandlingMethod == DragHandlingMethod::EditRichText]; +[proposal setPrecise:dragHandlingMethod == WebCore::DragHandlingMethod::EditPlainText || dragHandlingMethod == WebCore::DragHandlingMethod::EditRichText]; if ([delegate respondsToSelector:@selector(_webView:willUpdateDropProposalToProposal:forSession:)]) proposal = [delegate _webView:_webView willUpdateDropProposalToProposal:proposal.get() forSession:session]; ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [239086] trunk/Source/WebCore
Title: [239086] trunk/Source/WebCore Revision 239086 Author wenson_hs...@apple.com Date 2018-12-11 13:13:32 -0800 (Tue, 11 Dec 2018) Log Message [iOS] Send the full list of file upload URLs and types in PasteboardItemInfo https://bugs.webkit.org/show_bug.cgi?id=192598 Work towards Reviewed by Tim Horton. Refactors PasteboardItemInfo to contain lists of file URLs and corresponding pasteboard types, instead of just a "preferred" file upload URL and type. See below for more details. * platform/PasteboardItemInfo.h: (WebCore::PasteboardItemInfo::pathForContentType const): Add a helper method to find a file upload URL corresponding to a given type. (WebCore::PasteboardItemInfo::encode const): (WebCore::PasteboardItemInfo::decode): Change `pathForFileUpload` to `pathsForFileUpload`, and `contentTypeForFileUpload` to `contentTypesForFileUpload`. * platform/ios/AbstractPasteboard.h: * platform/ios/PasteboardIOS.mm: (WebCore::Pasteboard::readRespectingUTIFidelities): Adjust this to take the file path for the highest fidelity representation in `pathsForContentType`. (WebCore::Pasteboard::readFilePaths): * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): * platform/ios/WebItemProviderPasteboard.h: * platform/ios/WebItemProviderPasteboard.mm: (-[NSItemProvider web_containsFileURLAndFileUploadContent]): (-[NSItemProvider web_fileUploadContentTypes]): Replace `web_containsFileUploadContent` with `web_fileUploadContentTypes`, which returns the full list of file upload content types (rather than just a `BOOL` indicating whether one or more of these types exist). (-[WebItemProviderPasteboard fileUploadURLsAtIndex:fileTypes:]): (-[WebItemProviderPasteboard numberOfFiles]): (-[NSItemProvider web_containsFileUploadContent]): Deleted. (-[WebItemProviderPasteboard preferredFileUploadURLAtIndex:fileType:]): Deleted. Replaced with `-fileUploadURLsAtIndex:fileTypes:`. This implementation currently just returns the highest fidelity loaded type identifier, but this is wrong because it doesn't take into account inline data types that shouldn't be represented as data for file uploads (for instance, it never makes sense to upload the internal data serialization for an `NSURL` as a file on the web). Instead, use existing logic in `web_fileUploadContentTypes` to determine which file types can be treated as file uploads, and return all of these file types that we've loaded. Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/platform/PasteboardItemInfo.h trunk/Source/WebCore/platform/ios/AbstractPasteboard.h trunk/Source/WebCore/platform/ios/PasteboardIOS.mm trunk/Source/WebCore/platform/ios/PlatformPasteboardIOS.mm trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.h trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm Diff Modified: trunk/Source/WebCore/ChangeLog (239085 => 239086) --- trunk/Source/WebCore/ChangeLog 2018-12-11 21:12:11 UTC (rev 239085) +++ trunk/Source/WebCore/ChangeLog 2018-12-11 21:13:32 UTC (rev 239086) @@ -1,3 +1,54 @@ +2018-12-11 Wenson Hsieh + +[iOS] Send the full list of file upload URLs and types in PasteboardItemInfo +https://bugs.webkit.org/show_bug.cgi?id=192598 +Work towards + +Reviewed by Tim Horton. + +Refactors PasteboardItemInfo to contain lists of file URLs and corresponding pasteboard types, instead of just +a "preferred" file upload URL and type. See below for more details. + +* platform/PasteboardItemInfo.h: +(WebCore::PasteboardItemInfo::pathForContentType const): + +Add a helper method to find a file upload URL corresponding to a given type. + +(WebCore::PasteboardItemInfo::encode const): +(WebCore::PasteboardItemInfo::decode): + +Change `pathForFileUpload` to `pathsForFileUpload`, and `contentTypeForFileUpload` to `contentTypesForFileUpload`. + +* platform/ios/AbstractPasteboard.h: +* platform/ios/PasteboardIOS.mm: +(WebCore::Pasteboard::readRespectingUTIFidelities): + +Adjust this to take the file path for the highest fidelity representation in `pathsForContentType`. + +(WebCore::Pasteboard::readFilePaths): +* platform/ios/PlatformPasteboardIOS.mm: +(WebCore::PlatformPasteboard::informationForItemAtIndex): +* platform/ios/WebItemProviderPasteboard.h: +* platform/ios/WebItemProviderPasteboard.mm: +(-[NSItemProvider web_containsFileURLAndFileUploadContent]): +(-[NSItemProvider web_fileUploadContentTypes]): + +Replace `web_containsFileUploadContent` with `web_fileUploadContentTypes`, which returns the full list of file +upload content types (rather than just a `BOOL` indicating whether one or more of these types exist). + +(-[WebItemProviderPasteboard fileUploadURLsAtIndex:fileTypes:]): +(-[WebItemProviderPasteboard numberOfFiles]): +(-[NSItemProvider
[webkit-changes] [239511] trunk
Title: [239511] trunk
Revision 239511
Author wenson_hs...@apple.com
Date 2018-12-21 11:40:41 -0800 (Fri, 21 Dec 2018)
Log Message
Setting the file wrapper and content type of an attachment to a PDF should update its image
https://bugs.webkit.org/show_bug.cgi?id=192984
Reviewed by Tim Horton.
Source/WebCore:
Allow PDF data to be used to update enclosing image elements when setting the file wrapper for an attachment.
Covered by a new API test: WKAttachmentTests.SetFileWrapperForPDFImageAttachment.
* html/HTMLAttachmentElement.cpp:
(WebCore::mimeTypeIsSuitableForInlineImageAttachment):
(WebCore::HTMLAttachmentElement::updateEnclosingImageWithData):
Tools:
Add an API test to verify that setting the file wrapper for a _WKAttachment with an enclosing image element with
PDF data correctly updates the image element.
* TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/html/HTMLAttachmentElement.cpp
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (239510 => 239511)
--- trunk/Source/WebCore/ChangeLog 2018-12-21 19:37:40 UTC (rev 239510)
+++ trunk/Source/WebCore/ChangeLog 2018-12-21 19:40:41 UTC (rev 239511)
@@ -1,3 +1,18 @@
+2018-12-21 Wenson Hsieh
+
+Setting the file wrapper and content type of an attachment to a PDF should update its image
+https://bugs.webkit.org/show_bug.cgi?id=192984
+
+
+Reviewed by Tim Horton.
+
+Allow PDF data to be used to update enclosing image elements when setting the file wrapper for an attachment.
+Covered by a new API test: WKAttachmentTests.SetFileWrapperForPDFImageAttachment.
+
+* html/HTMLAttachmentElement.cpp:
+(WebCore::mimeTypeIsSuitableForInlineImageAttachment):
+(WebCore::HTMLAttachmentElement::updateEnclosingImageWithData):
+
2018-12-21 Justin Michaud
Repeated background images with zero size should display the background color
Modified: trunk/Source/WebCore/html/HTMLAttachmentElement.cpp (239510 => 239511)
--- trunk/Source/WebCore/html/HTMLAttachmentElement.cpp 2018-12-21 19:37:40 UTC (rev 239510)
+++ trunk/Source/WebCore/html/HTMLAttachmentElement.cpp 2018-12-21 19:40:41 UTC (rev 239511)
@@ -226,6 +226,11 @@
renderer->invalidate();
}
+static bool mimeTypeIsSuitableForInlineImageAttachment(const String& mimeType)
+{
+return MIMETypeRegistry::isSupportedImageMIMEType(mimeType) || MIMETypeRegistry::isPDFMIMEType(mimeType);
+}
+
void HTMLAttachmentElement::updateEnclosingImageWithData(const String& contentType, Ref&& data)
{
auto* hostElement = shadowHost();
@@ -238,7 +243,7 @@
mimeType = MIMETypeFromUTI(contentType);
#endif
-if (!MIMETypeRegistry::isSupportedImageMIMEType(mimeType))
+if (!mimeTypeIsSuitableForInlineImageAttachment(mimeType))
return;
hostElement->setAttributeWithoutSynchronization(HTMLNames::srcAttr, DOMURL::createObjectURL(document(), Blob::create(WTFMove(data), mimeType)));
Modified: trunk/Tools/ChangeLog (239510 => 239511)
--- trunk/Tools/ChangeLog 2018-12-21 19:37:40 UTC (rev 239510)
+++ trunk/Tools/ChangeLog 2018-12-21 19:40:41 UTC (rev 239511)
@@ -1,3 +1,16 @@
+2018-12-21 Wenson Hsieh
+
+Setting the file wrapper and content type of an attachment to a PDF should update its image
+https://bugs.webkit.org/show_bug.cgi?id=192984
+
+
+Reviewed by Tim Horton.
+
+Add an API test to verify that setting the file wrapper for a _WKAttachment with an enclosing image element with
+PDF data correctly updates the image element.
+
+* TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
+
2018-12-21 Michael Catanzaro
Add JSCOnly to bot dashboard
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm (239510 => 239511)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm 2018-12-21 19:37:40 UTC (rev 239510)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm 2018-12-21 19:40:41 UTC (rev 239511)
@@ -1505,6 +1505,18 @@
EXPECT_WK_STREQ([attachment uniqueIdentifier], [webView stringByEvaluatingJavaScript:@"document.body.cloneNode(true).querySelector('attachment').uniqueIdentifier"]);
}
+TEST(WKAttachmentTests, SetFileWrapperForPDFImageAttachment)
+{
+auto webView = webViewForTestingAttachments();
+[webView evaluateJavaScript:@"document.body.appendChild()" completionHandler:nil];
+NSString *identifier = [webView stringByEvaluatingJavaScript:@"const i = document.createElement('img'); document.body.appendChild(i); HTMLAttachmentElement.getAttachmentIdentifier(i)"];
+_WKAttachment *attachment = [webView _attachmentForIdentifier:identifier];
+
+auto pdfFile = adoptNS([[NSFileWrapper alloc] initRegularFileWithContents:testPDFData()]);
+[attachment setFileWrapper:pdfFile.get()
[webkit-changes] [238751] trunk
Title: [238751] trunk Revision 238751 Author wenson_hs...@apple.com Date 2018-11-30 13:18:13 -0800 (Fri, 30 Nov 2018) Log Message Replace "auto fill" with "AutoFill" in some localizable strings https://bugs.webkit.org/show_bug.cgi?id=192233 Reviewed by Chris Fleizach. Source/WebCore: Replace "autofill" with "AutoFill". * en.lproj/Localizable.strings: * platform/LocalizedStrings.cpp: (WebCore::AXAutoFillCredentialsLabel): (WebCore::AXAutoFillContactsLabel): (WebCore::AXAutoFillStrongPasswordLabel): (WebCore::AXAutoFillCreditCardLabel): LayoutTests: Rebaseline a test. * accessibility/auto-fill-types-expected.txt: Modified Paths trunk/LayoutTests/ChangeLog trunk/LayoutTests/accessibility/auto-fill-types-expected.txt trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/en.lproj/Localizable.strings trunk/Source/WebCore/platform/LocalizedStrings.cpp Diff Modified: trunk/LayoutTests/ChangeLog (238750 => 238751) --- trunk/LayoutTests/ChangeLog 2018-11-30 21:13:27 UTC (rev 238750) +++ trunk/LayoutTests/ChangeLog 2018-11-30 21:18:13 UTC (rev 238751) @@ -1,3 +1,15 @@ +2018-11-30 Wenson Hsieh + +Replace "auto fill" with "AutoFill" in some localizable strings +https://bugs.webkit.org/show_bug.cgi?id=192233 + + +Reviewed by Chris Fleizach. + +Rebaseline a test. + +* accessibility/auto-fill-types-expected.txt: + 2018-11-30 Devin Rousso Web Inspector: replace all unicode characters with the escaped character code Modified: trunk/LayoutTests/accessibility/auto-fill-types-expected.txt (238750 => 238751) --- trunk/LayoutTests/accessibility/auto-fill-types-expected.txt 2018-11-30 21:13:27 UTC (rev 238750) +++ trunk/LayoutTests/accessibility/auto-fill-types-expected.txt 2018-11-30 21:18:13 UTC (rev 238751) @@ -7,10 +7,10 @@ Initial auto-fill available: false Auto-fill type: none Contact button role: AXRole: AXButton -Contact button label: AXDescription: contact info auto fill +Contact button label: AXDescription: contact info AutoFill Auto-fill type: contacts Credentials button role: AXRole: AXButton -Credentials button label: AXDescription: password auto fill +Credentials button label: AXDescription: password AutoFill Auto-fill type: credentials Post auto-fill available: true PASS successfullyParsed is true Modified: trunk/Source/WebCore/ChangeLog (238750 => 238751) --- trunk/Source/WebCore/ChangeLog 2018-11-30 21:13:27 UTC (rev 238750) +++ trunk/Source/WebCore/ChangeLog 2018-11-30 21:18:13 UTC (rev 238751) @@ -1,3 +1,20 @@ +2018-11-30 Wenson Hsieh + +Replace "auto fill" with "AutoFill" in some localizable strings +https://bugs.webkit.org/show_bug.cgi?id=192233 + + +Reviewed by Chris Fleizach. + +Replace "autofill" with "AutoFill". + +* en.lproj/Localizable.strings: +* platform/LocalizedStrings.cpp: +(WebCore::AXAutoFillCredentialsLabel): +(WebCore::AXAutoFillContactsLabel): +(WebCore::AXAutoFillStrongPasswordLabel): +(WebCore::AXAutoFillCreditCardLabel): + 2018-11-29 Ryosuke Niwa Add CEReactions=NotNeeded on all the relevant IDL files Modified: trunk/Source/WebCore/en.lproj/Localizable.strings (238750 => 238751) --- trunk/Source/WebCore/en.lproj/Localizable.strings 2018-11-30 21:13:27 UTC (rev 238750) +++ trunk/Source/WebCore/en.lproj/Localizable.strings 2018-11-30 21:18:13 UTC (rev 238751) @@ -973,8 +973,8 @@ /* HTTP result code string */ "conflict" = "conflict"; -/* Label for the auto fill contacts button inside a text field. */ -"contact info auto fill" = "contact info auto fill"; +/* Label for the AutoFill contacts button inside a text field. */ +"contact info AutoFill" = "contact info AutoFill"; /* An ARIA accessibility group that contains content. */ "content information" = "content information"; @@ -985,8 +985,8 @@ /* HTTP result code string */ "created" = "created"; -/* Label for the credit card auto fill button inside a text field. */ -"credit card auto fill" = "credit card auto fill"; +/* Label for the credit card AutoFill button inside a text field. */ +"credit card AutoFill" = "credit card AutoFill"; /* The less good value description for a meter element. */ "critical value" = "critical value"; @@ -1186,8 +1186,8 @@ /* HTTP result code string */ "partial content" = "partial content"; -/* Label for the auto fill credentials button inside a text field. */ -"password auto fill" = "password auto fill"; +/* Label for the AutoFill credentials button inside a text field. */ +"password AutoFill" = "password AutoFill"; /* accessibility label for pause button */ "pause" = "pause"; @@ -1288,8 +1288,8 @@ /* accessibility help text for hide closed captions button */ "stop displaying closed captions" = "stop displaying closed captions"; -/* Label for the strong password auto fill button inside a text field. */ -"strong password auto fill" = "strong password auto fill"; +/* Label for the
[webkit-changes] [238661] trunk
Title: [238661] trunk Revision 238661 Author wenson_hs...@apple.com Date 2018-11-28 21:25:07 -0800 (Wed, 28 Nov 2018) Log Message [iOSMac] Dropping text selections from web content into editable elements crashes the web process https://bugs.webkit.org/show_bug.cgi?id=192113 Reviewed by Ryosuke Niwa. Source/WebCore: In iOSMac, registering invalid UTIs on NSItemProvider when starting a drag or handling a drop does not work. Since iOS writes and reads only "Apple Web Archive pasteboard type" (a.k.a. `WebArchivePboardType`) during drag and drop as well as copy and paste, we fail to read or write any web archive data, and subsequently fall back to reading RTF or flat RTFD, both of which are not supported in iOSMac, since UIFoundation links against the system's macOS WebKit stack. To fix this, we add support for reading and writing com.apple.webarchive (`kUTTypeWebArchive`) on iOS, so that WebKit-based iOSMac applications can understand web archive data from the host running macOS, and the host can also understand web archive data written by the iOSMac app. Additionally, don't allow reading RTF and flat RTFD as web content in iOSMac. (Note that writing RTF and flat RTFD is still safe, since it does not depend on UIFoundation.framework but rather `WebCore::HTMLConverter`). Test: DragAndDropTests.ModernWebArchiveType * editing/cocoa/WebContentReaderCocoa.mm: (WebCore::createFragment): Additionally make sure that we never call into UIFoundation's NSAttributedString to markup conversion codepath by making `createFragment` an empty stub on iOSMac. * platform/ios/PasteboardIOS.mm: (WebCore::supportedImageTypes): (WebCore::isTypeAllowedByReadingPolicy): (WebCore::Pasteboard::readPasteboardWebContentDataForType): (WebCore::Pasteboard::supportedWebContentPasteboardTypes): * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::write): Tools: Add a test to verify that, when dropping an item with both "com.apple.webarchive" and "public.utf8-plain-text" representations, the higher fidelity web archive data is used when handling the drop. * TestWebKitAPI/Tests/WebKitCocoa/DragAndDropTests.mm: Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm trunk/Source/WebCore/platform/ios/PasteboardIOS.mm trunk/Source/WebCore/platform/ios/PlatformPasteboardIOS.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DragAndDropTests.mm Diff Modified: trunk/Source/WebCore/ChangeLog (238660 => 238661) --- trunk/Source/WebCore/ChangeLog 2018-11-29 04:39:45 UTC (rev 238660) +++ trunk/Source/WebCore/ChangeLog 2018-11-29 05:25:07 UTC (rev 238661) @@ -1,3 +1,39 @@ +2018-11-28 Wenson Hsieh + +[iOSMac] Dropping text selections from web content into editable elements crashes the web process +https://bugs.webkit.org/show_bug.cgi?id=192113 + + +Reviewed by Ryosuke Niwa. + +In iOSMac, registering invalid UTIs on NSItemProvider when starting a drag or handling a drop does not work. +Since iOS writes and reads only "Apple Web Archive pasteboard type" (a.k.a. `WebArchivePboardType`) during drag +and drop as well as copy and paste, we fail to read or write any web archive data, and subsequently fall back to +reading RTF or flat RTFD, both of which are not supported in iOSMac, since UIFoundation links against the +system's macOS WebKit stack. + +To fix this, we add support for reading and writing com.apple.webarchive (`kUTTypeWebArchive`) on iOS, so that +WebKit-based iOSMac applications can understand web archive data from the host running macOS, and the host can +also understand web archive data written by the iOSMac app. Additionally, don't allow reading RTF and flat RTFD +as web content in iOSMac. (Note that writing RTF and flat RTFD is still safe, since it does not depend on +UIFoundation.framework but rather `WebCore::HTMLConverter`). + +Test: DragAndDropTests.ModernWebArchiveType + +* editing/cocoa/WebContentReaderCocoa.mm: +(WebCore::createFragment): + +Additionally make sure that we never call into UIFoundation's NSAttributedString to markup conversion codepath +by making `createFragment` an empty stub on iOSMac. + +* platform/ios/PasteboardIOS.mm: +(WebCore::supportedImageTypes): +(WebCore::isTypeAllowedByReadingPolicy): +(WebCore::Pasteboard::readPasteboardWebContentDataForType): +(WebCore::Pasteboard::supportedWebContentPasteboardTypes): +* platform/ios/PlatformPasteboardIOS.mm: +(WebCore::PlatformPasteboard::write): + 2018-11-28 Commit Queue Unreviewed, rolling out r238653 and r238656. Modified: trunk/Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm (238660 => 238661) --- trunk/Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm 2018-11-29 04:39:45 UTC (rev 238660) +++
[webkit-changes] [238954] trunk
Title: [238954] trunk
Revision 238954
Author wenson_hs...@apple.com
Date 2018-12-07 10:37:58 -0800 (Fri, 07 Dec 2018)
Log Message
[Attachment Support] Cloned attachment elements lose their unique identifiers
https://bugs.webkit.org/show_bug.cgi?id=192483
Reviewed by Tim Horton.
Source/WebCore:
This patch adds logic to ensure that the unique identifier of a cloned attachment element is the same as the
unique identifier of the original attachment element. If the cloned attachment is inserted into the same
document as the original attachment, then we will exercise the same codepath for copied-and-pasted attachments,
and assign a new unique identifier to the attachment element, while creating a new `_WKAttachment` in the client
that's backed by the same `NSFileWrapper`.
Test: WKAttachmentTests.AttachmentIdentifierOfClonedAttachment
* html/HTMLAttachmentElement.cpp:
(WebCore::HTMLAttachmentElement::copyNonAttributePropertiesFromElement):
* html/HTMLAttachmentElement.h:
Tools:
Introduce a new API test.
* TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(TestWebKitAPI::TEST):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/html/HTMLAttachmentElement.cpp
trunk/Source/WebCore/html/HTMLAttachmentElement.h
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (238953 => 238954)
--- trunk/Source/WebCore/ChangeLog 2018-12-07 18:33:43 UTC (rev 238953)
+++ trunk/Source/WebCore/ChangeLog 2018-12-07 18:37:58 UTC (rev 238954)
@@ -1,3 +1,22 @@
+2018-12-07 Wenson Hsieh
+
+[Attachment Support] Cloned attachment elements lose their unique identifiers
+https://bugs.webkit.org/show_bug.cgi?id=192483
+
+Reviewed by Tim Horton.
+
+This patch adds logic to ensure that the unique identifier of a cloned attachment element is the same as the
+unique identifier of the original attachment element. If the cloned attachment is inserted into the same
+document as the original attachment, then we will exercise the same codepath for copied-and-pasted attachments,
+and assign a new unique identifier to the attachment element, while creating a new `_WKAttachment` in the client
+that's backed by the same `NSFileWrapper`.
+
+Test: WKAttachmentTests.AttachmentIdentifierOfClonedAttachment
+
+* html/HTMLAttachmentElement.cpp:
+(WebCore::HTMLAttachmentElement::copyNonAttributePropertiesFromElement):
+* html/HTMLAttachmentElement.h:
+
2018-12-07 Rob Buis
Merge parseAccessControlExposeHeadersAllowList into parseAccessControlAllowList
Modified: trunk/Source/WebCore/html/HTMLAttachmentElement.cpp (238953 => 238954)
--- trunk/Source/WebCore/html/HTMLAttachmentElement.cpp 2018-12-07 18:33:43 UTC (rev 238953)
+++ trunk/Source/WebCore/html/HTMLAttachmentElement.cpp 2018-12-07 18:37:58 UTC (rev 238954)
@@ -86,6 +86,12 @@
return identifier;
}
+void HTMLAttachmentElement::copyNonAttributePropertiesFromElement(const Element& source)
+{
+m_uniqueIdentifier = downcast(source).uniqueIdentifier();
+HTMLElement::copyNonAttributePropertiesFromElement(source);
+}
+
URL HTMLAttachmentElement::archiveResourceURL(const String& identifier)
{
auto resourceURL = URL({ }, "applewebdata://attachment/"_s);
Modified: trunk/Source/WebCore/html/HTMLAttachmentElement.h (238953 => 238954)
--- trunk/Source/WebCore/html/HTMLAttachmentElement.h 2018-12-07 18:33:43 UTC (rev 238953)
+++ trunk/Source/WebCore/html/HTMLAttachmentElement.h 2018-12-07 18:37:58 UTC (rev 238954)
@@ -52,6 +52,8 @@
const String& uniqueIdentifier() const { return m_uniqueIdentifier; }
void setUniqueIdentifier(const String& uniqueIdentifier) { m_uniqueIdentifier = uniqueIdentifier; }
+void copyNonAttributePropertiesFromElement(const Element&) final;
+
WEBCORE_EXPORT void updateAttributes(std::optional&& newFileSize, const String& newContentType, const String& newFilename);
WEBCORE_EXPORT void updateEnclosingImageWithData(const String& contentType, Ref&& data);
Modified: trunk/Tools/ChangeLog (238953 => 238954)
--- trunk/Tools/ChangeLog 2018-12-07 18:33:43 UTC (rev 238953)
+++ trunk/Tools/ChangeLog 2018-12-07 18:37:58 UTC (rev 238954)
@@ -1,3 +1,15 @@
+2018-12-07 Wenson Hsieh
+
+[Attachment Support] Cloned attachment elements lose their unique identifiers
+https://bugs.webkit.org/show_bug.cgi?id=192483
+
+Reviewed by Tim Horton.
+
+Introduce a new API test.
+
+* TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
+(TestWebKitAPI::TEST):
+
2018-12-06 Jonathan Bedard
Consecutive DumpRenderTree crashes are happening again on WinCairo BuildBots since r238903
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm (238953 => 238954)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm 2018-12-07 18:33:43 UTC (rev
[webkit-changes] [238795] trunk
Title: [238795] trunk Revision 238795 Author wenson_hs...@apple.com Date 2018-12-03 07:42:12 -0800 (Mon, 03 Dec 2018) Log Message [iOSMac] Unable to upload non-image files using drag and drop in WKWebView https://bugs.webkit.org/show_bug.cgi?id=192283 Reviewed by Ryosuke Niwa. Source/WebCore: Currently on iOS, file URLs aren't generally written to the pasteboard during drag and drop unless the application providing the data explicitly registers "public.file-url" to item providers. As such, our current logic on iOS for handling drops does not attempt to prevent "public.file-url" from being advertised as the "text/uri-list" MIME type in DataTransfer, though we do currently succeed in suppressing access to the file URL. However, on iOSMac, the scenario in which file URLs are registered to item providers becomes pertinent when uploading files from other macOS apps (e.g. Finder) into a WKWebView running in iOSMac. Furthermore, the `preferredPresentationStyle` flag on `NSItemProvider` is unavailable in iOSMac; currently, this flag is our primary cue on iOS that an item should be treated as an attachment rather than inline data. In order to support file uploads in iOSMac, we make several adjustments to drop handling logic in iOS to handle the case where the "public.file-url" type is registered. See below for more details. Tests: DragAndDropTests.DataTransferExposePlainTextWithFileURLAsFile DragAndDropTests.DataTransferGetDataWhenDroppingImageWithFileURL * platform/PasteboardItemInfo.h: (WebCore::PasteboardItemInfo::encode const): (WebCore::PasteboardItemInfo::decode): Add a new flag that is set if and only if the item provider contains the "public.file-url" type, and also contains some non-URL data type that conforms to one of the file types supported for file uploads (i.e. "public.content", zip archives, and folders). * platform/cocoa/PasteboardCocoa.mm: (WebCore::Pasteboard::fileContentState): Consider the pasteboard to contain files in the case where one or more of the items contains a file URL, along with some other pasteboard data that can be represented as a file upload. * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): (WebCore::PlatformPasteboard::typesSafeForDOMToReadAndWrite const): If the pasteboard contains "public.file-url", don't consider "text/uri-list" to be one of the data types that's safe to expose to the page. Our current behavior in this case is that we will advertise "text/uri-list" as a pasteboard type in the DataTransfer, but if the page attempts to request this information, we simply return the empty string. Instead, we shouldn't expose "text/uri-list" as a type in the first place. * platform/ios/WebItemProviderPasteboard.h: * platform/ios/WebItemProviderPasteboard.mm: Add a few more `__bridge`-ing casts where appropriate. (typeConformsToTypes): Move this further up the file so that it can be used in `NSItemProvider (WebCoreExtras)`. (-[NSItemProvider web_containsFileURLAndFileUploadContent]): Add a helper method on NSItemProvider to determine whether an item provider has a file URL, as well as a content type suitable for file uploads. (-[WebItemProviderLoadResult canBeRepresentedAsFileUpload]): This currently always returns `NO` in iOSMac; instead, return `YES` on both iOS and iOSMac in the case where the item provider contains a file URL and content which may be uploaded. (-[WebItemProviderPasteboard preferredFileUploadURLAtIndex:fileType:]): (-[WebItemProviderPasteboard typeIdentifiersToLoad:]): Refactor this to take an `NSItemProvider` instead of a list of type identifiers, and bail out of loading data for "public.url" if the item provider contains a file URL. (-[WebItemProviderPasteboard doAfterLoadingProvidedContentIntoFileURLs:synchronousTimeout:]): (-[WebItemProviderPasteboard typeIdentifiersToLoadForRegisteredTypeIdentifiers:]): Deleted. Tools: Add a new API test to check that an item provider which contains plain text data and a file URL (but is not marked as an attachment) is still treated as an attachment upon drop. Furthermore, verify that "text/uri-list" does not expose the actual file URL written to the item provider. Additionally, rebaseline an existing API test to remove an extraneous "text/uri-list" type that appears in `DataTransfer.types`, but whose data is inaccessible via `getData` anyways. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/platform/PasteboardItemInfo.h trunk/Source/WebCore/platform/cocoa/PasteboardCocoa.mm trunk/Source/WebCore/platform/ios/PlatformPasteboardIOS.mm trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.h trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm Diff Modified: trunk/Source/WebCore/ChangeLog (238794 => 238795) --- trunk/Source/WebCore/ChangeLog 2018-12-03
[webkit-changes] [238921] trunk/Tools
Title: [238921] trunk/Tools Revision 238921 Author wenson_hs...@apple.com Date 2018-12-05 19:09:29 -0800 (Wed, 05 Dec 2018) Log Message [Cocoa] Share ClassMethodSwizzler and InstanceMethodSwizzler between TestWebKitAPI and WebKitTestRunner https://bugs.webkit.org/show_bug.cgi?id=192437 Reviewed by Tim Horton. * DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj: * TestRunnerShared/cocoa/ClassMethodSwizzler.h: Renamed from Tools/TestWebKitAPI/ClassMethodSwizzler.h. * TestRunnerShared/cocoa/ClassMethodSwizzler.mm: Renamed from Tools/TestWebKitAPI/ClassMethodSwizzler.mm. (ClassMethodSwizzler::ClassMethodSwizzler): (ClassMethodSwizzler::~ClassMethodSwizzler): * TestRunnerShared/cocoa/InstanceMethodSwizzler.h: Renamed from Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.h. * TestRunnerShared/cocoa/InstanceMethodSwizzler.mm: Renamed from Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.mm. (InstanceMethodSwizzler::InstanceMethodSwizzler): (InstanceMethodSwizzler::~InstanceMethodSwizzler): Move these swizzling helper classes into TestRunnerShared. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm: * TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm: (safeBrowsingView): * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewDefaultNavigationDelegate.mm: * TestWebKitAPI/cocoa/TestWKWebView.mm: (-[TestWKWebView initWithFrame:configuration:addToWindow:]): Remove namespacing around ClassMethodSwizzler and InstanceMethodSwizzler in a few API tests. * TestWebKitAPI/mac/TestFontOptions.mm: * WebKitTestRunner/TestController.h: * WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj: * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::ClassMethodSwizzler::ClassMethodSwizzler): Deleted. (WTR::ClassMethodSwizzler::~ClassMethodSwizzler): Deleted. Remove this duplicate implementation of ClassMethodSwizzler in WebKitTestRunner. Modified Paths trunk/Tools/ChangeLog trunk/Tools/DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewDefaultNavigationDelegate.mm trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm trunk/Tools/TestWebKitAPI/mac/TestFontOptions.mm trunk/Tools/WebKitTestRunner/TestController.h trunk/Tools/WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj trunk/Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm Added Paths trunk/Tools/TestRunnerShared/cocoa/ClassMethodSwizzler.h trunk/Tools/TestRunnerShared/cocoa/ClassMethodSwizzler.mm trunk/Tools/TestRunnerShared/cocoa/InstanceMethodSwizzler.h trunk/Tools/TestRunnerShared/cocoa/InstanceMethodSwizzler.mm Removed Paths trunk/Tools/TestWebKitAPI/ClassMethodSwizzler.h trunk/Tools/TestWebKitAPI/ClassMethodSwizzler.mm trunk/Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.h trunk/Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.mm Diff Modified: trunk/Tools/ChangeLog (238920 => 238921) --- trunk/Tools/ChangeLog 2018-12-06 03:02:19 UTC (rev 238920) +++ trunk/Tools/ChangeLog 2018-12-06 03:09:29 UTC (rev 238921) @@ -1,3 +1,41 @@ +2018-12-05 Wenson Hsieh + +[Cocoa] Share ClassMethodSwizzler and InstanceMethodSwizzler between TestWebKitAPI and WebKitTestRunner +https://bugs.webkit.org/show_bug.cgi?id=192437 + +Reviewed by Tim Horton. + +* DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj: +* TestRunnerShared/cocoa/ClassMethodSwizzler.h: Renamed from Tools/TestWebKitAPI/ClassMethodSwizzler.h. +* TestRunnerShared/cocoa/ClassMethodSwizzler.mm: Renamed from Tools/TestWebKitAPI/ClassMethodSwizzler.mm. +(ClassMethodSwizzler::ClassMethodSwizzler): +(ClassMethodSwizzler::~ClassMethodSwizzler): +* TestRunnerShared/cocoa/InstanceMethodSwizzler.h: Renamed from Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.h. +* TestRunnerShared/cocoa/InstanceMethodSwizzler.mm: Renamed from Tools/TestWebKitAPI/cocoa/InstanceMethodSwizzler.mm. +(InstanceMethodSwizzler::InstanceMethodSwizzler): +(InstanceMethodSwizzler::~InstanceMethodSwizzler): + +Move these swizzling helper classes into TestRunnerShared. + +* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: +* TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm: +* TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm: +(safeBrowsingView): +* TestWebKitAPI/Tests/WebKitCocoa/WKWebViewDefaultNavigationDelegate.mm: +* TestWebKitAPI/cocoa/TestWKWebView.mm: +(-[TestWKWebView initWithFrame:configuration:addToWindow:]): + +Remove namespacing around ClassMethodSwizzler and InstanceMethodSwizzler in a few API tests. + +* TestWebKitAPI/mac/TestFontOptions.mm: +* WebKitTestRunner/TestController.h: +*
[webkit-changes] [238939] trunk
Title: [238939] trunk Revision 238939 Author wenson_hs...@apple.com Date 2018-12-06 13:22:19 -0800 (Thu, 06 Dec 2018) Log Message [iOS] WKWebView should match UITextView behavior when editing text with an RTL keyboard https://bugs.webkit.org/show_bug.cgi?id=187554 Reviewed by Tim Horton. Source/WebKit: Add support for automatically switching the base writing direction to the default writing direction with respect to the current keyboard in an editable WKWebView by implementing `-setBaseWritingDirection:forRange:`. On iOS 12 and earlier, UIKit invokes this protocol method whenever the keyboard is changed to one with a different writing direction, although in some other versions of iOS, this only happens when first focusing an editable area. Test: editing/input/ios/rtl-keyboard-input-on-focus.html * Platform/spi/ios/UIKitSPI.h: Declare UIKeyboardImpl IPI methods mostly for use in WebKitTestRunner (with the exception of `-setInitialDirection`, which we may invoke when we receive the first post-layout EditorState update after focusing an editable element). * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::increaseListLevel): (WebKit::WebPageProxy::decreaseListLevel): (WebKit::WebPageProxy::changeListType): (WebKit::WebPageProxy::setBaseWritingDirection): Drive-by style fixes: make these bail and return early if `!isValid()`. (WebKit::WebPageProxy::resetStateAfterProcessExited): Reset assisted node state in the UI process upon web process termination. * UIProcess/WebPageProxy.h: Add plumbing for `setBaseWritingDirection`, from `WebPageProxy` to `WebPage` to `Editor`. * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didReceiveEditorStateUpdateAfterFocus): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView baseWritingDirectionForPosition:inDirection:]): (coreWritingDirection): (-[WKContentView setBaseWritingDirection:forRange:]): Support `-setBaseWritingDirectionForPosition:forRange:`, but only in the case where the given range is the selected range. This is all that's currently needed to fulfill the requirements in , though we could potentially add full support for this in the future by mapping the given text range to a DOM range and moving the selection prior to setting the base writing direction. (-[WKContentView _didReceiveEditorStateUpdateAfterFocus]): Add a hook to notify WKContentView when the first post-layout EditorState has been received in the UI process. When this is invoked, if the web view is editable and the selection is not a range, we call into `UIKeyboardImpl` to change the initial writing direction if necessary. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::startAssistingNode): (WebKit::WebPageProxy::stopAssistingNode): (WebKit::WebPageProxy::editorStateChanged): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setBaseWritingDirection): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: Add support for simulating the keyboard input mode in layout tests using UIScriptController, as well as a new `TestOption` to make the web view editable. * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setKeyboardInputModeIdentifier): * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.cpp: (WTR::UIScriptController::setKeyboardInputModeIdentifier): * TestRunnerShared/UIScriptContext/UIScriptController.h: * WebKitTestRunner/PlatformWebView.h: * WebKitTestRunner/TestController.cpp: (WTR::updateTestOptionsFromTestHeader): * WebKitTestRunner/TestController.h: (WTR::TestController::overriddenKeyboardInputMode const): * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::platformCreateWebView): * WebKitTestRunner/gtk/PlatformWebViewGtk.cpp: (WTR::PlatformWebView::setEditable): * WebKitTestRunner/ios/PlatformWebViewIOS.mm: (WTR::PlatformWebView::setEditable): * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetStateToConsistentValues): (WTR::swizzleCurrentInputMode): (WTR::TestController::setKeyboardInputModeIdentifier): Swizzle out several `UIKeyboardInputModeController` methods in order to convince UIKit that the user has selected a `UIKeyboardInputMode` corresponding to the given identifier. The call to `-prepareKeyboardInputModeFromPreferences:` is also necessary on iOS 12 in order to update cached writing direction state in UIKit. * WebKitTestRunner/ios/UIScriptControllerIOS.mm: (WTR::UIScriptController::setKeyboardInputModeIdentifier): * WebKitTestRunner/mac/PlatformWebViewMac.mm: (WTR::PlatformWebView::setEditable): * WebKitTestRunner/win/PlatformWebViewWin.cpp: (WTR::PlatformWebView::setEditable): * WebKitTestRunner/wpe/PlatformWebViewWPE.cpp:
[webkit-changes] [239025] trunk/Tools
Title: [239025] trunk/Tools
Revision 239025
Author wenson_hs...@apple.com
Date 2018-12-09 23:54:16 -0800 (Sun, 09 Dec 2018)
Log Message
[iOS] DragAndDropTests.RespectsExternalSourceFidelityRankings is flaky
https://bugs.webkit.org/show_bug.cgi?id=192524
Reviewed by Ryosuke Niwa.
This test started failing on certain builds of iOS where UIKit now attempts to reveal the selection by scrolling
(see ). This API test simulates two drops from external sources, both from the point
(300, 400) to (100, 300) in window coordinates. On these aforementioned builds of iOS, what happens is that the
first drop inserts text that overflows the editable region by an enormous amount, which creates an extremely
wide selection rect and increases the width of the document; revealing this selection causes the web view to
scroll horizontally, such that the second attempt to simulate a drag from (300, 400) to (100, 300) fails, since
these window coordinates no longer correspond to the drop destination element in the document.
To fix this test, we simply mark the drop destination as `overflow: hidden` to ensure that we don't try and
scroll horizontally after the first drop.
* TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html:
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html
Diff
Modified: trunk/Tools/ChangeLog (239024 => 239025)
--- trunk/Tools/ChangeLog 2018-12-10 05:30:23 UTC (rev 239024)
+++ trunk/Tools/ChangeLog 2018-12-10 07:54:16 UTC (rev 239025)
@@ -1,3 +1,23 @@
+2018-12-09 Wenson Hsieh
+
+[iOS] DragAndDropTests.RespectsExternalSourceFidelityRankings is flaky
+https://bugs.webkit.org/show_bug.cgi?id=192524
+
+Reviewed by Ryosuke Niwa.
+
+This test started failing on certain builds of iOS where UIKit now attempts to reveal the selection by scrolling
+(see ). This API test simulates two drops from external sources, both from the point
+(300, 400) to (100, 300) in window coordinates. On these aforementioned builds of iOS, what happens is that the
+first drop inserts text that overflows the editable region by an enormous amount, which creates an extremely
+wide selection rect and increases the width of the document; revealing this selection causes the web view to
+scroll horizontally, such that the second attempt to simulate a drag from (300, 400) to (100, 300) fails, since
+these window coordinates no longer correspond to the drop destination element in the document.
+
+To fix this test, we simply mark the drop destination as `overflow: hidden` to ensure that we don't try and
+scroll horizontally after the first drop.
+
+* TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html:
+
2018-12-08 Daniel Bates
Fix lldb_webkit.py following r238771
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html (239024 => 239025)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html 2018-12-10 05:30:23 UTC (rev 239024)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html 2018-12-10 07:54:16 UTC (rev 239025)
@@ -14,7 +14,7 @@
white-space: nowrap;
}
-#source {
+#source, #editor {
overflow: hidden;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238728] trunk
Title: [238728] trunk Revision 238728 Author wenson_hs...@apple.com Date 2018-11-29 23:22:00 -0800 (Thu, 29 Nov 2018) Log Message REGRESSION (r238635): Dragging a text selection within WKWebView causes the selection highlight to get into a bad state https://bugs.webkit.org/show_bug.cgi?id=192165 Reviewed by Daniel Bates. Source/WebKit: Fixes a bug in PageClientImpl::isViewFocused. Consider the following scenario: 1. WKWebView is hosted within the view hierarchy 2. First responder is *not* WKContentView 3. The active focus retain count is nonzero Before r238635, we would return true, due to condition (3). However, after r238635, we only consider whether the first responder is WKContentView, since the web view is in the view hierarchy. This breaks scenarios where WebKit or UIKit attempts to retain focus and later restore the content view to be the first responder (an example of this is dragging a text selection between editable elements in the same web view). To fix this, simply bail early and return true if focus is being retained. * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::isViewFocused): Tools: Fixes 11 API tests that started failing or timing out after r238635. See below for more details. * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm: (TestWebKitAPI::webViewForEditActionTesting): (TestWebKitAPI::webViewForEditActionTestingWithPageNamed): Ensure that the web view becomes first responder before executing edit actions. * TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html: * TestWebKitAPI/Tests/WebKitCocoa/contenteditable-and-textarea.html: Tweak these tests to allow selected content to overflow the width of the web view. Without this change, ContentEditableToContentEditable and ContentEditableToTextarea will sometimes fail because the content causes the body to scroll horizontally, so we miss the drop destination. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (loadTestPageAndEnsureInputSession): Add a new helper to load a test page with a given name, become first responder, and wait until an input session starts. Use this in various drag and drop tests to reduce code duplication. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm: (-[DragAndDropSimulator initWithWebView:]): (-[DragAndDropSimulator _resetSimulatedState]): (-[DragAndDropSimulator _concludeDropAndPerformOperationIfNecessary]): (-[DragAndDropSimulator _advanceProgress]): To more accurately emulate UIKit behavior, begin focus preservation when starting a drag, and attempt to clear the focus preservation token when the drag session ends. This allows us to simulate and test the scenario that regressed with r238635. (-[DragAndDropSimulator ensureInputSession]): (-[DragAndDropSimulator _webView:didStartInputSession:]): (-[DragAndDropSimulator waitForInputSession]): Deleted. Refactored into -ensureInputSession. Instead of assuming that an input session has not yet been started, simply wait for an input session to start if needed. * TestWebKitAPI/ios/UIKitSPI.h: Add a new SPI declaration. Modified Paths trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/UIProcess/ios/PageClientImplIOS.mm trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEditActions.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/autofocus-contenteditable.html trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/contenteditable-and-textarea.html trunk/Tools/TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm trunk/Tools/TestWebKitAPI/cocoa/DragAndDropSimulator.h trunk/Tools/TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h Diff Modified: trunk/Source/WebKit/ChangeLog (238727 => 238728) --- trunk/Source/WebKit/ChangeLog 2018-11-30 06:35:36 UTC (rev 238727) +++ trunk/Source/WebKit/ChangeLog 2018-11-30 07:22:00 UTC (rev 238728) @@ -1,3 +1,26 @@ +2018-11-29 Wenson Hsieh + +REGRESSION (r238635): Dragging a text selection within WKWebView causes the selection highlight to get into a bad state +https://bugs.webkit.org/show_bug.cgi?id=192165 + + +Reviewed by Daniel Bates. + +Fixes a bug in PageClientImpl::isViewFocused. Consider the following scenario: +1. WKWebView is hosted within the view hierarchy +2. First responder is *not* WKContentView +3. The active focus retain count is nonzero + +Before r238635, we would return true, due to condition (3). However, after r238635, we only consider whether the +first responder is WKContentView, since the web view is in the view hierarchy. This breaks scenarios where +WebKit or UIKit attempts to retain focus and later restore the content view to be the first responder (an +example of this is dragging a text selection between editable elements in the same web view). + +To fix this, simply bail early and return true if focus is being retained. + +*
[webkit-changes] [238894] trunk/Source
Title: [238894] trunk/Source Revision 238894 Author wenson_hs...@apple.com Date 2018-12-05 09:51:03 -0800 (Wed, 05 Dec 2018) Log Message Turn WritingDirection into an enum class https://bugs.webkit.org/show_bug.cgi?id=192401 Work towards Reviewed by Dan Bernstein. Change WritingDirection from an enum to an enum class. No change in behavior. Source/WebCore: * editing/ApplyStyleCommand.cpp: (WebCore::ApplyStyleCommand::splitAncestorsWithUnicodeBidi): (WebCore::ApplyStyleCommand::applyInlineStyle): * editing/EditingStyle.cpp: (WebCore::EditingStyle::textDirection const): (WebCore::EditingStyle::textDirectionForSelection): * editing/Editor.cpp: (WebCore::Editor::setBaseWritingDirection): (WebCore::Editor::baseWritingDirectionForSelectionStart const): * editing/EditorCommand.cpp: (WebCore::stateTextWritingDirectionLeftToRight): (WebCore::stateTextWritingDirectionNatural): (WebCore::stateTextWritingDirectionRightToLeft): * editing/WritingDirection.h: Additionally wrap this enum in `namespace WebCore`, and update the copyright year. * editing/ios/EditorIOS.mm: (WebCore::Editor::setTextAlignmentForChangedBaseWritingDirection): * page/ContextMenuController.cpp: (WebCore::ContextMenuController::contextMenuItemSelected): * testing/Internals.cpp: (WebCore::Internals::setBaseWritingDirection): Source/WebKit: * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::setTextDirection): Source/WebKitLegacy/ios: * WebCoreSupport/WebFrameIOS.mm: (-[WebFrame selectionBaseWritingDirection]): (-[WebFrame setBaseWritingDirection:]): Source/WebKitLegacy/mac: * WebView/WebHTMLView.mm: (-[WebHTMLView toggleBaseWritingDirection:]): (-[WebHTMLView changeBaseWritingDirection:]): (-[WebHTMLView _changeBaseWritingDirectionTo:]): Source/WebKitLegacy/win: * WebFrame.cpp: (WebFrame::setTextDirection): Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/ApplyStyleCommand.cpp trunk/Source/WebCore/editing/EditingStyle.cpp trunk/Source/WebCore/editing/Editor.cpp trunk/Source/WebCore/editing/EditorCommand.cpp trunk/Source/WebCore/editing/WritingDirection.h trunk/Source/WebCore/editing/ios/EditorIOS.mm trunk/Source/WebCore/page/ContextMenuController.cpp trunk/Source/WebCore/testing/Internals.cpp trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/WebProcess/WebPage/WebFrame.cpp trunk/Source/WebKitLegacy/ios/ChangeLog trunk/Source/WebKitLegacy/ios/WebCoreSupport/WebFrameIOS.mm trunk/Source/WebKitLegacy/mac/ChangeLog trunk/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm trunk/Source/WebKitLegacy/win/ChangeLog trunk/Source/WebKitLegacy/win/WebFrame.cpp Diff Modified: trunk/Source/WebCore/ChangeLog (238893 => 238894) --- trunk/Source/WebCore/ChangeLog 2018-12-05 16:05:58 UTC (rev 238893) +++ trunk/Source/WebCore/ChangeLog 2018-12-05 17:51:03 UTC (rev 238894) @@ -1,3 +1,37 @@ +2018-12-05 Wenson Hsieh + +Turn WritingDirection into an enum class +https://bugs.webkit.org/show_bug.cgi?id=192401 +Work towards + +Reviewed by Dan Bernstein. + +Change WritingDirection from an enum to an enum class. No change in behavior. + +* editing/ApplyStyleCommand.cpp: +(WebCore::ApplyStyleCommand::splitAncestorsWithUnicodeBidi): +(WebCore::ApplyStyleCommand::applyInlineStyle): +* editing/EditingStyle.cpp: +(WebCore::EditingStyle::textDirection const): +(WebCore::EditingStyle::textDirectionForSelection): +* editing/Editor.cpp: +(WebCore::Editor::setBaseWritingDirection): +(WebCore::Editor::baseWritingDirectionForSelectionStart const): +* editing/EditorCommand.cpp: +(WebCore::stateTextWritingDirectionLeftToRight): +(WebCore::stateTextWritingDirectionNatural): +(WebCore::stateTextWritingDirectionRightToLeft): +* editing/WritingDirection.h: + +Additionally wrap this enum in `namespace WebCore`, and update the copyright year. + +* editing/ios/EditorIOS.mm: +(WebCore::Editor::setTextAlignmentForChangedBaseWritingDirection): +* page/ContextMenuController.cpp: +(WebCore::ContextMenuController::contextMenuItemSelected): +* testing/Internals.cpp: +(WebCore::Internals::setBaseWritingDirection): + 2018-12-05 Alicia Boya García [MSE][GStreamer] Remove the AppendPipeline state machine Modified: trunk/Source/WebCore/editing/ApplyStyleCommand.cpp (238893 => 238894) --- trunk/Source/WebCore/editing/ApplyStyleCommand.cpp 2018-12-05 16:05:58 UTC (rev 238893) +++ trunk/Source/WebCore/editing/ApplyStyleCommand.cpp 2018-12-05 17:51:03 UTC (rev 238894) @@ -484,7 +484,7 @@ HTMLElement* unsplitAncestor = nullptr; WritingDirection highestAncestorDirection; -if (allowedDirection != NaturalWritingDirection +if (allowedDirection != WritingDirection::Natural && highestAncestorUnicodeBidi != CSSValueBidiOverride && is(*highestAncestorWithUnicodeBidi) &&
[webkit-changes] [238461] trunk
Title: [238461] trunk Revision 238461 Author wenson_hs...@apple.com Date 2018-11-23 10:18:01 -0800 (Fri, 23 Nov 2018) Log Message Enable drag and drop support for iOSMac https://bugs.webkit.org/show_bug.cgi?id=191818 Reviewed by Dean Jackson. Source/_javascript_Core: * Configurations/FeatureDefines.xcconfig: Source/WebCore: Enables drag and drop by default on iOSMac by switching on ENABLE_DATA_INTERACTION and ENABLE_DRAG_SUPPORT. This enables support for dragging links, text selections, and images, though many advanced features (e.g. custom pasteboard data) will require additional support from the platform. * Configurations/FeatureDefines.xcconfig: * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): (WebCore::registerItemToPasteboard): (WebCore::PlatformPasteboard::typesSafeForDOMToReadAndWrite const): * platform/ios/WebItemProviderPasteboard.mm: (-[WebItemProviderLoadResult canBeRepresentedAsFileUpload]): (-[WebItemProviderPasteboard numberOfFiles]): Disable codepaths which attempt to access or set `teamData` or `preferredPresentationStyle` on `NSItemProvider` in iOSMac, since these are currently unimplemented. Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: * Shared/WebPreferencesDefaultValues.cpp: (defaultCustomPasteboardDataEnabled): Enable custom pasteboard data by default on iOSMac. While writing and reading custom pasteboard data is currently broken in iOSMac due to the lack of `teamData` and `preferredPresentationStyle`, opting into custom pasteboard data at least allows us to avoid writing unsanitized data types to the pasteboard. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): Fix a regression from r236619> wherein the web process crashes when attempting to edit a text field. This happens because the call to `-[UIKeyboard isInHardwareKeyboardMode]` on the iOSMac platform attempts to initialize a `UHASWorkspace` from the web process, which then attempts to connect to the UIKit host application. Instead, we can skip this call altogether on iOSMac, where the platform never considers a hardware keyboard to be "connected", even when typing. Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/Configurations/FeatureDefines.xcconfig trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Configurations/FeatureDefines.xcconfig trunk/Source/WebCore/PAL/ChangeLog trunk/Source/WebCore/PAL/Configurations/FeatureDefines.xcconfig trunk/Source/WebCore/platform/ios/PlatformPasteboardIOS.mm trunk/Source/WebCore/platform/ios/WebItemProviderPasteboard.mm trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Configurations/FeatureDefines.xcconfig trunk/Source/WebKit/Shared/WebPreferencesDefaultValues.cpp trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm trunk/Source/WebKitLegacy/mac/ChangeLog trunk/Source/WebKitLegacy/mac/Configurations/FeatureDefines.xcconfig trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/Configurations/FeatureDefines.xcconfig Diff Modified: trunk/Source/_javascript_Core/ChangeLog (238460 => 238461) --- trunk/Source/_javascript_Core/ChangeLog 2018-11-23 17:05:43 UTC (rev 238460) +++ trunk/Source/_javascript_Core/ChangeLog 2018-11-23 18:18:01 UTC (rev 238461) @@ -1,3 +1,13 @@ +2018-11-23 Wenson Hsieh + +Enable drag and drop support for iOSMac +https://bugs.webkit.org/show_bug.cgi?id=191818 + + +Reviewed by Dean Jackson. + +* Configurations/FeatureDefines.xcconfig: + 2018-11-22 Mark Lam Make the jsc shell's dumpException() more robust against long exception strings. Modified: trunk/Source/_javascript_Core/Configurations/FeatureDefines.xcconfig (238460 => 238461) --- trunk/Source/_javascript_Core/Configurations/FeatureDefines.xcconfig 2018-11-23 17:05:43 UTC (rev 238460) +++ trunk/Source/_javascript_Core/Configurations/FeatureDefines.xcconfig 2018-11-23 18:18:01 UTC (rev 238461) @@ -124,6 +124,7 @@ ENABLE_DATA_INTERACTION = $(ENABLE_DATA_INTERACTION_$(WK_PLATFORM_NAME)); ENABLE_DATA_INTERACTION_iphoneos = ENABLE_DATA_INTERACTION; ENABLE_DATA_INTERACTION_iphonesimulator = ENABLE_DATA_INTERACTION; +ENABLE_DATA_INTERACTION_iosmac = ENABLE_DATA_INTERACTION; ENABLE_DEVICE_ORIENTATION = $(ENABLE_DEVICE_ORIENTATION_$(WK_PLATFORM_NAME)); ENABLE_DEVICE_ORIENTATION_iphoneos = ENABLE_DEVICE_ORIENTATION; @@ -136,6 +137,7 @@ ENABLE_DRAG_SUPPORT = $(ENABLE_DRAG_SUPPORT_$(WK_PLATFORM_NAME)); ENABLE_DRAG_SUPPORT_iphoneos = ENABLE_DRAG_SUPPORT; ENABLE_DRAG_SUPPORT_iphonesimulator = ENABLE_DRAG_SUPPORT; +ENABLE_DRAG_SUPPORT_iosmac = ENABLE_DRAG_SUPPORT; ENABLE_ENCRYPTED_MEDIA = $(ENABLE_ENCRYPTED_MEDIA_$(WK_PLATFORM_NAME)); ENABLE_ENCRYPTED_MEDIA_iphoneos = ENABLE_ENCRYPTED_MEDIA; Modified:
[webkit-changes] [238471] trunk
Title: [238471] trunk Revision 238471 Author wenson_hs...@apple.com Date 2018-11-24 13:06:09 -0800 (Sat, 24 Nov 2018) Log Message [Cocoa] Add WKWebView SPI to trigger and remove data detection https://bugs.webkit.org/show_bug.cgi?id=191918 Reviewed by Tim Horton. Source/WebCore: Add a helper method on DataDetection to remove all data detected links in the given document. See WebKit changes for more detail. * editing/cocoa/DataDetection.h: * editing/cocoa/DataDetection.mm: (WebCore::DataDetection::removeDataDetectedLinksInDocument): Source/WebKit: Adds support for two new WKWebView SPI methods, `-_detectDataWithTypes:completionHandler:` and `-_removeAllDataDetectedLinks:`, to allow internal WebKit clients to run data detection and add links to data detected content, or remove all data detected links from the document. Test: WebKit.AddAndRemoveDataDetectors * Shared/Cocoa/DataDetectionResult.h: * Shared/Cocoa/DataDetectionResult.mm: (WebKit::DataDetectionResult::decode): Modernize DataDetectionResult's IPC decoding, so that it can be used with reply-based async IPC. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _removeDataDetectedLinks:]): (-[WKWebView _detectDataWithTypes:completionHandler:]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::detectDataInAllFrames): (WebKit::WebPageProxy::removeDataDetectedLinks): Add or remove data detected links from each frame in the page, and then propagate the new data detector results of the main frame to the UI process (this matches current behavior, where the results of -[WKWebView _dataDetectionResults] only reflects data detection results in the main frame of the page). * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::removeDataDetectedLinks): (WebKit::WebPage::detectDataInAllFrames): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: Add an API test to exercise the new WebKit SPI. * TestWebKitAPI/DataDetectorsCoreSPI.h: Added. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm: (-[WKWebView synchronouslyDetectDataWithTypes:]): (-[WKWebView synchronouslyRemoveDataDetectedLinks]): (TEST): * TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm: (TestWebKitAPI::TEST): (-[TestWKWebView tagsInBody]): Deleted. (-[TestWKWebView expectElementTagsInOrder:]): Deleted. (-[TestWKWebView expectElementCount:tagName:]): Deleted. (-[TestWKWebView expectElementTag:toComeBefore:]): Deleted. Rename this from `-expectElementCount:tagName:` to `-expectElementCount:querySelector:`. * TestWebKitAPI/Tests/WebKitCocoa/data-detectors.html: Added. Add a new test page containing some content that can be data detected. * TestWebKitAPI/cocoa/TestWKWebView.h: * TestWebKitAPI/cocoa/TestWKWebView.mm: (-[WKWebView tagsInBody]): (-[WKWebView expectElementTagsInOrder:]): (-[WKWebView expectElementCount:querySelector:]): (-[WKWebView expectElementTag:toComeBefore:]): Move some testing helper functions from WKAttachmentTests to a testing category on WKWebView. This allows us to use `-expectElementCount:querySelector:` in tests outside of WKAttachmentTests. (-[WKWebView objectByEvaluatingJavaScript:]): (-[WKWebView objectByEvaluatingJavaScriptWithUserGesture:]): (-[WKWebView stringByEvaluatingJavaScript:]): Move some common helper functions from TestWKWebView to a testing category on WKWebView. (-[TestWKWebView objectByEvaluatingJavaScript:]): Deleted. (-[TestWKWebView objectByEvaluatingJavaScriptWithUserGesture:]): Deleted. (-[TestWKWebView stringByEvaluatingJavaScript:]): Deleted. Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/editing/cocoa/DataDetection.h trunk/Source/WebCore/editing/cocoa/DataDetection.mm trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/Shared/Cocoa/DataDetectionResult.h trunk/Source/WebKit/Shared/Cocoa/DataDetectionResult.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm trunk/Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h trunk/Source/WebKit/UIProcess/WebPageProxy.cpp trunk/Source/WebKit/UIProcess/WebPageProxy.h trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp trunk/Source/WebKit/WebProcess/WebPage/WebPage.h trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.h trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm Added Paths trunk/Tools/TestWebKitAPI/DataDetectorsCoreSPI.h trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/data-detectors.html Diff Modified: trunk/Source/WebCore/ChangeLog (238470 => 238471) --- trunk/Source/WebCore/ChangeLog 2018-11-24 18:37:14 UTC (rev 238470) +++ trunk/Source/WebCore/ChangeLog 2018-11-24 21:06:09 UTC (rev 238471) @@ -1,3 +1,18 @@ +2018-11-24 Wenson
[webkit-changes] [238473] trunk/Source
Title: [238473] trunk/Source
Revision 238473
Author wenson_hs...@apple.com
Date 2018-11-24 17:45:54 -0800 (Sat, 24 Nov 2018)
Log Message
[Cocoa] Fix a few localizable string descriptions in WebEditCommandProxy.cpp and WebEditorClient.mm
https://bugs.webkit.org/show_bug.cgi?id=191945
Reviewed by Anders Carlsson.
Source/WebCore:
Run `update-webkit-localizable-strings`.
* en.lproj/Localizable.strings:
Source/WebKit:
Replace some a couple of command undo action name descriptions with "Undo action name", to match all other
edit commands.
* UIProcess/WebEditCommandProxy.cpp:
(WebKit::WebEditCommandProxy::nameForEditAction):
Source/WebKitLegacy/mac:
* WebCoreSupport/WebEditorClient.mm:
(undoNameForEditAction):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/en.lproj/Localizable.strings
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/WebEditCommandProxy.cpp
trunk/Source/WebKitLegacy/mac/ChangeLog
trunk/Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (238472 => 238473)
--- trunk/Source/WebCore/ChangeLog 2018-11-25 00:37:06 UTC (rev 238472)
+++ trunk/Source/WebCore/ChangeLog 2018-11-25 01:45:54 UTC (rev 238473)
@@ -1,3 +1,14 @@
+2018-11-24 Wenson Hsieh
+
+[Cocoa] Fix a few localizable string descriptions in WebEditCommandProxy.cpp and WebEditorClient.mm
+https://bugs.webkit.org/show_bug.cgi?id=191945
+
+Reviewed by Anders Carlsson.
+
+Run `update-webkit-localizable-strings`.
+
+* en.lproj/Localizable.strings:
+
2018-11-24 Sam Weinig
Remove now unnecessary specialized ListHashSet from InlineItem.h
Modified: trunk/Source/WebCore/en.lproj/Localizable.strings (238472 => 238473)
--- trunk/Source/WebCore/en.lproj/Localizable.strings 2018-11-25 00:37:06 UTC (rev 238472)
+++ trunk/Source/WebCore/en.lproj/Localizable.strings 2018-11-25 01:45:54 UTC (rev 238473)
@@ -187,10 +187,10 @@
/* Media Controls context menu item */
"Controls" = "Controls";
-/* Convert to ordered list action name */
+/* Undo action name */
"Convert to Ordered List (Undo action name)" = "Convert to Ordered List";
-/* Convert to unordered list action name */
+/* Undo action name */
"Convert to Unordered List (Undo action name)" = "Convert to Unordered List";
/* Copy context menu item */
@@ -595,12 +595,12 @@
/* Search in Spotlight context menu item */
"Search in Spotlight" = "Search in Spotlight";
+/* Search the Web context menu item */
+"Search the Web" = "Search the Web";
+
/* Search with search provider context menu item with provider name inserted */
"Search with %@" = "Search with %@";
-/* Search the Web context menu item */
-"Search the Web" = "Search the Web";
-
/* Validation message for required file inputs that have no value */
"Select a file" = "Select a file";
@@ -820,6 +820,9 @@
/* accessibility role description for a URL field. */
"URL field" = "URL field";
+/* Unacceptable TLS certificate error */
+"Unacceptable TLS certificate" = "Unacceptable TLS certificate";
+
/* Underline context menu item */
"Underline" = "Underline";
Modified: trunk/Source/WebKit/ChangeLog (238472 => 238473)
--- trunk/Source/WebKit/ChangeLog 2018-11-25 00:37:06 UTC (rev 238472)
+++ trunk/Source/WebKit/ChangeLog 2018-11-25 01:45:54 UTC (rev 238473)
@@ -1,5 +1,18 @@
2018-11-24 Wenson Hsieh
+[Cocoa] Fix a few localizable string descriptions in WebEditCommandProxy.cpp and WebEditorClient.mm
+https://bugs.webkit.org/show_bug.cgi?id=191945
+
+Reviewed by Anders Carlsson.
+
+Replace some a couple of command undo action name descriptions with "Undo action name", to match all other
+edit commands.
+
+* UIProcess/WebEditCommandProxy.cpp:
+(WebKit::WebEditCommandProxy::nameForEditAction):
+
+2018-11-24 Wenson Hsieh
+
[Cocoa] Add WKWebView SPI to trigger and remove data detection
https://bugs.webkit.org/show_bug.cgi?id=191918
Modified: trunk/Source/WebKit/UIProcess/WebEditCommandProxy.cpp (238472 => 238473)
--- trunk/Source/WebKit/UIProcess/WebEditCommandProxy.cpp 2018-11-25 00:37:06 UTC (rev 238472)
+++ trunk/Source/WebKit/UIProcess/WebEditCommandProxy.cpp 2018-11-25 01:45:54 UTC (rev 238473)
@@ -174,9 +174,9 @@
// FIXME: We should give internal clients a way to override these undo names. For instance, Mail refers to ordered and unordered lists as "numbered" and "bulleted" lists, respectively,
// despite the fact that ordered and unordered lists are not necessarily displayed using bullets and numerals.
case EditAction::ConvertToOrderedList:
-return WEB_UI_STRING_KEY("Convert to Ordered List", "Convert to Ordered List (Undo action name)", "Convert to ordered list action name");
+return WEB_UI_STRING_KEY("Convert to Ordered List", "Convert to Ordered List (Undo action name)", "Undo action name");
case EditAction::ConvertToUnorderedList:
-
[webkit-changes] [238380] trunk/Tools
Title: [238380] trunk/Tools
Revision 238380
Author wenson_hs...@apple.com
Date 2018-11-19 13:37:00 -0800 (Mon, 19 Nov 2018)
Log Message
[iOS Debug] Assertion failure in NSComparisonResult UIContentSizeCategoryCompareToCategory()
https://bugs.webkit.org/show_bug.cgi?id=190401
Reviewed by Dean Jackson.
Work around sporadic UIKit assertions when running API tests that may present a UICalloutBar. Currently, UIKit
asks for the `UIApp`’s `-preferredContentSizeCategory` when showing or laying out the callout bar. However,
TestWebKitAPI lacks a UIApp altogether, and forcing one to be initialized via `UIApplicationInstantiateSingleton`
causes numerous other UIKit and WebKit assertions to be hit.
In lieu of TestWebKitAPI becoming a real UI application (see https://webkit.org/b/175204), simply don't allow
the callout bar to be initialized in TestWKWebView-based API tests. This encompasses all API tests which
have some chance of causing the callout bar to be shown by making a ranged text selections during the test.
* TestWebKitAPI/cocoa/TestWKWebView.mm:
(suppressUICalloutBar):
(-[TestWKWebView initWithFrame:configuration:addToWindow:]):
* TestWebKitAPI/ios/UIKitSPI.h:
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm
trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h
Diff
Modified: trunk/Tools/ChangeLog (238379 => 238380)
--- trunk/Tools/ChangeLog 2018-11-19 21:22:51 UTC (rev 238379)
+++ trunk/Tools/ChangeLog 2018-11-19 21:37:00 UTC (rev 238380)
@@ -1,3 +1,25 @@
+2018-11-19 Wenson Hsieh
+
+[iOS Debug] Assertion failure in NSComparisonResult UIContentSizeCategoryCompareToCategory()
+https://bugs.webkit.org/show_bug.cgi?id=190401
+
+
+Reviewed by Dean Jackson.
+
+Work around sporadic UIKit assertions when running API tests that may present a UICalloutBar. Currently, UIKit
+asks for the `UIApp`’s `-preferredContentSizeCategory` when showing or laying out the callout bar. However,
+TestWebKitAPI lacks a UIApp altogether, and forcing one to be initialized via `UIApplicationInstantiateSingleton`
+causes numerous other UIKit and WebKit assertions to be hit.
+
+In lieu of TestWebKitAPI becoming a real UI application (see https://webkit.org/b/175204), simply don't allow
+the callout bar to be initialized in TestWKWebView-based API tests. This encompasses all API tests which
+have some chance of causing the callout bar to be shown by making a ranged text selections during the test.
+
+* TestWebKitAPI/cocoa/TestWKWebView.mm:
+(suppressUICalloutBar):
+(-[TestWKWebView initWithFrame:configuration:addToWindow:]):
+* TestWebKitAPI/ios/UIKitSPI.h:
+
2018-11-19 Fujii Hironori
REGRESSION(r238016)[GTK][TestWebKitAPI][Ninja] TestJSC can't compile "Bytecodes.h: No such file or directory"
Modified: trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm (238379 => 238380)
--- trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm 2018-11-19 21:22:51 UTC (rev 238379)
+++ trunk/Tools/TestWebKitAPI/cocoa/TestWKWebView.mm 2018-11-19 21:37:00 UTC (rev 238380)
@@ -28,6 +28,7 @@
#if WK_API_ENABLED
+#import "ClassMethodSwizzler.h"
#import "TestNavigationDelegate.h"
#import "Utilities.h"
@@ -185,6 +186,9 @@
@implementation TestWKWebView {
RetainPtr _hostWindow;
RetainPtr _testHandler;
+#if PLATFORM(IOS_FAMILY)
+std::unique_ptr _sharedCalloutBarSwizzler;
+#endif
}
- (instancetype)initWithFrame:(CGRect)frame
@@ -198,6 +202,15 @@
return [self initWithFrame:frame configuration:configuration addToWindow:YES];
}
+#if PLATFORM(IOS_FAMILY)
+
+static UICalloutBar *suppressUICalloutBar()
+{
+return nil;
+}
+
+#endif
+
- (instancetype)initWithFrame:(CGRect)frame configuration:(WKWebViewConfiguration *)configuration addToWindow:(BOOL)addToWindow
{
self = [super initWithFrame:frame configuration:configuration];
@@ -207,6 +220,11 @@
if (addToWindow)
[self _setUpTestWindow:frame];
+#if PLATFORM(IOS_FAMILY)
+// FIXME: Remove this workaround once is fixed.
+_sharedCalloutBarSwizzler = std::make_unique([UICalloutBar class], @selector(sharedCalloutBar), reinterpret_cast(suppressUICalloutBar));
+#endif
+
return self;
}
Modified: trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h (238379 => 238380)
--- trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2018-11-19 21:22:51 UTC (rev 238379)
+++ trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2018-11-19 21:37:00 UTC (rev 238380)
@@ -30,6 +30,7 @@
#if USE(APPLE_INTERNAL_SDK)
#import
+#import
#import
#import
#import
@@ -97,6 +98,10 @@
- (NSDictionary *)_autofillContext;
@end
+@interface UICalloutBar : UIView
++ (UICalloutBar *)sharedCalloutBar;
+@end
+
#if ENABLE(DRAG_SUPPORT)
@protocol UIDragInteractionDelegate_Proposed_SPI_33146803
- (void)_dragInteraction:(UIDragInteraction *)interaction itemsForAddingToSession:(id )session withTouchAtPoint:(CGPoint)point
[webkit-changes] [238383] trunk/Tools
Title: [238383] trunk/Tools Revision 238383 Author wenson_hs...@apple.com Date 2018-11-19 16:26:10 -0800 (Mon, 19 Nov 2018) Log Message Unreviewed, fix the internal iOS debug build after r238380 UICalloutBar should only be declared when the public (non-internal) SDK is used to build WebKit; otherwise, we end up with duplicate declarations of UICalloutBar. * TestWebKitAPI/ios/UIKitSPI.h: Modified Paths trunk/Tools/ChangeLog trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h Diff Modified: trunk/Tools/ChangeLog (238382 => 238383) --- trunk/Tools/ChangeLog 2018-11-19 23:33:53 UTC (rev 238382) +++ trunk/Tools/ChangeLog 2018-11-20 00:26:10 UTC (rev 238383) @@ -1,3 +1,12 @@ +2018-11-19 Wenson Hsieh + +Unreviewed, fix the internal iOS debug build after r238380 + +UICalloutBar should only be declared when the public (non-internal) SDK is used to build WebKit; otherwise, we +end up with duplicate declarations of UICalloutBar. + +* TestWebKitAPI/ios/UIKitSPI.h: + 2018-11-19 David Quesada EXC_BAD_ACCESS when invoking a DownloadProxy's destination decision handler after the download has been canceled Modified: trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h (238382 => 238383) --- trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2018-11-19 23:33:53 UTC (rev 238382) +++ trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2018-11-20 00:26:10 UTC (rev 238383) @@ -92,6 +92,10 @@ @interface UIKeyboard : UIView @end +@interface UICalloutBar : UIView ++ (UICalloutBar *)sharedCalloutBar; +@end + #endif @protocol UITextInputTraits_Private_Proposed_SPI_34583628 @@ -98,10 +102,6 @@ - (NSDictionary *)_autofillContext; @end -@interface UICalloutBar : UIView -+ (UICalloutBar *)sharedCalloutBar; -@end - #if ENABLE(DRAG_SUPPORT) @protocol UIDragInteractionDelegate_Proposed_SPI_33146803 - (void)_dragInteraction:(UIDragInteraction *)interaction itemsForAddingToSession:(id )session withTouchAtPoint:(CGPoint)point completion:(void(^)(NSArray *))completion; ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238485] trunk/Tools
Title: [238485] trunk/Tools
Revision 238485
Author wenson_hs...@apple.com
Date 2018-11-25 14:59:07 -0800 (Sun, 25 Nov 2018)
Log Message
Unreviewed, fix the internal iOS 12 build after r238471
* TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm:
(TEST):
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm
Diff
Modified: trunk/Tools/ChangeLog (238484 => 238485)
--- trunk/Tools/ChangeLog 2018-11-25 22:11:24 UTC (rev 238484)
+++ trunk/Tools/ChangeLog 2018-11-25 22:59:07 UTC (rev 238485)
@@ -1,3 +1,10 @@
+2018-11-25 Wenson Hsieh
+
+Unreviewed, fix the internal iOS 12 build after r238471
+
+* TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm:
+(TEST):
+
2018-11-25 Tim Horton
Make it possible to insert editable images with a gesture
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm (238484 => 238485)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm 2018-11-25 22:11:24 UTC (rev 238484)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm 2018-11-25 22:59:07 UTC (rev 238485)
@@ -135,17 +135,20 @@
auto checkDataDetectionResults = [] (NSArray *results) {
EXPECT_EQ(3U, results.count);
-EXPECT_EQ(DDResultCategoryUnknown, results[0].category);
EXPECT_TRUE([results[0].value containsString:@"+1-234-567-8900"]);
EXPECT_TRUE([results[0].value containsString:@"https://www.apple.com"]);
EXPECT_TRUE([results[0].value containsString:@"2 Apple Park Way, Cupertino 95014"]);
EXPECT_WK_STREQ("SignatureBlock", results[0].type);
-EXPECT_EQ(DDResultCategoryCalendarEvent, results[1].category);
EXPECT_WK_STREQ("Date", results[1].type);
EXPECT_WK_STREQ("December 21, 2021", results[1].value);
-EXPECT_EQ(DDResultCategoryMisc, results[2].category);
EXPECT_WK_STREQ("FlightInformation", results[2].type);
EXPECT_WK_STREQ("AC780", results[2].value);
+
+#if __IPHONE_OS_VERSION_MIN_REQUIRED >= 13
+EXPECT_EQ(DDResultCategoryUnknown, results[0].category);
+EXPECT_EQ(DDResultCategoryCalendarEvent, results[1].category);
+EXPECT_EQ(DDResultCategoryMisc, results[2].category);
+#endif
};
[webView synchronouslyDetectDataWithTypes:WKDataDetectorTypeAll];
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238553] trunk/Source/WebKit
Title: [238553] trunk/Source/WebKit
Revision 238553
Author wenson_hs...@apple.com
Date 2018-11-27 07:51:43 -0800 (Tue, 27 Nov 2018)
Log Message
WebKit.AddAndRemoveDataDetectors hits a debug assertion after r238515
https://bugs.webkit.org/show_bug.cgi?id=191996
Reviewed by Tim Horton.
This assertion is hit because `decode(Decoder& decoder, NSArray *allowedClasses)` expects the decoded
object (of class `_NSArrayM`) to be equal to `NSArray.class`.
We fix the crash by relaxing the debug assertion when decoding securely-codable objects over IPC. Instead of
checking that the class of the decoded object is equal to one of the allowed classes, check that the object is a
kind of any of the allowed classes.
* Shared/Cocoa/ArgumentCodersCocoa.h:
(IPC::isObjectClassAllowed):
(IPC::decode):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.h
Diff
Modified: trunk/Source/WebKit/ChangeLog (238552 => 238553)
--- trunk/Source/WebKit/ChangeLog 2018-11-27 15:29:55 UTC (rev 238552)
+++ trunk/Source/WebKit/ChangeLog 2018-11-27 15:51:43 UTC (rev 238553)
@@ -1,3 +1,21 @@
+2018-11-27 Wenson Hsieh
+
+WebKit.AddAndRemoveDataDetectors hits a debug assertion after r238515
+https://bugs.webkit.org/show_bug.cgi?id=191996
+
+Reviewed by Tim Horton.
+
+This assertion is hit because `decode(Decoder& decoder, NSArray *allowedClasses)` expects the decoded
+object (of class `_NSArrayM`) to be equal to `NSArray.class`.
+
+We fix the crash by relaxing the debug assertion when decoding securely-codable objects over IPC. Instead of
+checking that the class of the decoded object is equal to one of the allowed classes, check that the object is a
+kind of any of the allowed classes.
+
+* Shared/Cocoa/ArgumentCodersCocoa.h:
+(IPC::isObjectClassAllowed):
+(IPC::decode):
+
2018-11-27 Tomas Popela
[GTK][WPE] Remove temporary workaround in Source/WebKit/Platform*.cmake
Modified: trunk/Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.h (238552 => 238553)
--- trunk/Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.h 2018-11-27 15:29:55 UTC (rev 238552)
+++ trunk/Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.h 2018-11-27 15:51:43 UTC (rev 238553)
@@ -43,6 +43,19 @@
return decode(decoder, @[ allowedClass ]);
}
+#ifndef NDEBUG
+
+static inline bool isObjectClassAllowed(id object, NSArray *allowedClasses)
+{
+for (Class allowedClass in allowedClasses) {
+if ([object isKindOfClass:allowedClass])
+return true;
+}
+return false;
+}
+
+#endif
+
template
std::optional> decode(Decoder& decoder, NSArray *allowedClasses)
{
@@ -54,7 +67,7 @@
return { nullptr };
id object = result->leakRef();
-ASSERT([allowedClasses containsObject:[object class]]);
+ASSERT(isObjectClassAllowed(object, allowedClasses));
return { adoptNS(static_cast(object)) };
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238584] trunk/Tools
Title: [238584] trunk/Tools
Revision 238584
Author wenson_hs...@apple.com
Date 2018-11-27 15:54:06 -0800 (Tue, 27 Nov 2018)
Log Message
Unreviewed, fix the watchOS engineering build
Disable a newly added API test, since DDScannerResult is unavailable on watchOS.
* TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm:
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm
Diff
Modified: trunk/Tools/ChangeLog (238583 => 238584)
--- trunk/Tools/ChangeLog 2018-11-27 23:46:18 UTC (rev 238583)
+++ trunk/Tools/ChangeLog 2018-11-27 23:54:06 UTC (rev 238584)
@@ -1,3 +1,11 @@
+2018-11-27 Wenson Hsieh
+
+Unreviewed, fix the watchOS engineering build
+
+Disable a newly added API test, since DDScannerResult is unavailable on watchOS.
+
+* TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm:
+
2018-11-27 Chris Dumez
Regression(PSON) crash under WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame()
Modified: trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm (238583 => 238584)
--- trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm 2018-11-27 23:46:18 UTC (rev 238583)
+++ trunk/Tools/TestWebKitAPI/Tests/WebKitCocoa/DataDetection.mm 2018-11-27 23:54:06 UTC (rev 238584)
@@ -126,6 +126,8 @@
expectLinkCount(webView.get(), @"yesterday at 6PM", 1);
}
+#if PLATFORM(IOS)
+
TEST(WebKit, AddAndRemoveDataDetectors)
{
auto webView = adoptNS([[TestWKWebView alloc] initWithFrame:CGRectMake(0, 0, 320, 500)]);
@@ -164,4 +166,6 @@
checkDataDetectionResults([webView _dataDetectionResults]);
}
+#endif // PLATFORM(IOS)
+
#endif
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238438] trunk
Title: [238438] trunk Revision 238438 Author wenson_hs...@apple.com Date 2018-11-21 21:03:59 -0800 (Wed, 21 Nov 2018) Log Message [Cocoa] [WebKit2] Add support for replacing find-in-page text matches https://bugs.webkit.org/show_bug.cgi?id=191786 Reviewed by Ryosuke Niwa. Source/WebCore: Add support for replacing Find-in-Page matches. See below for details. Covered by new layout tests as well as a new API test. Tests: editing/find/find-and-replace-adjacent-words.html editing/find/find-and-replace-at-editing-boundary.html editing/find/find-and-replace-basic.html editing/find/find-and-replace-in-subframes.html editing/find/find-and-replace-no-matches.html editing/find/find-and-replace-noneditable-matches.html editing/find/find-and-replace-replacement-text-input-events.html API test: WebKit.FindAndReplace * page/Page.cpp: (WebCore::replaceRanges): (WebCore::Page::replaceRangesWithText): Add a helper that, given a list of Ranges, replaces each range with the given text. To do this, we first map each Range to editing offsets within the topmost editable root for each Range. This results in a map of editable root to list of editing offsets we need to replace. To apply the replacements, for each editable root in the map, we iterate over each replacement range (i.e. an offset and length), set the current selection to contain that replacement range, and use `Editor::replaceSelectionWithText`. To prevent prior text replacements from clobbering the offsets of latter text replacement ranges, we also iterate backwards through text replacement ranges when performing each replacement. Likewise, we also apply text replacement to each editing container in backwards order: for nodes in the same frame, we compare their position in the document, and for nodes in different frames, we instead compare their frames in frame tree traversal order. We map Ranges to editing offsets and back when performing text replacement because each text replacement may split or merge text nodes, which causes adjacent Ranges to shrink or extend while replacing text. In an earlier attempt to implement this, I simply iterated over each Range to replace and carried out text replacement for each Range. This led to incorrect behavior in some cases, such as replacing adjacent matches. Thus, by computing the set of text replacement offsets prior to replacing any text, we're able to target the correct ranges for replacement. (WebCore::Page::replaceSelectionWithText): Add a helper method on Page to replace the current selection with some text. This simply calls out to `Editor::replaceSelectionWithText`. * page/Page.h: Source/WebCore/PAL: Add `-replaceMatches:withString:inSelectionOnly:resultCollector:`. * pal/spi/mac/NSTextFinderSPI.h: Source/WebKit: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView replaceMatches:withString:inSelectionOnly:resultCollector:]): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::replaceMatches): * UIProcess/WebPageProxy.h: * UIProcess/mac/WKTextFinderClient.mm: (-[WKTextFinderClient replaceMatches:withString:inSelectionOnly:resultCollector:]): Implement this method to opt in to "Replace…" UI on macOS in the find bar. In this API, we're given a list of matches to replace. We propagate the indices of each match to the web process, where FindController maps them to corresponding replacement ranges. Currently, the given list of matches is only ever a list containing the first match, or a list containing all matches. * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp: (WKBundlePageFindStringMatches): (WKBundlePageReplaceStringMatches): * WebProcess/InjectedBundle/API/c/WKBundlePage.h: * WebProcess/WebCoreSupport/WebEditorClient.cpp: * WebProcess/WebPage/FindController.cpp: (WebKit::FindController::replaceMatches): Map match indices to Ranges, and then call into WebCore::Page to do the heavy lifting (see WebCore ChangeLog for more details). Additionally add a hard find-and-replace limit here to prevent the web process from spinning indefinitely if there are an enormous number of find matches. * WebProcess/WebPage/FindController.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::findStringMatchesFromInjectedBundle): (WebKit::WebPage::replaceStringMatchesFromInjectedBundle): Add helpers to exercise find and replace in WebKit2. (WebKit::WebPage::replaceMatches): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Tools: * MiniBrowser/mac/WK2BrowserWindowController.m: (-[WK2BrowserWindowController setFindBarView:]): Fix a bug in MiniBrowser that prevents AppKit from displaying the "All" button in the find bar after checking the "Replace" option. * TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm: Add an API test to exercise find-and-replace API using WKWebView. (replaceMatches): (TEST): * WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::findOptionsFromArray):
[webkit-changes] [238454] trunk/Source
Title: [238454] trunk/Source
Revision 238454
Author wenson_hs...@apple.com
Date 2018-11-22 19:10:34 -0800 (Thu, 22 Nov 2018)
Log Message
Address post-review feedback after r238438
https://bugs.webkit.org/show_bug.cgi?id=191913
Reviewed by Ryosuke Niwa.
Source/WebCore:
Replace `bool` arguments to `FrameSelection::setSelectedRange`, `Editor::replaceSelectionWithText`, and
`Editor::replaceSelectionWithFragment` with `enum class`es instead. In particular, introduce the following:
FrameSelection::ShouldCloseTyping { No, Yes }
Editor::SelectReplacement { No, Yes }
Editor::SmartReplace { No, Yes }
Editor::MatchStyle { No, Yes }
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::selectText):
* editing/Editor.cpp:
(WebCore::Editor::handleTextEvent):
(WebCore::Editor::replaceSelectionWithFragment):
(WebCore::Editor::replaceSelectionWithText):
(WebCore::Editor::setComposition):
(WebCore::Editor::markMisspellingsAfterTypingToWord):
(WebCore::Editor::changeBackToReplacedString):
(WebCore::Editor::transpose):
(WebCore::Editor::insertAttachment):
At various call sites, replace boolean arguments with named enums.
* editing/Editor.h:
* editing/EditorCommand.cpp:
(WebCore::expandSelectionToGranularity):
(WebCore::executeDeleteToMark):
(WebCore::executeSelectToMark):
* editing/FrameSelection.cpp:
(WebCore::FrameSelection::setSelectedRange):
* editing/FrameSelection.h:
* page/Page.cpp:
(WebCore::replaceRanges):
Avoid a bit of ref-count churn, and adjust a few functions to take `const Vector&`s instead of `Vector&&`s.
(WebCore::Page::replaceRangesWithText):
(WebCore::Page::replaceSelectionWithText):
* page/Page.h:
Source/WebKit:
Replace boolean arguments to setSelectedRange, replaceSelectionWithText and replaceSelectionWithFragment with
enum flags, and tweak a couple of functions to take `const Vector&` instead of `Vector&&`.
* WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageReplaceStringMatches):
* WebProcess/WebPage/FindController.cpp:
(WebKit::FindController::replaceMatches):
* WebProcess/WebPage/FindController.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::replaceStringMatchesFromInjectedBundle):
(WebKit::WebPage::replaceMatches):
(WebKit::WebPage::replaceSelectionWithText):
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::selectWithGesture):
(WebKit::WebPage::updateSelectionWithTouches):
(WebKit::WebPage::selectWithTwoTouches):
(WebKit::WebPage::extendSelection):
(WebKit::WebPage::selectWordBackward):
(WebKit::WebPage::moveSelectionByOffset):
(WebKit::WebPage::selectPositionAtPoint):
(WebKit::WebPage::selectPositionAtBoundaryWithDirection):
(WebKit::WebPage::moveSelectionAtBoundaryWithDirection):
(WebKit::WebPage::selectTextWithGranularityAtPoint):
(WebKit::WebPage::updateSelectionWithExtentPointAndBoundary):
(WebKit::WebPage::updateSelectionWithExtentPoint):
(WebKit::WebPage::replaceSelectedText):
(WebKit::WebPage::replaceDictatedText):
(WebKit::WebPage::syncApplyAutocorrection):
Source/WebKitLegacy/mac:
* WebView/WebFrame.mm:
(-[WebFrame setSelectedDOMRange:affinity:closeTyping:]):
(-[WebFrame _replaceSelectionWithFragment:selectReplacement:smartReplace:matchStyle:]):
* WebView/WebView.mm:
(-[WebView setSelectedDOMRange:affinity:]):
Source/WebKitLegacy/win:
* AccessibleTextImpl.cpp:
(AccessibleText::replaceText):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/accessibility/AccessibilityObject.cpp
trunk/Source/WebCore/editing/Editor.cpp
trunk/Source/WebCore/editing/Editor.h
trunk/Source/WebCore/editing/EditorCommand.cpp
trunk/Source/WebCore/editing/FrameSelection.cpp
trunk/Source/WebCore/editing/FrameSelection.h
trunk/Source/WebCore/page/Page.cpp
trunk/Source/WebCore/page/Page.h
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp
trunk/Source/WebKit/WebProcess/WebPage/FindController.cpp
trunk/Source/WebKit/WebProcess/WebPage/FindController.h
trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp
trunk/Source/WebKit/WebProcess/WebPage/WebPage.h
trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
trunk/Source/WebKitLegacy/mac/ChangeLog
trunk/Source/WebKitLegacy/mac/WebView/WebFrame.mm
trunk/Source/WebKitLegacy/mac/WebView/WebView.mm
trunk/Source/WebKitLegacy/win/AccessibleTextImpl.cpp
trunk/Source/WebKitLegacy/win/ChangeLog
Diff
Modified: trunk/Source/WebCore/ChangeLog (238453 => 238454)
--- trunk/Source/WebCore/ChangeLog 2018-11-23 01:33:40 UTC (rev 238453)
+++ trunk/Source/WebCore/ChangeLog 2018-11-23 03:10:34 UTC (rev 238454)
@@ -1,3 +1,49 @@
+2018-11-22 Wenson Hsieh
+
+Address post-review feedback after r238438
+https://bugs.webkit.org/show_bug.cgi?id=191913
+
+Reviewed by Ryosuke Niwa.
+
+Replace `bool` arguments to `FrameSelection::setSelectedRange`, `Editor::replaceSelectionWithText`, and
+`Editor::replaceSelectionWithFragment` with `enum class`es instead. In particular, introduce the
[webkit-changes] [238455] trunk/Source/WebKit
Title: [238455] trunk/Source/WebKit
Revision 238455
Author wenson_hs...@apple.com
Date 2018-11-22 20:00:31 -0800 (Thu, 22 Nov 2018)
Log Message
[Cocoa] clang emits a warning when building WebKit after r238293
https://bugs.webkit.org/show_bug.cgi?id=191917
Reviewed by Dan Bernstein.
Move the implementations of -setSafeBrowsingEnabled: and -isSafeBrowsingEnabled to the main implementation of
WKPreferences to fix the warning.
* UIProcess/API/Cocoa/WKPreferences.mm:
(-[WKPreferences setSafeBrowsingEnabled:]):
(-[WKPreferences isSafeBrowsingEnabled]):
Modified Paths
trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm
Diff
Modified: trunk/Source/WebKit/ChangeLog (238454 => 238455)
--- trunk/Source/WebKit/ChangeLog 2018-11-23 03:10:34 UTC (rev 238454)
+++ trunk/Source/WebKit/ChangeLog 2018-11-23 04:00:31 UTC (rev 238455)
@@ -1,5 +1,19 @@
2018-11-22 Wenson Hsieh
+[Cocoa] clang emits a warning when building WebKit after r238293
+https://bugs.webkit.org/show_bug.cgi?id=191917
+
+Reviewed by Dan Bernstein.
+
+Move the implementations of -setSafeBrowsingEnabled: and -isSafeBrowsingEnabled to the main implementation of
+WKPreferences to fix the warning.
+
+* UIProcess/API/Cocoa/WKPreferences.mm:
+(-[WKPreferences setSafeBrowsingEnabled:]):
+(-[WKPreferences isSafeBrowsingEnabled]):
+
+2018-11-22 Wenson Hsieh
+
Address post-review feedback after r238438
https://bugs.webkit.org/show_bug.cgi?id=191913
Modified: trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm (238454 => 238455)
--- trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm 2018-11-23 03:10:34 UTC (rev 238454)
+++ trunk/Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm 2018-11-23 04:00:31 UTC (rev 238455)
@@ -140,6 +140,16 @@
_preferences->setStorageAccessPromptsEnabled(enabled);
}
+- (void)setSafeBrowsingEnabled:(BOOL)enabled
+{
+_preferences->setSafeBrowsingEnabled(enabled);
+}
+
+- (BOOL)isSafeBrowsingEnabled
+{
+return _preferences->safeBrowsingEnabled();
+}
+
#pragma mark OS X-specific methods
#if PLATFORM(MAC)
@@ -697,16 +707,6 @@
_preferences->setICECandidateFilteringEnabled(enabled);
}
-- (void)setSafeBrowsingEnabled:(BOOL)enabled
-{
-_preferences->setSafeBrowsingEnabled(enabled);
-}
-
-- (BOOL)isSafeBrowsingEnabled
-{
-return _preferences->safeBrowsingEnabled();
-}
-
- (BOOL)_webRTCLegacyAPIEnabled
{
return NO;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238375] trunk
Title: [238375] trunk
Revision 238375
Author wenson_hs...@apple.com
Date 2018-11-19 08:31:22 -0800 (Mon, 19 Nov 2018)
Log Message
Dragging image with a border-image larger than the image element crashes
https://bugs.webkit.org/show_bug.cgi?id=191817
Reviewed by Ryosuke Niwa.
Source/WebCore:
When dragging an image element, if the image element has:
(1) box-sizing: border-box;
(2) a border-image
(3) a border-top-width that is at least as large as the height of the element and/or a border-left-width that is
at least as large as the width of the element
...then upon drag, we will fail to create a suitable drag image using the bounding box of the image element
since the size is empty, thereby causing a crash. To fix this, we bail out of this bounding-rect-dependent
codepath for generating a drag image in the case where the bounding rect is empty, and instead fall back to an
icon representation for the drag image.
Test: fast/events/drag-image-with-border-image.html
* page/DragController.cpp:
(WebCore::DragController::doImageDrag):
LayoutTests:
Verifies that an image that meets the pathological criteria described in Source/WebCore/ChangeLog can still be
dragged and dropped into an editable area.
* fast/events/drag-image-with-border-image.html: Added.
* platform/gtk/TestExpectations:
* platform/ios/TestExpectations:
* platform/mac-wk2/TestExpectations:
* platform/wpe/TestExpectations:
Enable this test only in WebKit1.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/platform/gtk/TestExpectations
trunk/LayoutTests/platform/ios/TestExpectations
trunk/LayoutTests/platform/mac-wk2/TestExpectations
trunk/LayoutTests/platform/wpe/TestExpectations
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/DragController.cpp
Added Paths
trunk/LayoutTests/fast/events/drag-image-with-border-image-expected.txt
trunk/LayoutTests/fast/events/drag-image-with-border-image.html
Diff
Modified: trunk/LayoutTests/ChangeLog (238374 => 238375)
--- trunk/LayoutTests/ChangeLog 2018-11-19 16:26:42 UTC (rev 238374)
+++ trunk/LayoutTests/ChangeLog 2018-11-19 16:31:22 UTC (rev 238375)
@@ -1,3 +1,22 @@
+2018-11-19 Wenson Hsieh
+
+Dragging image with a border-image larger than the image element crashes
+https://bugs.webkit.org/show_bug.cgi?id=191817
+
+
+Reviewed by Ryosuke Niwa.
+
+Verifies that an image that meets the pathological criteria described in Source/WebCore/ChangeLog can still be
+dragged and dropped into an editable area.
+
+* fast/events/drag-image-with-border-image.html: Added.
+* platform/gtk/TestExpectations:
+* platform/ios/TestExpectations:
+* platform/mac-wk2/TestExpectations:
+* platform/wpe/TestExpectations:
+
+Enable this test only in WebKit1.
+
2018-11-18 Yusuke Suzuki
Unreviewed, rolling in the rest of r237254
Added: trunk/LayoutTests/fast/events/drag-image-with-border-image-expected.txt (0 => 238375)
--- trunk/LayoutTests/fast/events/drag-image-with-border-image-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/events/drag-image-with-border-image-expected.txt 2018-11-19 16:31:22 UTC (rev 238375)
@@ -0,0 +1,10 @@
+PASS receivedDropEvent is true
+PASS !!destination.querySelector("img") is true
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
+
+This test verifies that the web process does not crash when dragging an image element with a border image whose dimensions exceeds the dimensions of the image element itself. To manually test, try to drag the contents of the solid red box; the web process should not crash, and dropping into the green editable area should insert an image.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
Added: trunk/LayoutTests/fast/events/drag-image-with-border-image.html (0 => 238375)
--- trunk/LayoutTests/fast/events/drag-image-with-border-image.html (rev 0)
+++ trunk/LayoutTests/fast/events/drag-image-with-border-image.html 2018-11-19 16:31:22 UTC (rev 238375)
@@ -0,0 +1,55 @@
+
+
+
+img {
+border-image: url(./resources/abe.png);
+border-top-width: 100px;
+border-left-width: 100px;
+box-sizing: border-box;
+}
+
+#container {
+border: solid 1px red;
+}
+
+#destination {
+border: dashed 1px green;
+}
+
+img, #destination, #container {
+width: 100px;
+height: 100px;
+}
+
+
+
+![]()
+
+
+