Changeset 236619 in webkit


Ignore:
Timestamp:
Sep 28, 2018 4:02:41 PM (6 years ago)
Author:
dbates@webkit.org
Message:

[iOS] Allow programmatic focus when hardware keyboard is attached
https://bugs.webkit.org/show_bug.cgi?id=190017
<rdar://problem/42270463>

Reviewed by Wenson Hsieh.

Source/WebCore:

Add support for checking if the embedding client is WebKitTestRunner and export isDumpRenderTree()
so that we can make use of it from WebKit. We will make use of these functions to keep the current
behavior of disallowing programmatic focus when running tests in these apps. This is needed to
keep testing deterministic. Otherwise, test results would be dependent on whether a hardware
keyboard is attached. When running tests in Simulator.app the hardware keyboard may also not be
connected (i.e. Hardware > Keyboard > Connect Hardware Keyboard is disabled).

  • platform/RuntimeApplicationChecks.h:
  • platform/cocoa/RuntimeApplicationChecksCocoa.mm:

(WebCore::IOSApplication::isWebKitTestRunner): Added.

Source/WebKit:

Make the experience of using iOS with a hardware keyboard more desktop-like by allowing
programmatic focusing of editable elements.

  • Platform/spi/ios/UIKitSPI.h: Forward declare SPI.
  • Shared/NativeWebKeyboardEvent.h:
  • Shared/ios/NativeWebKeyboardEventIOS.mm:

(WebKit::isInHardwareKeyboardMode): Returns whether we are in hardware keyboard mode. In DumpRenderTree
and WebKitTestRunner this function always returns false to keep test results deterministic.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView _startAssistingNode:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
Allow starting an input session if we are in hardware keyboard mode.

  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::platformEditorState const): Send the full editor state if we are in hardware
keyboard mode regardless of whether layout has been performed so that UIProcess can update UI,
including the position of the caret, immediately.

Location:
trunk/Source
Files:
9 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r236618 r236619  
     12018-09-28  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Allow programmatic focus when hardware keyboard is attached
     4        https://bugs.webkit.org/show_bug.cgi?id=190017
     5        <rdar://problem/42270463>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Add support for checking if the embedding client is WebKitTestRunner and export isDumpRenderTree()
     10        so that we can make use of it from WebKit. We will make use of these functions to keep the current
     11        behavior of disallowing programmatic focus when running tests in these apps. This is needed to
     12        keep testing deterministic. Otherwise, test results would be dependent on whether a hardware
     13        keyboard is attached. When running tests in Simulator.app the hardware keyboard may also not be
     14        connected (i.e. Hardware > Keyboard > Connect Hardware Keyboard is disabled).
     15
     16        * platform/RuntimeApplicationChecks.h:
     17        * platform/cocoa/RuntimeApplicationChecksCocoa.mm:
     18        (WebCore::IOSApplication::isWebKitTestRunner): Added.
     19
    1202018-09-28  Ryosuke Niwa  <rniwa@webkit.org>
    221
  • trunk/Source/WebCore/platform/RuntimeApplicationChecks.h

    r234447 r236619  
    8080WEBCORE_EXPORT bool isMobileSafari();
    8181WEBCORE_EXPORT bool isWebBookmarksD();
    82 bool isDumpRenderTree();
     82WEBCORE_EXPORT bool isWebKitTestRunner();
     83WEBCORE_EXPORT bool isDumpRenderTree();
    8384bool isMobileStore();
    8485bool isSpringBoard();
  • trunk/Source/WebCore/platform/cocoa/RuntimeApplicationChecksCocoa.mm

    r236474 r236619  
    218218}
    219219
     220bool IOSApplication::isWebKitTestRunner()
     221{
     222    // We use a prefix match instead of strict equality since multiple instances of WebKitTestRunner
     223    // may be launched, where the bundle identifier of each instance has a unique suffix.
     224    static bool isWebKitTestRunner = applicationBundleIsEqualTo("org.webkit.WebKitTestRunnerApp"_s); // e.g. org.webkit.WebKitTestRunnerApp0
     225    return isWebKitTestRunner;
     226}
     227
    220228bool IOSApplication::isMobileStore()
    221229{
  • trunk/Source/WebKit/ChangeLog

    r236612 r236619  
     12018-09-28  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Allow programmatic focus when hardware keyboard is attached
     4        https://bugs.webkit.org/show_bug.cgi?id=190017
     5        <rdar://problem/42270463>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Make the experience of using iOS with a hardware keyboard more desktop-like by allowing
     10        programmatic focusing of editable elements.
     11
     12        * Platform/spi/ios/UIKitSPI.h: Forward declare SPI.
     13        * Shared/NativeWebKeyboardEvent.h:
     14        * Shared/ios/NativeWebKeyboardEventIOS.mm:
     15        (WebKit::isInHardwareKeyboardMode): Returns whether we are in hardware keyboard mode. In DumpRenderTree
     16        and WebKitTestRunner this function always returns false to keep test results deterministic.
     17        * UIProcess/ios/WKContentViewInteraction.mm:
     18        (-[WKContentView _startAssistingNode:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
     19        Allow starting an input session if we are in hardware keyboard mode.
     20        * WebProcess/WebPage/ios/WebPageIOS.mm:
     21        (WebKit::WebPage::platformEditorState const): Send the full editor state if we are in hardware
     22        keyboard mode regardless of whether layout has been performed so that UIProcess can update UI,
     23        including the position of the caret, immediately.
     24
    1252018-09-28  Ryosuke Niwa  <rniwa@webkit.org>
    226
  • trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h

    r236417 r236619  
    248248- (void)geometryChangeDone:(BOOL)keyboardVisible;
    249249- (void)prepareForGeometryChange;
     250+ (BOOL)isInHardwareKeyboardMode;
    250251@end
    251252
  • trunk/Source/WebKit/Shared/NativeWebKeyboardEvent.h

    r230461 r236619  
    106106};
    107107
     108// FIXME: Find a better place for this.
     109#if PLATFORM(IOS)
     110bool isInHardwareKeyboardMode();
     111#endif
     112
    108113} // namespace WebKit
    109114
  • trunk/Source/WebKit/Shared/ios/NativeWebKeyboardEventIOS.mm

    r212376 r236619  
    2929#if PLATFORM(IOS)
    3030
     31#import "UIKitSPI.h"
    3132#import "WebIOSEventFactory.h"
     33#import <WebCore/RuntimeApplicationChecks.h>
    3234
    3335namespace WebKit {
     36
     37bool isInHardwareKeyboardMode()
     38{
     39    return !WebCore::IOSApplication::isDumpRenderTree() && !WebCore::IOSApplication::isWebKitTestRunner() && [UIKeyboard isInHardwareKeyboardMode];
     40}
    3441
    3542NativeWebKeyboardEvent::NativeWebKeyboardEvent(::WebEvent *event)
  • trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

    r236491 r236619  
    41924192#else
    41934193            || _isChangingFocus
     4194            || isInHardwareKeyboardMode()
    41944195#endif
    41954196#if ENABLE(DRAG_SUPPORT)
  • trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

    r236530 r236619  
    3838#import "InteractionInformationAtPosition.h"
    3939#import "Logging.h"
     40#import "NativeWebKeyboardEvent.h"
    4041#import "PluginView.h"
    4142#import "PrintInfo.h"
     
    192193    }
    193194
    194     // We only set the remaining EditorState entries if the layout is done. To compute these
    195     // entries, we need the layout to be done and we don't want to trigger a synchronous
    196     // layout as this would be bad for performance. If we have a composition, we send everything
    197     // right away as the UIProcess needs the caretRects ASAP for marked text.
    198     bool frameViewHasFinishedLayout = frame.view() && !frame.view()->needsLayout();
    199     if (shouldIncludePostLayoutData == IncludePostLayoutDataHint::No && !frameViewHasFinishedLayout && !frame.editor().hasComposition()) {
     195    // We only set the remaining EditorState entries if layout is done as a performance optimization
     196    // to avoid the need to force a synchronous layout here to compute these entries. If we
     197    // have a composition or are using a hardware keyboard then we send the full editor state
     198    // immediately so that the UIProcess can update UI, including the position of the caret.
     199    bool needsLayout = !frame.view() || frame.view()->needsLayout();
     200    if (shouldIncludePostLayoutData == IncludePostLayoutDataHint::No && needsLayout && !isInHardwareKeyboardMode() && !frame.editor().hasComposition()) {
    200201        result.isMissingPostLayoutData = true;
    201202        return;
Note: See TracChangeset for help on using the changeset viewer.