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

Changeset 249012 in webkit


Ignore:
Timestamp:
Aug 22, 2019, 9:20:34 AM (7 years ago)
Author:
Alan Coon
Message:

Cherry-pick r249006. rdar://problem/54600921

Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
​https://bugs.webkit.org/show_bug.cgi?id=201023
<rdar://problem/54294794>

Reviewed by Ryosuke Niwa.

Source/WebCore:

Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places
focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the
WebKit ChangeLog for more details.

Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html

  • rendering/RenderLayer.cpp: (WebCore::RenderLayer::calculateClipRects const):

Source/WebKit:

After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element
was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due
to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on
Microsoft Word online.

However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform
input context changes when moving between the title and body fields, or when tapping to change selection. This
is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more
detail here). While text is never directly inserted into this hidden contenteditable, the events are observed
and used to "play back" editing in the main visible content area.

Thus, when moving between the title and body fields (or when changing selection within either), the only hint we
get is that the hidden editable element is blurred and immediately refocused. Since we no longer send
ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively
changed input contexts.

Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text
that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters
into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected
text in the title field.

To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately
refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input
context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious
for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden
editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused
element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a
single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus
messages we would've sent in previous releases).

  • Platform/spi/ios/UIKitSPI.h:
  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:

Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus
moves away from and immediately returns to a hidden editable element.

  • UIProcess/ios/PageClientImplIOS.h:
  • UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement):
  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]):

Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new
autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request
would've still happened anyways in the case where we would previously have sent an ElementDidFocus message.

  • UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement):
  • WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::elementDidFocus):

In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same
element, we should still notify the UI process so that it can synchronize state between the application process
and kbd. See above for more details.

(WebKit::WebPage::elementDidBlur):
(WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):

  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):

LayoutTests:

Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an
empty, borderless subframe.

  • editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added.
  • editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added.

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

Location:
branches/safari-608-branch
Files:
2 added
16 edited

Legend:

Unmodified
Added
Removed

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

    r249011 r249012  
     12019-08-22  Kocsen Chung  <kocsen_chung@apple.com>
     2
     3        Cherry-pick r249006. rdar://problem/54600921
     4
     5    Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     6    https://bugs.webkit.org/show_bug.cgi?id=201023
     7    <rdar://problem/54294794>
     8   
     9    Reviewed by Ryosuke Niwa.
     10   
     11    Source/WebCore:
     12   
     13    Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places
     14    focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the
     15    WebKit ChangeLog for more details.
     16   
     17    Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html
     18   
     19    * rendering/RenderLayer.cpp:
     20    (WebCore::RenderLayer::calculateClipRects const):
     21   
     22    Source/WebKit:
     23   
     24    After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element
     25    was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due
     26    to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on
     27    Microsoft Word online.
     28   
     29    However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform
     30    input context changes when moving between the title and body fields, or when tapping to change selection. This
     31    is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more
     32    detail here). While text is never directly inserted into this hidden contenteditable, the events are observed
     33    and used to "play back" editing in the main visible content area.
     34   
     35    Thus, when moving between the title and body fields (or when changing selection within either), the only hint we
     36    get is that the hidden editable element is blurred and immediately refocused. Since we no longer send
     37    ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively
     38    changed input contexts.
     39   
     40    Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text
     41    that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters
     42    into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected
     43    text in the title field.
     44   
     45    To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately
     46    refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input
     47    context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious
     48    for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden
     49    editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused
     50    element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a
     51    single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus
     52    messages we would've sent in previous releases).
     53   
     54    * Platform/spi/ios/UIKitSPI.h:
     55    * UIProcess/PageClient.h:
     56    * UIProcess/WebPageProxy.h:
     57    * UIProcess/WebPageProxy.messages.in:
     58   
     59    Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus
     60    moves away from and immediately returns to a hidden editable element.
     61   
     62    * UIProcess/ios/PageClientImplIOS.h:
     63    * UIProcess/ios/PageClientImplIOS.mm:
     64    (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement):
     65    * UIProcess/ios/WKContentViewInteraction.h:
     66    * UIProcess/ios/WKContentViewInteraction.mm:
     67    (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]):
     68   
     69    Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new
     70    autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request
     71    would've still happened anyways in the case where we would previously have sent an ElementDidFocus message.
     72   
     73    * UIProcess/ios/WebPageProxyIOS.mm:
     74    (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement):
     75    * WebProcess/WebPage/WebPage.cpp:
     76    (WebKit::WebPage::elementDidFocus):
     77   
     78    In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same
     79    element, we should still notify the UI process so that it can synchronize state between the application process
     80    and kbd. See above for more details.
     81   
     82    (WebKit::WebPage::elementDidBlur):
     83    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     84    * WebProcess/WebPage/WebPage.h:
     85    * WebProcess/WebPage/ios/WebPageIOS.mm:
     86    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     87   
     88    LayoutTests:
     89   
     90    Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an
     91    empty, borderless subframe.
     92   
     93    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added.
     94    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added.
     95   
     96   
     97    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249006 268f45cc-cd09-0410-ab3c-d52691b4dbfc
     98
     99    2019-08-22  Wenson Hsieh  <wenson_hsieh@apple.com>
     100
     101            Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     102            https://bugs.webkit.org/show_bug.cgi?id=201023
     103            <rdar://problem/54294794>
     104
     105            Reviewed by Ryosuke Niwa.
     106
     107            Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an
     108            empty, borderless subframe.
     109
     110            * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added.
     111            * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added.
     112
    11132019-08-22  Kocsen Chung  <kocsen_chung@apple.com>
    2114

  • branches/safari-608-branch/Source/WebCore/ChangeLog

    r249011 r249012  
     12019-08-22  Kocsen Chung  <kocsen_chung@apple.com>
     2
     3        Cherry-pick r249006. rdar://problem/54600921
     4
     5    Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     6    https://bugs.webkit.org/show_bug.cgi?id=201023
     7    <rdar://problem/54294794>
     8   
     9    Reviewed by Ryosuke Niwa.
     10   
     11    Source/WebCore:
     12   
     13    Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places
     14    focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the
     15    WebKit ChangeLog for more details.
     16   
     17    Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html
     18   
     19    * rendering/RenderLayer.cpp:
     20    (WebCore::RenderLayer::calculateClipRects const):
     21   
     22    Source/WebKit:
     23   
     24    After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element
     25    was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due
     26    to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on
     27    Microsoft Word online.
     28   
     29    However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform
     30    input context changes when moving between the title and body fields, or when tapping to change selection. This
     31    is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more
     32    detail here). While text is never directly inserted into this hidden contenteditable, the events are observed
     33    and used to "play back" editing in the main visible content area.
     34   
     35    Thus, when moving between the title and body fields (or when changing selection within either), the only hint we
     36    get is that the hidden editable element is blurred and immediately refocused. Since we no longer send
     37    ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively
     38    changed input contexts.
     39   
     40    Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text
     41    that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters
     42    into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected
     43    text in the title field.
     44   
     45    To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately
     46    refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input
     47    context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious
     48    for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden
     49    editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused
     50    element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a
     51    single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus
     52    messages we would've sent in previous releases).
     53   
     54    * Platform/spi/ios/UIKitSPI.h:
     55    * UIProcess/PageClient.h:
     56    * UIProcess/WebPageProxy.h:
     57    * UIProcess/WebPageProxy.messages.in:
     58   
     59    Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus
     60    moves away from and immediately returns to a hidden editable element.
     61   
     62    * UIProcess/ios/PageClientImplIOS.h:
     63    * UIProcess/ios/PageClientImplIOS.mm:
     64    (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement):
     65    * UIProcess/ios/WKContentViewInteraction.h:
     66    * UIProcess/ios/WKContentViewInteraction.mm:
     67    (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]):
     68   
     69    Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new
     70    autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request
     71    would've still happened anyways in the case where we would previously have sent an ElementDidFocus message.
     72   
     73    * UIProcess/ios/WebPageProxyIOS.mm:
     74    (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement):
     75    * WebProcess/WebPage/WebPage.cpp:
     76    (WebKit::WebPage::elementDidFocus):
     77   
     78    In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same
     79    element, we should still notify the UI process so that it can synchronize state between the application process
     80    and kbd. See above for more details.
     81   
     82    (WebKit::WebPage::elementDidBlur):
     83    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     84    * WebProcess/WebPage/WebPage.h:
     85    * WebProcess/WebPage/ios/WebPageIOS.mm:
     86    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     87   
     88    LayoutTests:
     89   
     90    Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an
     91    empty, borderless subframe.
     92   
     93    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added.
     94    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added.
     95   
     96   
     97    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249006 268f45cc-cd09-0410-ab3c-d52691b4dbfc
     98
     99    2019-08-22  Wenson Hsieh  <wenson_hsieh@apple.com>
     100
     101            Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     102            https://bugs.webkit.org/show_bug.cgi?id=201023
     103            <rdar://problem/54294794>
     104
     105            Reviewed by Ryosuke Niwa.
     106
     107            Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places
     108            focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the
     109            WebKit ChangeLog for more details.
     110
     111            Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html
     112
     113            * rendering/RenderLayer.cpp:
     114            (WebCore::RenderLayer::calculateClipRects const):
     115
    11162019-08-22  Kocsen Chung  <kocsen_chung@apple.com>
    2117

  • branches/safari-608-branch/Source/WebCore/rendering/RenderLayer.cpp

    r249011 r249012  
    68196819            return false;
    68206820
     6821        if (is<HTMLFrameOwnerElement>(layer.renderer().element()) && layer.visibleSize().isEmpty())
     6822            return true;
     6823
    68216824        LayoutRect layerBounds;
    68226825        ClipRect backgroundRect;

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

    r248988 r249012  
     12019-08-22  Kocsen Chung  <kocsen_chung@apple.com>
     2
     3        Cherry-pick r249006. rdar://problem/54600921
     4
     5    Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     6    https://bugs.webkit.org/show_bug.cgi?id=201023
     7    <rdar://problem/54294794>
     8   
     9    Reviewed by Ryosuke Niwa.
     10   
     11    Source/WebCore:
     12   
     13    Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places
     14    focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the
     15    WebKit ChangeLog for more details.
     16   
     17    Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html
     18   
     19    * rendering/RenderLayer.cpp:
     20    (WebCore::RenderLayer::calculateClipRects const):
     21   
     22    Source/WebKit:
     23   
     24    After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element
     25    was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due
     26    to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on
     27    Microsoft Word online.
     28   
     29    However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform
     30    input context changes when moving between the title and body fields, or when tapping to change selection. This
     31    is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more
     32    detail here). While text is never directly inserted into this hidden contenteditable, the events are observed
     33    and used to "play back" editing in the main visible content area.
     34   
     35    Thus, when moving between the title and body fields (or when changing selection within either), the only hint we
     36    get is that the hidden editable element is blurred and immediately refocused. Since we no longer send
     37    ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively
     38    changed input contexts.
     39   
     40    Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text
     41    that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters
     42    into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected
     43    text in the title field.
     44   
     45    To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately
     46    refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input
     47    context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious
     48    for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden
     49    editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused
     50    element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a
     51    single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus
     52    messages we would've sent in previous releases).
     53   
     54    * Platform/spi/ios/UIKitSPI.h:
     55    * UIProcess/PageClient.h:
     56    * UIProcess/WebPageProxy.h:
     57    * UIProcess/WebPageProxy.messages.in:
     58   
     59    Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus
     60    moves away from and immediately returns to a hidden editable element.
     61   
     62    * UIProcess/ios/PageClientImplIOS.h:
     63    * UIProcess/ios/PageClientImplIOS.mm:
     64    (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement):
     65    * UIProcess/ios/WKContentViewInteraction.h:
     66    * UIProcess/ios/WKContentViewInteraction.mm:
     67    (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]):
     68   
     69    Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new
     70    autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request
     71    would've still happened anyways in the case where we would previously have sent an ElementDidFocus message.
     72   
     73    * UIProcess/ios/WebPageProxyIOS.mm:
     74    (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement):
     75    * WebProcess/WebPage/WebPage.cpp:
     76    (WebKit::WebPage::elementDidFocus):
     77   
     78    In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same
     79    element, we should still notify the UI process so that it can synchronize state between the application process
     80    and kbd. See above for more details.
     81   
     82    (WebKit::WebPage::elementDidBlur):
     83    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     84    * WebProcess/WebPage/WebPage.h:
     85    * WebProcess/WebPage/ios/WebPageIOS.mm:
     86    (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     87   
     88    LayoutTests:
     89   
     90    Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an
     91    empty, borderless subframe.
     92   
     93    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added.
     94    * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added.
     95   
     96   
     97    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249006 268f45cc-cd09-0410-ab3c-d52691b4dbfc
     98
     99    2019-08-22  Wenson Hsieh  <wenson_hsieh@apple.com>
     100
     101            Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com
     102            https://bugs.webkit.org/show_bug.cgi?id=201023
     103            <rdar://problem/54294794>
     104
     105            Reviewed by Ryosuke Niwa.
     106
     107            After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element
     108            was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due
     109            to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on
     110            Microsoft Word online.
     111
     112            However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform
     113            input context changes when moving between the title and body fields, or when tapping to change selection. This
     114            is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more
     115            detail here). While text is never directly inserted into this hidden contenteditable, the events are observed
     116            and used to "play back" editing in the main visible content area.
     117
     118            Thus, when moving between the title and body fields (or when changing selection within either), the only hint we
     119            get is that the hidden editable element is blurred and immediately refocused. Since we no longer send
     120            ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively
     121            changed input contexts.
     122
     123            Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text
     124            that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters
     125            into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected
     126            text in the title field.
     127
     128            To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately
     129            refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input
     130            context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious
     131            for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden
     132            editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused
     133            element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a
     134            single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus
     135            messages we would've sent in previous releases).
     136
     137            * Platform/spi/ios/UIKitSPI.h:
     138            * UIProcess/PageClient.h:
     139            * UIProcess/WebPageProxy.h:
     140            * UIProcess/WebPageProxy.messages.in:
     141
     142            Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus
     143            moves away from and immediately returns to a hidden editable element.
     144
     145            * UIProcess/ios/PageClientImplIOS.h:
     146            * UIProcess/ios/PageClientImplIOS.mm:
     147            (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement):
     148            * UIProcess/ios/WKContentViewInteraction.h:
     149            * UIProcess/ios/WKContentViewInteraction.mm:
     150            (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]):
     151
     152            Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new
     153            autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request
     154            would've still happened anyways in the case where we would previously have sent an ElementDidFocus message.
     155
     156            * UIProcess/ios/WebPageProxyIOS.mm:
     157            (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement):
     158            * WebProcess/WebPage/WebPage.cpp:
     159            (WebKit::WebPage::elementDidFocus):
     160
     161            In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same
     162            element, we should still notify the UI process so that it can synchronize state between the application process
     163            and kbd. See above for more details.
     164
     165            (WebKit::WebPage::elementDidBlur):
     166            (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     167            * WebProcess/WebPage/WebPage.h:
     168            * WebProcess/WebPage/ios/WebPageIOS.mm:
     169            (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded):
     170
    11712019-08-21  Kocsen Chung  <kocsen_chung@apple.com>
    2172

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

    r248573 r249012  
    271271@interface UIKeyboardImpl : UIView <UIKeyboardCandidateListDelegate>
    272272- (BOOL)smartInsertDeleteIsEnabled;
     273- (void)updateForChangedSelection;
    273274@end
    274275

  • branches/safari-608-branch/Source/WebKit/UIProcess/PageClient.h

    r247981 r249012  
    386386
    387387    virtual void elementDidFocus(const FocusedElementInformation&, bool userIsInteracting, bool blurPreviousNode, OptionSet<WebCore::ActivityState::Flag> activityStateChanges, API::Object* userData) = 0;
     388    virtual void updateInputContextAfterBlurringAndRefocusingElement() = 0;
    388389    virtual void elementDidBlur() = 0;
    389390    virtual void focusedElementDidChangeInputMode(WebCore::InputMode) = 0;

  • branches/safari-608-branch/Source/WebKit/UIProcess/WebPageProxy.h

    r248617 r249012  
    19441944    void elementDidFocus(const FocusedElementInformation&, bool userIsInteracting, bool blurPreviousNode, OptionSet<WebCore::ActivityState::Flag> activityStateChanges, const UserData&);
    19451945    void elementDidBlur();
     1946    void updateInputContextAfterBlurringAndRefocusingElement();
    19461947    void focusedElementDidChangeInputMode(WebCore::InputMode);
    19471948    void didReleaseAllTouchPoints();

  • branches/safari-608-branch/Source/WebKit/UIProcess/WebPageProxy.messages.in

    r247970 r249012  
    409409    ElementDidFocus(struct WebKit::FocusedElementInformation information, bool userIsInteracting, bool blurPreviousNode, OptionSet<WebCore::ActivityState::Flag> activityStateChanges, WebKit::UserData userData)
    410410    ElementDidBlur()
     411    UpdateInputContextAfterBlurringAndRefocusingElement()
    411412    FocusedElementDidChangeInputMode(enum:uint8_t WebCore::InputMode mode)
    412413    ScrollingNodeScrollWillStartScroll()

  • branches/safari-608-branch/Source/WebKit/UIProcess/ios/PageClientImplIOS.h

    r247981 r249012  
    150150
    151151    void elementDidFocus(const FocusedElementInformation&, bool userIsInteracting, bool blurPreviousNode, OptionSet<WebCore::ActivityState::Flag> activityStateChanges, API::Object* userData) override;
     152    void updateInputContextAfterBlurringAndRefocusingElement() final;
    152153    void elementDidBlur() override;
    153154    void focusedElementDidChangeInputMode(WebCore::InputMode) override;

  • branches/safari-608-branch/Source/WebKit/UIProcess/ios/PageClientImplIOS.mm

    r247981 r249012  
    561561}
    562562
     563void PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement()
     564{
     565    [m_contentView _updateInputContextAfterBlurringAndRefocusingElement];
     566}
     567
    563568bool PageClientImpl::isFocusingElement()
    564569{

  • branches/safari-608-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h

    r248837 r249012  
    458458- (void)_handleSmartMagnificationInformationForPotentialTap:(uint64_t)requestID renderRect:(const WebCore::FloatRect&)renderRect fitEntireRect:(BOOL)fitEntireRect viewportMinimumScale:(double)viewportMinimumScale viewportMaximumScale:(double)viewportMaximumScale;
    459459- (void)_elementDidFocus:(const WebKit::FocusedElementInformation&)information userIsInteracting:(BOOL)userIsInteracting blurPreviousNode:(BOOL)blurPreviousNode activityStateChanges:(OptionSet<WebCore::ActivityState::Flag>)activityStateChanges userObject:(NSObject <NSSecureCoding> *)userObject;
     460- (void)_updateInputContextAfterBlurringAndRefocusingElement;
    460461- (void)_elementDidBlur;
    461462- (void)_hideContextMenuHintContainer;

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

    r248840 r249012  
    54955495}
    54965496
     5497- (void)_updateInputContextAfterBlurringAndRefocusingElement
     5498{
     5499    if (!hasFocusedElement(_focusedElementInformation) || !_suppressSelectionAssistantReasons)
     5500        return;
     5501
     5502    [UIKeyboardImpl.activeInstance updateForChangedSelection];
     5503}
     5504
    54975505- (BOOL)shouldIgnoreKeyboardWillHideNotification
    54985506{

  • branches/safari-608-branch/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm

    r248622 r249012  
    905905}
    906906
     907void WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement()
     908{
     909    pageClient().updateInputContextAfterBlurringAndRefocusingElement();
     910}
     911
    907912void WebPageProxy::elementDidFocus(const FocusedElementInformation& information, bool userIsInteracting, bool blurPreviousNode, OptionSet<WebCore::ActivityState::Flag> activityStateChanges, const UserData& userData)
    908913{

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

    r248617 r249012  
    54705470{
    54715471    if (!shouldDispatchUpdateAfterFocusingElement(element)) {
     5472        updateInputContextAfterBlurringAndRefocusingElementIfNeeded(element);
    54725473        m_focusedElement = &element;
    54735474        m_recentlyBlurredElement = nullptr;
    … …  
    54775478    if (is<HTMLSelectElement>(element) || isTextFormControlOrEditableContent(element)) {
    54785479        m_focusedElement = &element;
     5480        m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement = false;
    54795481
    54805482#if PLATFORM(IOS_FAMILY)
    … …  
    55185520            protectedThis->m_recentlyBlurredElement = nullptr;
    55195521        });
     5522        m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement = false;
    55205523    }
    55215524}
    … …  
    66966699}
    66976700
     6701void WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded(Element&)
     6702{
     6703}
     6704
    66986705#endif // !PLATFORM(IOS_FAMILY)
    66996706

  • branches/safari-608-branch/Source/WebKit/WebProcess/WebPage/WebPage.h

    r248988 r249012  
    604604    void focusedElementDidChangeInputMode(WebCore::Element&, WebCore::InputMode);
    605605    void resetFocusedElementForFrame(WebFrame*);
     606    void updateInputContextAfterBlurringAndRefocusingElementIfNeeded(WebCore::Element&);
    606607
    607608    void disabledAdaptationsDidChange(const OptionSet<WebCore::DisabledAdaptations>&);
    … …  
    18251826    RefPtr<WebCore::Element> m_focusedElement;
    18261827    RefPtr<WebCore::Element> m_recentlyBlurredElement;
     1828    bool m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement { false };
    18271829    bool m_hasPendingEditorStateUpdate { false };
    18281830

  • branches/safari-608-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

    r248937 r249012  
    11711171}
    11721172
     1173void WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded(Element& element)
     1174{
     1175    if (m_recentlyBlurredElement != &element || !m_isShowingInputViewForFocusedElement)
     1176        return;
     1177
     1178    m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement = true;
     1179    callOnMainThread([this, protectedThis = makeRefPtr(this)] {
     1180        if (m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement)
     1181            send(Messages::WebPageProxy::UpdateInputContextAfterBlurringAndRefocusingElement());
     1182        m_hasPendingInputContextUpdateAfterBlurringAndRefocusingElement = false;
     1183    });
     1184}
     1185
    11731186void WebPage::blurFocusedElement()
    11741187{
Note: See TracChangeset for help on using the changeset viewer.