WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
235184
Crash in Document::updateStyleIfNeeded() when removing a node containing the drag caret
https://bugs.webkit.org/show_bug.cgi?id=235184
Summary
Crash in Document::updateStyleIfNeeded() when removing a node containing the ...
Wenson Hsieh
Reported
2022-01-13 08:21:08 PST
rdar://74845918
Attachments
Test case
(993 bytes, text/html)
2022-01-13 08:23 PST
,
Wenson Hsieh
no flags
Details
For EWS
(11.17 KB, patch)
2022-01-13 09:22 PST
,
Wenson Hsieh
darin
: review+
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
For landing
(12.12 KB, patch)
2022-01-13 11:42 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Wenson Hsieh
Comment 1
2022-01-13 08:23:36 PST
Created
attachment 449063
[details]
Test case
Wenson Hsieh
Comment 2
2022-01-13 09:22:19 PST
Created
attachment 449069
[details]
For EWS
Darin Adler
Comment 3
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?
Wenson Hsieh
Comment 4
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()"?
Darin Adler
Comment 5
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.
Darin Adler
Comment 6
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).
Wenson Hsieh
Comment 7
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.
Wenson Hsieh
Comment 8
2022-01-13 11:42:10 PST
Created
attachment 449089
[details]
For landing
EWS
Comment 9
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]
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug