Timeline
Jul 20, 2019:
- 8:53 PM Changeset in webkit [247673] by
-
- 9 edits in trunk
Speed up HashTable decoding by reserving capacity and avoiding rehashing
https://bugs.webkit.org/show_bug.cgi?id=199982
Reviewed by Saam Barati.
Source/WebKit:
Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
performance. I measured a ~35% improvement when decoding a very large
HashMap of Strings (~160k entries) in the context of the
StorageManager::GetValues IPC.
- Platform/IPC/ArgumentCoders.h:
- Shared/API/c/WKDictionary.cpp:
(WKDictionaryCreate):
Source/WTF:
Introduce reserveInitialCapacity() on HashMap to reserve capacity on a
HashMap and cut down on rehashing cost when possible.
- wtf/HashMap.h:
- wtf/HashTable.h:
(WTF::HashTable::reserveInitialCapacity):
- wtf/persistence/PersistentCoders.h:
Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for
performance.
Tools:
Add API test coverage.
- TestWebKitAPI/Tests/WTF/HashMap.cpp:
(TestWebKitAPI::TEST):
- 6:04 PM Changeset in webkit [247672] by
-
- 3 edits in trunk/Source/WebKit
Micro-optimize HashMap & String IPC decoding
https://bugs.webkit.org/show_bug.cgi?id=199967
Reviewed by Geoffrey Garen.
The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
the key & value when calling HashMap::add(). The modern decoder (returning
an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
to call the modern one to reduce code duplication and to get this optimization.
Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
HashMap::size() returns an 'unsigned int' type. Finally, update the modern
decoder to WTFMove(hashMap) when returning. Because the function returns an
Optional<HashMap> and not a HashMap, I do not believe we get return value
optimization (RVO).
Do similar changes to String IPC coders.
- Platform/IPC/ArgumentCoders.cpp:
(IPC::decodeStringText):
(IPC::ArgumentCoder<String>::decode):
- Platform/IPC/ArgumentCoders.h:
- 3:04 PM Changeset in webkit [247671] by
-
- 19 edits2 adds in trunk
Add accessibilityInsertText for text insertion in edit fields.
https://bugs.webkit.org/show_bug.cgi?id=199973
Patch by Andres Gonzalez <Andres Gonzalez> on 2019-07-20
Reviewed by Chris Fleizach.
Source/WebCore:
Tests: accessibility/insert-newline.html
accessibility/ios-simulator/insert-newline.html
Accessibility clients like VoiceOver and Voice Control were entering
text in text fields by replacing the entire content of the field
(SetValue) and then setting the insertion point to the appropriate
offset (SetSelectedTextRange). accessibilityInsertText gives a simpler
interface to clients to insert text at the insertion point location.
In addition, this provides a workaround for the issue encountered with
the previous method when inserting a linebreak.
- accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::insertText):
- accessibility/AccessibilityObject.h:
- accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:
(-[WebAccessibilityObjectWrapper accessibilityInsertText:]):
- accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityInsertText:]):
Tools:
Glue code to run new LayoutTests.
- WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
- WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
- WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:
(WTR::AccessibilityUIElement::insertText):
- WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm:
(WTR::AccessibilityUIElement::insertText):
- WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::insertText):
- WebKitTestRunner/InjectedBundle/win/AccessibilityUIElementWin.cpp:
(WTR::AccessibilityUIElement::insertText):
LayoutTests:
Tests for inserting a newline in the middle of a text line and checking
that the insertion point and text ranges are correct.
- accessibility/insert-newline-expected.txt: Added.
- accessibility/insert-newline.html: Added.
- accessibility/ios-simulator/insert-newline-expected.txt: Added.
- accessibility/ios-simulator/insert-newline.html: Added.
- 1:11 PM Changeset in webkit [247670] by
-
- 8 edits in trunk/Source
REGRESSION(r246033/r246496): [GTK] Kinetic scrolling doesn't work
https://bugs.webkit.org/show_bug.cgi?id=199322
Patch by Alexander Mikhaylenko <exalm7659@gmail.com> on 2019-07-20
Reviewed by Michael Catanzaro.
Source/WebCore:
Check ENABLE(KINETIC_SCROLLING) instead of ENABLE(ASYNC_SCROLLING) for kinetic scrolling.
- platform/PlatformWheelEvent.h:
- platform/generic/ScrollAnimatorGeneric.cpp:
(WebCore::ScrollAnimatorGeneric::handleWheelEvent):
- platform/gtk/PlatformWheelEventGtk.cpp:
(WebCore::PlatformWheelEvent::PlatformWheelEvent):
Source/WebKit:
Check ENABLE(KINETIC_SCROLLING) instead of ENABLE(ASYNC_SCROLLING) when setting wheel event phase and momentum phase.
- Shared/WebEventConversion.cpp:
(WebKit::WebKit2PlatformWheelEvent::WebKit2PlatformWheelEvent):
Source/WTF:
Introduce ENABLE_KINETIC_SCROLLING to explicitly always have kinetic scrolling on GTK.
- wtf/Platform.h:
- 11:53 AM Changeset in webkit [247669] by
-
- 4 edits7 adds in trunk/Source/WebCore
[LFC][TFC] Introduce table formatting context.
https://bugs.webkit.org/show_bug.cgi?id=199979
<rdar://problem/53346292>
Reviewed by Antti Koivisto.
Add the basic class structure for the table formatting context.
https://www.w3.org/TR/CSS22/tables.html
- Sources.txt:
- WebCore.xcodeproj/project.pbxproj:
- layout/FormattingState.h:
(WebCore::Layout::FormattingState::isTableFormattingState const):
- layout/tableformatting/TableFormattingContext.cpp: Added.
(WebCore::Layout::TableFormattingContext::TableFormattingContext):
(WebCore::Layout::TableFormattingContext::layout const):
- layout/tableformatting/TableFormattingContext.h: Added.
- layout/tableformatting/TableFormattingState.cpp: Added.
(WebCore::Layout::TableFormattingState::TableFormattingState):
(WebCore::Layout::TableFormattingState::~TableFormattingState):
- layout/tableformatting/TableFormattingState.h: Added.
- layout/tableformatting/TableInvalidation.cpp: Added.
(WebCore::Layout::TableInvalidation::invalidate):
- layout/tableformatting/TableInvalidation.h: Added.
- 11:52 AM Changeset in webkit [247668] by
-
- 6 edits in trunk/Source/WebCore
[LFC][IFC] Add support for mid-word break.
https://bugs.webkit.org/show_bug.cgi?id=199976
<rdar://problem/53337349>
Reviewed by Antti Koivisto.
Introduce leading and trailing InlineTextItem to support incoming and outgoing partial content.
TextUtil::split is a straight copy of SimpleLineLayout::split.
- layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
(WebCore::Layout::inlineItemWidth):
(WebCore::Layout::LineLayout::close):
(WebCore::Layout::LineLayout::placeInlineItem):
(WebCore::Layout::LineLayout::layout):
- layout/inlineformatting/InlineTextItem.cpp:
(WebCore::Layout::InlineTextItem::split const):
(WebCore::Layout::InlineTextItem::split): Deleted.
- layout/inlineformatting/InlineTextItem.h:
(WebCore::Layout::InlineTextItem::inlineBox const):
- layout/inlineformatting/text/TextUtil.cpp:
(WebCore::Layout::TextUtil::split):
- layout/inlineformatting/text/TextUtil.h:
- 6:47 AM Changeset in webkit [247667] by
-
- 10 edits in trunk/Source
[Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate
https://bugs.webkit.org/show_bug.cgi?id=199718
<rdar://problem/53344961>
Reviewed by Simon Fraser.
Source/WebCore:
When the page scale changes (e.g. as the result of shink to fit mode) we need to visit all the text content on the page and check whether they need to be boosted.
Currently we call setNeedsRecalcStyleInAllFrames() to accomplish it. Unfortunatelly setNeedsRecalcStyleInAllFrames destroys all the style information which means that the
subsequent styleResolve() needs to start from scratch.
This patch addresses this issue by directly adjusting the computed style information when text boosting is required and schedules layout accordingly. We also trigger this style adjusting
on a timer so that rapid dynamicViewportSizeUpdate() calls won't trigger redundant layouts.
- css/StyleResolver.cpp:
(WebCore::hasTextChild):
(WebCore::StyleResolver::adjustRenderStyleForTextAutosizing):
(WebCore::hasTextChildren): Deleted.
- css/StyleResolver.h:
- page/FrameView.h:
- page/Page.cpp:
(WebCore::Page::invalidateTextAutoSizeInAllFrames):
- page/Page.h:
Source/WebKit:
- WebProcess/WebPage/WebPage.cpp:
(WebKit::m_textAutoSizingAdjustmentTimer):
(WebKit::WebPage::close):
(WebKit::WebPage::didCommitLoad):
(WebKit::WebPage::textAutoSizingAdjustmentTimerFired):
(WebKit::m_shrinkToFitContentTimer): Deleted.
- WebProcess/WebPage/WebPage.h:
- WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::dynamicViewportSizeUpdate):
(WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):
(WebKit::WebPage::resetTextAutosizing):
(WebKit::WebPage::viewportConfigurationChanged):
- 5:40 AM Changeset in webkit [247666] by
-
- 10 edits4 adds in trunk
[WHLSL] Make enums work
https://bugs.webkit.org/show_bug.cgi?id=199634
Reviewed by Robin Morisset.
Source/WebCore:
This patch makes enums work. There were a couple changes needed to do this work:
- In the metal codegen, we were emitting code like "EnumType.EnumValue"
instead of "EnumType::EnumValue".
- Inside the enumeration declaration AST node, we track enums in a HashMap
because we need to look up names of enum values in that map in parts of the
compiler. However, HashMap is not ordered but we were relying on the iteration
order of it to generate the default values of enums. E.g, in: "enum { Foo = 10, Bar }",
Bar should be 11. However, there was no guarantee that we iterated over Bar
after Foo. Instead, we just track the default values as we parse an enum
inside of the parser. This allows us to continue to keep using HashMap without
also adding an auxiliary data structure (or using more memory in some way) to
track the order of the enum elements.
I've also filed a patch to do follow-up work on implementing the correct
operational behavior when constructing an enum from its underlying type when
the underlying value does not match any enum value:
https://bugs.webkit.org/show_bug.cgi?id=199853
Tests: webgpu/whlsl/enums-2.html
webgpu/whlsl/enums.html
- Modules/webgpu/WHLSL/AST/WHLSLEnumerationMember.h:
(WebCore::WHLSL::AST::EnumerationMember::EnumerationMember):
(WebCore::WHLSL::AST::EnumerationMember::value):
(WebCore::WHLSL::AST::EnumerationMember::setValue): Deleted.
- Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::constantExpressionString):
- Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp:
(WebCore::WHLSL::Metal::TypeNamer::emitNamedTypeDefinition):
- Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:
(WebCore::WHLSL::ASTDumper::visit):
- Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::Checker::visit):
- Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseEnumerationDefinition):
(WebCore::WHLSL::Parser::parseEnumerationMember):
- Modules/webgpu/WHLSL/WHLSLParser.h:
- Modules/webgpu/WHLSL/WHLSLVisitor.cpp:
(WebCore::WHLSL::Visitor::visit):
LayoutTests:
- webgpu/whlsl/enums-2-expected.txt: Added.
- webgpu/whlsl/enums-2.html: Added.
- webgpu/whlsl/enums-expected.txt: Added.
- webgpu/whlsl/enums.html: Added.
Jul 19, 2019:
- 7:01 PM Changeset in webkit [247665] by
-
- 1 edit5 adds in trunk/Tools
Move webkit.css to opensource to support resultsdbpy's frontend
https://bugs.webkit.org/show_bug.cgi?id=199957
Patch by Zhifei Fang <zhifei_fang@apple.com> on 2019-07-19
Reviewed by Jonathan Bedard.
- resultsdbpy/resultsdbpy/view/static/library/css/docs.yaml: Added.
- resultsdbpy/resultsdbpy/view/static/library/css/generate-webkit-css-docs: Added.
- resultsdbpy/resultsdbpy/view/static/library/css/index.html: Added.
- resultsdbpy/resultsdbpy/view/static/library/css/webkit.css: Added.
- 6:15 PM Changeset in webkit [247664] by
-
- 10 edits7 adds in trunk/Tools
Move Ref.js to WebKit to support resultsdbpy's frontend
https://bugs.webkit.org/show_bug.cgi?id=199956
Patch by Zhifei Fang <zhifei_fang@apple.com> on 2019-07-19
Reviewed by Jonathan Bedard.
- resultsdbpy/resultsdbpy/view/static/js/drawer.js:
- resultsdbpy/resultsdbpy/view/static/js/search.js:
- resultsdbpy/resultsdbpy/view/static/js/timeline.js:
- resultsdbpy/resultsdbpy/view/static/library/js/Ref.js: Added.
- resultsdbpy/resultsdbpy/view/static/library/js/Utils.js: Added.
- resultsdbpy/resultsdbpy/view/static/library/js/components/BaseComponents.js: Added.
- resultsdbpy/resultsdbpy/view/static/library/js/components/TimelineComponents.js: Added.
- resultsdbpy/resultsdbpy/view/templates/base.html:
- resultsdbpy/resultsdbpy/view/templates/commits.html:
- resultsdbpy/resultsdbpy/view/templates/documentation.html:
- resultsdbpy/resultsdbpy/view/templates/search.html:
- resultsdbpy/resultsdbpy/view/templates/suite_results.html:
- resultsdbpy/resultsdbpy/view/view_routes.py:
- 5:55 PM Changeset in webkit [247663] by
-
- 5 edits in trunk/Tools
[webkitpy] Allow the testrunner driver to setup the environment completely without needing to start the server process.
https://bugs.webkit.org/show_bug.cgi?id=199945
Reviewed by Michael Catanzaro.
Refactor the code to create the Driver temporal directories inside Driver._setup_environ_for_driver().
This allows external callers to setup the environment for running tests by calling that method without needing to start the server process.
When this callers finish testing, it is enough with calling either Driver.stop() or Driver._delete_temporal_directories().
- Scripts/webkitpy/port/driver.py:
(Driver._setup_environ_for_driver):
(Driver._create_temporal_directories):
(Driver):
(Driver._start):
(Driver._delete_temporal_directories):
(Driver.stop):
- Scripts/webkitpy/w3c/wpt_runner.py: Not needed anymore to start the driver since this doesnt need the server process running.
(main):
- Scripts/webkitpy/webdriver_tests/webdriver_test_runner.py: Ditto.
(WebDriverTestRunner.init):
- glib/api_test_runner.py:
(TestRunner._setup_testing_environment): Ditto.
- 5:55 PM Changeset in webkit [247662] by
-
- 16 edits in trunk/Source
Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess
https://bugs.webkit.org/show_bug.cgi?id=199924
<rdar://problem/50552067>
Reviewed by Devin Rousso.
Source/WebCore:
Add necessary API to set mock capture devices override.
In case of desynchronization between webprocess and uiprocess, make sure to return early
and fail capture instead of crashing.
- inspector/InspectorClient.h:
(WebCore::InspectorClient::setMockCaptureDevicesEnabled):
- inspector/agents/InspectorPageAgent.cpp:
(WebCore::InspectorPageAgent::disable):
(WebCore::InspectorPageAgent::overrideSetting):
- platform/mock/MockRealtimeMediaSourceCenter.cpp:
Source/WebKit:
Add IPC plumbery to pass inspector override value for mock capture devices.
Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector.
The override will be removed when web inspector goes away.
- UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
(WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const):
- UIProcess/UserMediaPermissionRequestManagerProxy.h:
(WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride):
- UIProcess/WebInspectorProxy.cpp:
(WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled):
- UIProcess/WebInspectorProxy.h:
- UIProcess/WebInspectorProxy.messages.in:
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride):
- UIProcess/WebPageProxy.h:
- WebProcess/WebCoreSupport/WebInspectorClient.cpp:
(WebKit::WebInspectorClient::setMockCaptureDevicesEnabled):
- WebProcess/WebCoreSupport/WebInspectorClient.h:
- WebProcess/WebPage/WebInspector.cpp:
(WebKit::WebInspector::setMockCaptureDevicesEnabled):
- WebProcess/WebPage/WebInspector.h:
- 5:40 PM Changeset in webkit [247661] by
-
- 3 edits in trunk/LayoutTests
fast/scrolling/ipad/* tests running on Mac
https://bugs.webkit.org/show_bug.cgi?id=199969
<rdar://problem/52531653>
Unreviewed test gardening.
- TestExpectations: Skip fast/scrolling/ipad on all platforms.
- platform/ios/TestExpectations: Move to generic TestExpectations.
- 4:56 PM Changeset in webkit [247660] by
-
- 3 edits in branches/safari-608-branch/LayoutTests
Cherry-pick r247648. rdar://problem/53279094
Rebase fast/forms/ios/typing-in-input-in-iframe.html after r244141
https://bugs.webkit.org/show_bug.cgi?id=199875
<rdar://problem/50060561>
Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-19
Reviewed by Megan Gardner.
With r247571 and its justification, we need to rebase another test.
- fast/forms/ios/typing-in-input-in-iframe-expected.txt:
- fast/forms/ios/typing-in-input-in-iframe.html:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247648 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 4:55 PM Changeset in webkit [247659] by
-
- 3 edits in branches/safari-608-branch/LayoutTests
Cherry-pick r247571. rdar://problem/53279094
Rebase fast/forms/ios/delete-in-input-in-iframe.html after r244141
https://bugs.webkit.org/show_bug.cgi?id=199875
<rdar://problem/50060561>
Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-18
Reviewed by Megan Gardner.
In r202295, we added an ios-specific quirk to prevent scrolling on iOS because of UIKit/WebKit scrolling discrepancies.
In r244141, we changed the scrolling behavior to be more like macOS, and the test was broken. Since this was an intentional
change and the bugs reported in rdar://problem/26805722 (initially fixed by r202295) and rdar://problem/49225507 (fixed by r244141)
are both behaving as desired, the intentional change in r244141 should be reflected by new test expectations.
We do want typing in an input field in an iframe to scroll as we type.
- fast/forms/ios/delete-in-input-in-iframe-expected.txt:
- fast/forms/ios/delete-in-input-in-iframe.html:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247571 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 4:10 PM Changeset in webkit [247658] by
-
- 4 edits in trunk/Source/WebKit
Web Content process gets stuck suspended after navigating away from a system preview
https://bugs.webkit.org/show_bug.cgi?id=199965
<rdar://problem/53109004>
Reviewed by Dean Jackson.
- UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _isBackground]):
- UIProcess/ios/WKSystemPreviewView.h:
- UIProcess/ios/WKSystemPreviewView.mm:
(-[WKSystemPreviewView web_initWithFrame:webView:mimeType:]):
(-[WKSystemPreviewView web_isBackground]):
Apply the fix from r193481 to WKSystemPreviewView as well, having it
become a WKApplicationStateTrackingView and plumbing that through
to our is-background machinery.
We really, really should instead have WKWebView itself be the application
state tracking view, but that is a bigger change (and has some implications
for full-screen video and whatnot).
- 3:50 PM Changeset in webkit [247657] by
-
- 3 edits in trunk/Source/WebKit
Provide correct names for UIContextMenuInteraction API replacements
https://bugs.webkit.org/show_bug.cgi?id=199966
Reviewed by Tim Horton.
We had some old incorrect names for replacements to SPI. While
here, I reordered and expanded the documentation for the new API.
- UIProcess/API/Cocoa/WKUIDelegate.h:
- UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
- 3:49 PM Changeset in webkit [247656] by
-
- 4 edits in trunk/Source/WebKit
[iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding
https://bugs.webkit.org/show_bug.cgi?id=199963
rdar://problem/52897797
Reviewed by Tim Horton.
Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding.
- Platform/spi/ios/UIKitSPI.h:
- UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _initializeWithConfiguration:]):
- UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
(WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren):
- 3:30 PM Changeset in webkit [247655] by
-
- 2 edits in trunk/Source/WebCore
[Apple Pay] Log less in PaymentCoordinator::shouldEnableApplePayAPIs()
https://bugs.webkit.org/show_bug.cgi?id=199958
Reviewed by Tim Horton.
Only log when APIs are disabled due to user scripts.
- Modules/applepay/PaymentCoordinator.cpp:
(WebCore::PaymentCoordinator::shouldEnableApplePayAPIs const):
- 3:11 PM Changeset in webkit [247654] by
-
- 1 copy in tags/Safari-608.1.37
Tag Safari-608.1.37.
- 2:58 PM Changeset in webkit [247653] by
-
- 2 edits in trunk/Source/WebKit
[iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
https://bugs.webkit.org/show_bug.cgi?id=199807
<rdar://problem/52760259>
Reviewed by Wenson Hsieh.
Sometimes the correction highlight may not hide when defocusing an editable field.
This occurs only when a person pressed a key in a non-editable element beforehand.
We need to reset some state to force a re-computation of whether a keyboard is still
needed whenever an element is defocused (blurred in web paralance).
Following r241734 both editable and non-editable key events are handled using the same
code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder
return YES to tell UIKit it needs a keyboard even when there is no editable element focused.
As a result UIKit retains all the keyboard state, including keeping the correction highlight
visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return
YES when a non-editable element was focused and hence UIKit would tear down the keyboard
and its state, including the correction highlight. In r245154, we made keyboard instantiate
for a focused non-editable element lazy as a performance optimization. Although r245154
kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we
can utilize it as a hook to fix this bug. In particular, we now clear the bit about a
seen keydown in a non-editable element whenever we are defocusing an editable element
before we reload the input views, as part of hiding the keyboard. On the reload, UIKit
will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that
a non-editable element is focused and hence UIKit will do what it did pre r241734: tear
down the keyboard.
- UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here
so that we don't keep the keyboard around on a new page commit. This includes the case
when the same page is reloaded. There is not much advantage to keeping the keyboard
around across reloads and not doing so will reduce our memory footprint.
(-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an
editable element. This will cause UIKit to tear down the keyboard on reload removing
the correction highlight.
- 2:17 PM Changeset in webkit [247652] by
-
- 8 edits in trunk/Source
Add a menu item to toggle between showing and hiding link previews
https://bugs.webkit.org/show_bug.cgi?id=199940
<rdar://problem/53032288>
Reviewed by Beth Dakin.
Source/WebCore:
New strings for Show/Hide Link Previews.
- en.lproj/Localizable.strings:
Source/WebKit:
Add a new _WKElementAction that toggles the display of link previews
in context menus, and add it to the default set of actions we provide
for links.
When a UIAction is created from this new _WKElementAction type,
it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier.
This allows us to check a UIMenu provided by a delegate to make sure
that they have provided the toggle menu item. If they haven't, we add it
back.
The preference for showing links is moved from kCFPreferencesAnyApplication
to standard user defaults, so that it can be set no matter what the
hosting application is.
- UIProcess/API/Cocoa/_WKElementAction.h: New action type.
- UIProcess/API/Cocoa/_WKElementAction.mm:
(+[_WKElementAction _elementActionWithType:customTitle:assistant:]):
(+[_WKElementAction imageForElementActionType:]): Use eye.fill for now.
I'll need to check with HI to see if there is a more appropriate glyph.
(elementActionTypeToUIActionIdentifier):
(uiActionIdentifierToElementActionType):
- UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to
the default set.
(-[WKActionSheetAssistant defaultActionsForLinkSheet:]):
- UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _registerPreview]): No need to listen for CFPreferences
notifications any more.
(-[WKContentView _unregisterPreview]):
(menuWithShowLinkPreviewAction): New method that adds the UIAction
for toggling previews to a UIMenu if necessary.
(-[WKContentView assignLegacyDataForContextMenuInteraction]):
(-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]):
(-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted.
(titleForMenu): Deleted. URL text previews will be provided separately.
- 12:55 PM Changeset in webkit [247651] by
-
- 5 edits2 adds in trunk
[iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling
https://bugs.webkit.org/show_bug.cgi?id=199949
<rdar://problem/49944428>
Reviewed by Tim Horton and Megan Gardner.
Source/WebKit:
Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the
scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method
whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification).
When switching between focused form fields, we hide the keyboard for the previous focused element prior to
showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the
process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll
WKScrollView.
On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which
causes us to adjust the scroll view back to its original position right away; this means that the scrolling that
happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change.
However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element
until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a
consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump
is also less noticeable).
To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to
show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending
"keyboard will hide" notification.
Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html
- UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]):
(-[WKWebView _keyboardWillHide:]):
- UIProcess/ios/WKContentViewInteraction.h:
- UIProcess/ios/WKContentViewInteraction.mm:
(shouldShowKeyboardForElement):
Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input
view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we
don't show an input view).
(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
(-[WKContentView shouldIgnoreKeyboardWillHideNotification]):
LayoutTests:
Add a new layout test to verify that moving focus between horizontally adjacent form controls doesn't induce
vertical scrolling.
- fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields-expected.txt: Added.
- fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html: Added.
- 12:47 PM Changeset in webkit [247650] by
-
- 3 edits2 adds in trunk
Links stop working after long-pressing a link (WK1)
https://bugs.webkit.org/show_bug.cgi?id=199952
<rdar://problem/52291860>
Patch by Antoine Quint <Antoine Quint> on 2019-07-19
Reviewed by Wenson Hsieh.
Source/WebCore:
Test: fast/events/touch/ios/click-after-long-press.html
When EventHandler::tryToBeginDragAtPoint() is called, we must reset m_mousePressed to false so that
WebChromeClientIOS::observedContentChange() is called by EventHandler::mousePressed() when we would
process the next tap after a drag interaction.
- page/ios/EventHandlerIOS.mm:
(WebCore::EventHandler::tryToBeginDragAtPoint):
LayoutTests:
- fast/events/touch/ios/click-after-long-press-expected.txt: Added.
- fast/events/touch/ios/click-after-long-press.html: Added.
- 11:06 AM Changeset in webkit [247649] by
-
- 3 edits in trunk/Source/WebCore
IndexedDB: error in starting version change transaction may be neglected
https://bugs.webkit.org/show_bug.cgi?id=199818
<rdar://problem/52925738>
Reviewed by Brady Eidson.
For version change transaction, IDBServer didn't wait the result of beginTransaction on the background thread
before giving the IDBClient the result of open request. In this case, beginTransaction may fail to update the
DatabaseVersion in database file or set m_originalDatabaseInfoBeforeVersionChange, but the transaction was
marked as started. When we later set m_databaseInfo with m_originalDatabaseInfoBeforeVersionChange,
m_databaseInfo could become nullptr.
To write a test for this, we will need to simulate an SQLite error. I manually tested this by crafting the
SQLiteStatement in beginTransaction, making it an invalid statement, and verified that error event, instead of
ungradeneeded event is dispatched to the IDBRequest.
- Modules/indexeddb/server/UniqueIDBDatabase.cpp:
(WebCore::IDBServer::UniqueIDBDatabase::startVersionChangeTransaction):
(WebCore::IDBServer::UniqueIDBDatabase::performStartVersionChangeTransaction):
(WebCore::IDBServer::UniqueIDBDatabase::didPerformStartVersionChangeTransaction):
(WebCore::IDBServer::UniqueIDBDatabase::immediateCloseForUserDelete):
(WebCore::IDBServer::UniqueIDBDatabase::beginTransactionInBackingStore): Deleted.
- Modules/indexeddb/server/UniqueIDBDatabase.h:
- 9:56 AM Changeset in webkit [247648] by
-
- 3 edits in trunk/LayoutTests
Rebase fast/forms/ios/typing-in-input-in-iframe.html after r244141
https://bugs.webkit.org/show_bug.cgi?id=199875
<rdar://problem/50060561>
Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-19
Reviewed by Megan Gardner.
With r247571 and its justification, we need to rebase another test.
- fast/forms/ios/typing-in-input-in-iframe-expected.txt:
- fast/forms/ios/typing-in-input-in-iframe.html:
- 8:58 AM Changeset in webkit [247647] by
-
- 2 edits in trunk/Websites/bugs.webkit.org
[ews-app] EWS status-bubbles are sometimes multi-row with scroll-bar
https://bugs.webkit.org/show_bug.cgi?id=199939
Reviewed by Jonathan Bedard.
- code-review.js: Disable scrolling.
- 8:54 AM Changeset in webkit [247646] by
-
- 2 edits in trunk/Tools
[ews-build] Display pre-existing Layout test failure names in the build summary
https://bugs.webkit.org/show_bug.cgi?id=199941
Reviewed by Jonathan Bedard.
- BuildSlaveSupport/ews-build/steps.py:
(AnalyzeLayoutTestsResults.report_pre_existing_failures):
- 8:51 AM Changeset in webkit [247645] by
-
- 2 edits in trunk/LayoutTests
Unable to bring up custom media controls on iOS for video.sina.cn
https://bugs.webkit.org/show_bug.cgi?id=199889
<rdar://problem/51883919>
Unreviewed test gardening.
This new test can only run on Internal bots.
Patch by Antoine Quint <Antoine Quint> on 2019-07-19
- platform/ios/TestExpectations:
- 6:35 AM Changeset in webkit [247644] by
-
- 4 edits in trunk/Source/WebCore
[LFC][IFC] Add partial content handling
https://bugs.webkit.org/show_bug.cgi?id=199930
Reviewed by Antti Koivisto.
Move the actual inline item placement to a dedicated functions. This enables us to
construct a dedicated InlineItem for the partial content and pass it in to this function.
<span>The quick brown fox jumps over the lazy dog</span> <- inline content
[The][ ][quick][ ][brown][ ][fox][ ][jumps][ ][over][ ][the][ ][lazy][ ][dog] <- InlineItems
Line breaking:
[The][ ][qu]
[ick] <- Partial InlineItem (position: 6 length: 3) from [quick] (position: 4 length: 5)
- layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
(WebCore::Layout::LineLayout::close):
(WebCore::Layout::LineLayout::placeInlineItem):
(WebCore::Layout::LineLayout::layout):
(WebCore::Layout::LineInput::LineInput):
(WebCore::Layout::InlineFormattingContext::InlineLayout::layout const):
(WebCore::Layout::InlineFormattingContext::InlineLayout::computedIntrinsicWidth const):
- layout/inlineformatting/InlineTextItem.cpp:
(WebCore::Layout::InlineTextItem::split):
- layout/inlineformatting/InlineTextItem.h:
- 4:43 AM Changeset in webkit [247643] by
-
- 2 edits in trunk/Source/WebCore
[GStreamer] Flush get_range calls during PAUSED->READY in WebKitWebSource
https://bugs.webkit.org/show_bug.cgi?id=199934
Reviewed by Xabier Rodriguez-Calvar.
Unit testing not applicable.
- platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(webKitWebSrcChangeState): A well-behaved element should unblock streaming threads
during a PAUSED->READY transition, so do that here.
- 2:56 AM Changeset in webkit [247642] by
-
- 3 edits in trunk/Tools
[GTK][WPE] run-webkit-tests should run with a temporal homedir
https://bugs.webkit.org/show_bug.cgi?id=199738
Reviewed by Michael Catanzaro.
Run the tests with an empty homedir that is created inside the driver tmpdir.
The driver tmpdir is a random directory created for each test runner that is purged after the run.
This is done to ensure that the test results are not affected by the user settings of any library.
- Scripts/webkitpy/port/driver.py:
(Driver._setup_environ_for_driver):
- Scripts/webkitpy/port/driver_unittest.py:
(DriverTest.test_setup_environ_base_vars):
(DriverTest):
(DriverTest.test_create_temporal_home_dir):
- 2:11 AM Changeset in webkit [247641] by
-
- 2 edits in trunk/Source/WebCore
Remove some unneeded code in MathOperator
https://bugs.webkit.org/show_bug.cgi?id=199935
Patch by Rob Buis <rbuis@igalia.com> on 2019-07-19
Reviewed by Frédéric Wang.
The initialize method is unneeded since the member
variables all use default initialization.
No new tests, not changing behavior.
- rendering/mathml/MathOperator.cpp:
(WebCore::MathOperator::MathOperator):
(WebCore::MathOperator::GlyphAssemblyData::initialize): Deleted.
- 1:34 AM Changeset in webkit [247640] by
-
- 7 edits1 delete in trunk
Remove pywebsockets from thirdparty
https://bugs.webkit.org/show_bug.cgi?id=199710
Patch by Carlos Garcia Campos <cgarcia@igalia.com> on 2019-07-19
Reviewed by Jonathan Bedard.
Tools:
We have a very old version of pywebsocket in webkitpy thirdparty, but we are also importing pywebsocket as part
of wpt tools. We can simply use the wpt one for all websocket tests and remove the old copy from sources.
- Scripts/webkitpy/layout_tests/servers/websocket_server.py:
(PyWebSocket._prepare_config): Use pywebsocket from imported w3c tools directory.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/COPYING: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/init.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/_stream_base.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/_stream_hixie75.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/_stream_hybi.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/common.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/dispatch.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/extensions.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/handshake/init.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/handshake/_base.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/handshake/hybi.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/handshake/hybi00.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/headerparserhandler.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/http_header_util.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/memorizingfile.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/msgutil.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/mux.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/standalone.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/stream.py: Removed.
- Scripts/webkitpy/thirdparty/mod_pywebsocket/util.py: Removed.
LayoutTests:
Update two tests that timeout with the new pywebsocket version, because the server doesn't close the connection
after handshake.AbortedByUserException(). Simply assume onopen to be called a success in handshake like other
tests using handshake.AbortedByUserException() do.
- http/tests/websocket/tests/hybi/handshake-ok-with-legacy-sec-websocket-response-headers-expected.txt:
- http/tests/websocket/tests/hybi/handshake-ok-with-legacy-sec-websocket-response-headers.html:
- http/tests/websocket/tests/hybi/handshake-ok-with-legacy-websocket-response-headers-expected.txt:
- http/tests/websocket/tests/hybi/handshake-ok-with-legacy-websocket-response-headers.html:
- 12:39 AM Changeset in webkit [247639] by
-
- 2 edits in trunk/Source/WebInspectorUI
Web Inspector: Issues toggling multiple breakpoints on one line
https://bugs.webkit.org/show_bug.cgi?id=199918
Reviewed by Joseph Pecoraro.
- UserInterface/Views/SourceCodeTextEditor.js:
(WI.SourceCodeTextEditor):
(WI.SourceCodeTextEditor.prototype.close):
(WI.SourceCodeTextEditor.prototype.textEditorGutterContextMenu):
(WI.SourceCodeTextEditor.prototype.textEditorUpdatedFormatting):
(WI.SourceCodeTextEditor.prototype._handleFormatterDidChange): Added.
Listen forWI.SourceCode.Event.FormatterDidChangeevents as there may be multiple content
views for the sameWI.SourceCode. Previously, if there were, only the active one would
properly update it's "line -> column -> breakpoint" mapping, causing an error to be thrown
when the non-active content views tried to retrieve the breakpoint for the new line/column.