Bug 235184

Summary: Crash in Document::updateStyleIfNeeded() when removing a node containing the drag caret
Product: WebKit Reporter: Wenson Hsieh <wenson_hsieh>
Component: HTML EditingAssignee: Wenson Hsieh <wenson_hsieh>
Status: RESOLVED FIXED    
Severity: Normal CC: akeerthi, darin, ews-watchlist, hi, megan_gardner, mifenton, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Test case
none
For EWS
darin: review+, ews-feeder: commit-queue-
For landing none

Description Wenson Hsieh 2022-01-13 08:21:08 PST
rdar://74845918
Comment 1 Wenson Hsieh 2022-01-13 08:23:36 PST
Created attachment 449063 [details]
Test case
Comment 2 Wenson Hsieh 2022-01-13 09:22:19 PST
Created attachment 449069 [details]
For EWS
Comment 3 Darin Adler 2022-01-13 09:53:54 PST
Comment on attachment 449069 [details]
For EWS

View in context: https://bugs.webkit.org/attachment.cgi?id=449069&action=review

> Source/WebCore/editing/FrameSelection.cpp:543
> -    clear();
> +    if (RefPtr node = m_position.deepEquivalent().anchorNode())
> +        invalidateCaretRect(node.get(), true);
> +
> +    m_position = { };
> +    clearCaretRect();

I worry that nothing is left behind here other than the regression test to explain the subtle reason why this must not call clear().

Is there any way we can make this subtle point more obvious? Function naming? Some discipline across this entire class that more explicitly addresses repaint issues? Some kind of comment?
Comment 4 Wenson Hsieh 2022-01-13 09:58:45 PST
Comment on attachment 449069 [details]
For EWS

View in context: https://bugs.webkit.org/attachment.cgi?id=449069&action=review

Thanks for the review!

>> Source/WebCore/editing/FrameSelection.cpp:543
>> +    clearCaretRect();
> 
> I worry that nothing is left behind here other than the regression test to explain the subtle reason why this must not call clear().
> 
> Is there any way we can make this subtle point more obvious? Function naming? Some discipline across this entire class that more explicitly addresses repaint issues? Some kind of comment?

That's a good point — perhaps I could factor this piece of logic out into helper method named something like, "clearCaretPositionWithoutUpdatingStyle()"?
Comment 5 Darin Adler 2022-01-13 10:00:31 PST
(In reply to Wenson Hsieh from comment #4)
> perhaps I could factor this piece of logic out into
> helper method named something like,
> "clearCaretPositionWithoutUpdatingStyle()"?

I love that.

My favorite type of comment is a good function name.
Comment 6 Darin Adler 2022-01-13 10:01:22 PST
Still might add a *brief* comment at the call site stating *why* it’s important to not update style in this case (and, by implication, why it’s not important in other cases).
Comment 7 Wenson Hsieh 2022-01-13 11:04:11 PST
(In reply to Darin Adler from comment #6)
> Still might add a *brief* comment at the call site stating *why* it’s
> important to not update style in this case (and, by implication, why it’s
> not important in other cases).

Sounds good! Will pull it into the helper method, and add a brief comment explaining that it's unsafe to update style here due to being in the middle of node removal.
Comment 8 Wenson Hsieh 2022-01-13 11:42:10 PST
Created attachment 449089 [details]
For landing
Comment 9 EWS 2022-01-13 13:26:12 PST
Committed r287992 (246019@main): <https://commits.webkit.org/246019@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 449089 [details].