[webkit-changes] [WebKit/WebKit] ce1f5b: REGRESSION (264086 at main): [iOS 17] Autocorrect hig...

Wenson Hsieh noreply at github.com
Wed Jun 7 17:39:27 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ce1f5b1c5dd74c19b8833b169298249b915d0901
      https://github.com/WebKit/WebKit/commit/ce1f5b1c5dd74c19b8833b169298249b915d0901
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-06-07 (Wed, 07 Jun 2023)

  Changed paths:
    M Source/WebCore/dom/SimpleRange.h
    M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm

  Log Message:
  -----------
  REGRESSION (264086 at main): [iOS 17] Autocorrect highlight is sometimes incorrect in Mail compose
https://bugs.webkit.org/show_bug.cgi?id=257830
rdar://109582406

Reviewed by Megan Gardner and Aditya Keerthi.

The refactoring in 264086 at main introduced a subtle behavior change in the case where the text
iterator emits spaces for soft line breaks in an `_editable` web view. When emitting text for a soft
line break, we previously appended the zero rect in the list of `textRects` for this character
range; however, after `264086 at main`, we now skip the rect altogether, which causes the list of rects
to fall out of sync with the combined `contextBefore` + `selectedText` + `contextAfter` string.
Consequently, UIKit (which currently assumes that indices into the string correspond directly to
indices of rects in `textRects`) ends up using the wrong character layout rects.

This patch fixes the above by restoring preexisting behavior and appending a single empty rect in
the case where the text iterator finds (non-empty) text, but there are no character rects.

Additionally, I attempted to add a debug assertion to verify that the number of resulting text rects
is always consistent with the combined length of the context and selection strings; however, this
uncovered some bugs in the existing implementation, even prior the changes in 264086 at main, where we
would sometimes end up with either too many or too few rects, when running the following three
layout tests:

• editing/selection/ios/update-selection-after-iframe-scroll.html
• editing/selection/ios/update-selection-after-overflow-scroll.html
• editing/selection/shift-click-includes-existing-selection.html

This patch fixes the assertion in `editing/selection/shift-click-includes-existing-selection.html`,
where we end up with too many text rects due to the fact that the text iterator advances to both the
upstream and downstream positions of a line break, emitting "\n" both times with the same rect. To
avoid this, we keep track of the last `SimpleRange` we observed, and avoid emitting a duplicate rect
in the case where we advance to the a range we just visited.

Test: DocumentEditingContext.CharacterRectsInEditableWebView

* Source/WebCore/dom/SimpleRange.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::requestDocumentEditingContext):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:

Canonical link: https://commits.webkit.org/264969@main




More information about the webkit-changes mailing list