Changeset 245144 in webkit


Ignore:
Timestamp:
May 9, 2019 10:41:20 AM (5 years ago)
Author:
dbates@webkit.org
Message:

[iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
​https://bugs.webkit.org/show_bug.cgi?id=197632
<rdar://problem/47902054>

Reviewed by Brent Fulgham.

Source/WebKit:

Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
opens a new window.

By default we only allow popups to open if they were user initiated (like when a person clicks
on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
WebCore processes an event from WebKit. So long as this token is on the stack we consider
all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
to determine if it's being called by the keyboard. If it is then we can assume that this is
part of key event handling and hence was initiated by the user. We can pass along this detail
to the WebProcess for it to push a new UserGestureToken onto the stack.

For now we only track whether text inserted by the keyboard was user initiated or not. In
<​https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.

  • Platform/spi/ios/UIKitSPI.h: Expose SPI.
  • Shared/Cocoa/InsertTextOptions.cpp:

(IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
(IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
Encode and decode whether we are processing a user gesture.

  • Shared/Cocoa/InsertTextOptions.h:
  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
the embedding client did. We only want to privilege user initiated actions (the keyboard).

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
depending on whether we are or are not processing a user gesture.

LayoutTests:

Add tests to ensure we fire input and keypress events in the correct order and that we can
submit a <form> with target = "_blank" using the Return key.

  • fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
  • fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
  • fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
  • fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
  • platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added

in <rdar://problem/50596032>.

Location:
trunk
Files:
4 added
8 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r245135 r245144  
     12019-05-09  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     4        https://bugs.webkit.org/show_bug.cgi?id=197632
     5        <rdar://problem/47902054>
     6
     7        Reviewed by Brent Fulgham.
     8
     9        Add tests to ensure we fire input and keypress events in the correct order and that we can
     10        submit a <form> with target = "_blank" using the Return key.
     11
     12        * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
     13        * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
     14        * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
     15        * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
     16        * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
     17        in <rdar://problem/50596032>.
     18
    1192019-05-09  Per Arne Vollan  <pvollan@apple.com>
    220

  • trunk/LayoutTests/platform/ios/TestExpectations

    r245013 r245144  
    32623262
    32633263webkit.org/b/175678 media/W3C/video/events/event_progress.html [ Pass Failure ]
     3264
     3265# FIXME: Unskip the following test once we have the fix for <rdar://problem/50596032>.
     3266fast/events/ios/submit-form-target-blank-using-return-key.html

  • trunk/Source/WebKit/ChangeLog

    r245134 r245144  
     12019-05-09  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     4        https://bugs.webkit.org/show_bug.cgi?id=197632
     5        <rdar://problem/47902054>
     6
     7        Reviewed by Brent Fulgham.
     8
     9        Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
     10        opens a new window.
     11
     12        By default we only allow popups to open if they were user initiated (like when a person clicks
     13        on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
     14        WebCore processes an event from WebKit. So long as this token is on the stack we consider
     15        all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
     16        the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
     17        part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
     18        However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
     19        with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
     20        to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
     21        and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
     22        to determine if it's being called by the keyboard. If it is then we can assume that this is
     23        part of key event handling and hence was initiated by the user. We can pass along this detail
     24        to the WebProcess for it to push a new UserGestureToken onto the stack.
     25
     26        For now we only track whether text inserted by the keyboard was user initiated or not. In
     27        <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
     28
     29        * Platform/spi/ios/UIKitSPI.h: Expose SPI.
     30        * Shared/Cocoa/InsertTextOptions.cpp:
     31        (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
     32        (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
     33        Encode and decode whether we are processing a user gesture.
     34
     35        * Shared/Cocoa/InsertTextOptions.h:
     36        * UIProcess/ios/WKContentViewInteraction.mm:
     37        (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
     38        the embedding client did. We only want to privilege user initiated actions (the keyboard).
     39        * WebProcess/WebPage/WebPage.cpp:
     40        (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
     41        depending on whether we are or are not processing a user gesture.
     42
    1432019-05-09  Antoine Quint  <graouts@apple.com>
    244

  • trunk/Source/WebKit/Platform/spi/ios/UIKitSPI.h

    r244975 r245144  
    11271127- (BOOL)handleKeyAppCommandForCurrentEvent;
    11281128- (BOOL)handleKeyInputMethodCommandForCurrentEvent;
     1129- (BOOL)isCallingInputDelegate;
    11291130@property (nonatomic, readonly) UIKeyboardInputMode *currentInputModeInPreference;
    11301131@end

  • trunk/Source/WebKit/Shared/Cocoa/InsertTextOptions.cpp

    r245073 r245144  
    3333    encoder << options.registerUndoGroup;
    3434    encoder << options.suppressSelectionUpdate;
     35    encoder << options.processingUserGesture;
    3536    encoder << options.editingRangeIsRelativeTo;
    3637}
    … …  
    4344    if (!decoder.decode(options.suppressSelectionUpdate))
    4445        return WTF::nullopt;
     46    if (!decoder.decode(options.processingUserGesture))
     47        return WTF::nullopt;
    4548    if (!decoder.decode(options.editingRangeIsRelativeTo))
    4649        return WTF::nullopt;

  • trunk/Source/WebKit/Shared/Cocoa/InsertTextOptions.h

    r245073 r245144  
    3434    bool registerUndoGroup { false };
    3535    bool suppressSelectionUpdate { false };
     36    bool processingUserGesture { false };
    3637    EditingRangeIsRelativeTo editingRangeIsRelativeTo { EditingRangeIsRelativeTo::EditableRoot };
    3738};

  • trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

    r245112 r245144  
    41804180- (void)insertText:(NSString *)aStringValue
    41814181{
    4182     _page->insertTextAsync(aStringValue, WebKit::EditingRange(), { });
     4182    auto* keyboard = [UIKeyboardImpl sharedInstance];
     4183
     4184    WebKit::InsertTextOptions options;
     4185    options.processingUserGesture = [keyboard respondsToSelector:@selector(isCallingInputDelegate)] && keyboard.isCallingInputDelegate;
     4186
     4187    _page->insertTextAsync(aStringValue, WebKit::EditingRange(), WTFMove(options));
    41834188}
    41844189
    … …  
    46724677- (void)executeEditCommandWithCallback:(NSString *)commandName
    46734678{
     4679    // FIXME: Editing commands are not considered by WebKit as user initiated even if they are the result
     4680    // of keydown or keyup. We need to query the keyboard to determine if this was called from the keyboard
     4681    // or not to know whether to tell WebKit to treat this command as user initiated or not.
    46744682    [self beginSelectionChange];
    46754683    RetainPtr<WKContentView> view = self;

  • trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp

    r245073 r245144  
    51365136    Ref<Frame> protector(frame);
    51375137
     5138    UserGestureIndicator gestureIndicator { options.processingUserGesture ? ProcessingUserGesture : NotProcessingUserGesture, frame.document() };
     5139
    51385140    bool replacesText = false;
    51395141    if (replacementEditingRange.location != notFound) {
Note: See TracChangeset for help on using the changeset viewer.