[webkit-changes] [WebKit/WebKit] 8922f7: (REGRESSION 262148 at main) No repaint when deleting ...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8922f7c4d3323f179770504e36a3a8b60596ea58
      https://github.com/WebKit/WebKit/commit/8922f7c4d3323f179770504e36a3a8b60596ea58
  Author: Alan Baradlay <zalan at apple.com>
  Date:   2023-05-19 (Fri, 19 May 2023)

  Changed paths:
    A LayoutTests/fast/inline/range-replace-partial-layout-invalidation-expected.html
    A LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html
    M Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp

  Log Message:
  -----------
  (REGRESSION 262148 at main) No repaint when deleting text, possibly only when the deleted text spans more than one line
https://bugs.webkit.org/show_bug.cgi?id=257043
<rdar://109538333>

Reviewed by Antti Koivisto.

Normally while editing inline content in a content-editable container e.g

  "This is some long
   long long long
   long text content"

  and select/delete "long long text" (spanning over line#2 and #3)

What happens is RenderText receives a content mutation event pointing to the _beginning_ of "long long text".
As a result we damage line #2 and run a partial layout staring from line#2 until after we see no layout change anymore or we hit content end.

However some JS based editors call innerHTML instead to mimic editing steps turning the above example to a "range replace"
type of mutation where the entire text content is getting replaced with the "new", shortened content.

In such cases, instead of receiving the position of the actual damage, we end up with the offset value of 0
since the entire content is being replaced (even though it's just a slight change in the text content)
Now we damage line#0 and start running layout from the very first line until we see no layout change...which is the second line
since the actual damage is on the third line.

Since IFC does not support such mutations yet, in this patch we disable range based bailout which means while
we still run partial inline layout, we always go all the way to the bottom of the content.

/fast/inline/range-replace-partial-layout-invalidation-expected.html: Added.
* LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html: Added.
* Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
(WebCore::Layout::InlineInvalidation::textWillBeRemoved):

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