⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 245225 in webkit


Ignore:
Timestamp:
May 12, 2019, 11:51:02 PM (7 years ago)
Author:
bshafiei@apple.com
Message:

Cherry-pick r245144. rdar://problem/47902054

[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>.

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Location:
branches/safari-608.1.24-branch
Files:
4 added
8 edited

Legend:

Unmodified
Added
Removed

  • branches/safari-608.1.24-branch/LayoutTests/ChangeLog

    r245126 r245225  
     12019-05-12  Babak Shafiei  <bshafiei@apple.com>
     2
     3        Cherry-pick r245144. rdar://problem/47902054
     4
     5    [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     6    https://bugs.webkit.org/show_bug.cgi?id=197632
     7    <rdar://problem/47902054>
     8   
     9    Reviewed by Brent Fulgham.
     10   
     11    Source/WebKit:
     12   
     13    Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
     14    opens a new window.
     15   
     16    By default we only allow popups to open if they were user initiated (like when a person clicks
     17    on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
     18    WebCore processes an event from WebKit. So long as this token is on the stack we consider
     19    all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
     20    the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
     21    part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
     22    However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
     23    with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
     24    to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
     25    and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
     26    to determine if it's being called by the keyboard. If it is then we can assume that this is
     27    part of key event handling and hence was initiated by the user. We can pass along this detail
     28    to the WebProcess for it to push a new UserGestureToken onto the stack.
     29   
     30    For now we only track whether text inserted by the keyboard was user initiated or not. In
     31    <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
     32   
     33    * Platform/spi/ios/UIKitSPI.h: Expose SPI.
     34    * Shared/Cocoa/InsertTextOptions.cpp:
     35    (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
     36    (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
     37    Encode and decode whether we are processing a user gesture.
     38   
     39    * Shared/Cocoa/InsertTextOptions.h:
     40    * UIProcess/ios/WKContentViewInteraction.mm:
     41    (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
     42    the embedding client did. We only want to privilege user initiated actions (the keyboard).
     43    * WebProcess/WebPage/WebPage.cpp:
     44    (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
     45    depending on whether we are or are not processing a user gesture.
     46   
     47    LayoutTests:
     48   
     49    Add tests to ensure we fire input and keypress events in the correct order and that we can
     50    submit a <form> with target = "_blank" using the Return key.
     51   
     52    * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
     53    * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
     54    * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
     55    * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
     56    * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
     57    in <rdar://problem/50596032>.
     58   
     59    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
     60
     61    2019-05-09  Daniel Bates  <dabates@apple.com>
     62
     63            [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     64            https://bugs.webkit.org/show_bug.cgi?id=197632
     65            <rdar://problem/47902054>
     66
     67            Reviewed by Brent Fulgham.
     68
     69            Add tests to ensure we fire input and keypress events in the correct order and that we can
     70            submit a <form> with target = "_blank" using the Return key.
     71
     72            * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
     73            * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
     74            * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
     75            * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
     76            * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
     77            in <rdar://problem/50596032>.
     78
    1792019-05-09  Antti Koivisto  <antti@apple.com>
    280

  • branches/safari-608.1.24-branch/LayoutTests/platform/ios/TestExpectations

    r245013 r245225  
    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

  • branches/safari-608.1.24-branch/Source/WebKit/ChangeLog

    r245112 r245225  
     12019-05-12  Babak Shafiei  <bshafiei@apple.com>
     2
     3        Cherry-pick r245144. rdar://problem/47902054
     4
     5    [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     6    https://bugs.webkit.org/show_bug.cgi?id=197632
     7    <rdar://problem/47902054>
     8   
     9    Reviewed by Brent Fulgham.
     10   
     11    Source/WebKit:
     12   
     13    Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
     14    opens a new window.
     15   
     16    By default we only allow popups to open if they were user initiated (like when a person clicks
     17    on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
     18    WebCore processes an event from WebKit. So long as this token is on the stack we consider
     19    all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
     20    the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
     21    part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
     22    However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
     23    with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
     24    to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
     25    and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
     26    to determine if it's being called by the keyboard. If it is then we can assume that this is
     27    part of key event handling and hence was initiated by the user. We can pass along this detail
     28    to the WebProcess for it to push a new UserGestureToken onto the stack.
     29   
     30    For now we only track whether text inserted by the keyboard was user initiated or not. In
     31    <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
     32   
     33    * Platform/spi/ios/UIKitSPI.h: Expose SPI.
     34    * Shared/Cocoa/InsertTextOptions.cpp:
     35    (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
     36    (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
     37    Encode and decode whether we are processing a user gesture.
     38   
     39    * Shared/Cocoa/InsertTextOptions.h:
     40    * UIProcess/ios/WKContentViewInteraction.mm:
     41    (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
     42    the embedding client did. We only want to privilege user initiated actions (the keyboard).
     43    * WebProcess/WebPage/WebPage.cpp:
     44    (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
     45    depending on whether we are or are not processing a user gesture.
     46   
     47    LayoutTests:
     48   
     49    Add tests to ensure we fire input and keypress events in the correct order and that we can
     50    submit a <form> with target = "_blank" using the Return key.
     51   
     52    * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
     53    * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
     54    * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
     55    * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
     56    * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
     57    in <rdar://problem/50596032>.
     58   
     59    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
     60
     61    2019-05-09  Daniel Bates  <dabates@apple.com>
     62
     63            [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
     64            https://bugs.webkit.org/show_bug.cgi?id=197632
     65            <rdar://problem/47902054>
     66
     67            Reviewed by Brent Fulgham.
     68
     69            Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
     70            opens a new window.
     71
     72            By default we only allow popups to open if they were user initiated (like when a person clicks
     73            on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
     74            WebCore processes an event from WebKit. So long as this token is on the stack we consider
     75            all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
     76            the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
     77            part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
     78            However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
     79            with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
     80            to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
     81            and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
     82            to determine if it's being called by the keyboard. If it is then we can assume that this is
     83            part of key event handling and hence was initiated by the user. We can pass along this detail
     84            to the WebProcess for it to push a new UserGestureToken onto the stack.
     85
     86            For now we only track whether text inserted by the keyboard was user initiated or not. In
     87            <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
     88
     89            * Platform/spi/ios/UIKitSPI.h: Expose SPI.
     90            * Shared/Cocoa/InsertTextOptions.cpp:
     91            (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
     92            (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
     93            Encode and decode whether we are processing a user gesture.
     94
     95            * Shared/Cocoa/InsertTextOptions.h:
     96            * UIProcess/ios/WKContentViewInteraction.mm:
     97            (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
     98            the embedding client did. We only want to privilege user initiated actions (the keyboard).
     99            * WebProcess/WebPage/WebPage.cpp:
     100            (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
     101            depending on whether we are or are not processing a user gesture.
     102
    11032019-05-08  Antoine Quint  <graouts@apple.com>
    2104

  • branches/safari-608.1.24-branch/Source/WebKit/Platform/spi/ios/UIKitSPI.h

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

  • branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.cpp

    r245073 r245225  
    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;

  • branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.h

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

  • branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

    r245112 r245225  
    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;

  • branches/safari-608.1.24-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp

    r245073 r245225  
    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.