Summary: | Crash in WebCore::StyledMarkupAccumulator::traverseNodesForSerialization | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||||
Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | cgarcia, dino, ews-watchlist, mcatanzaro, mifenton, rniwa, svillar, webkit-bug-importer, wenson_hsieh | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=1758370 https://bugzilla.redhat.com/show_bug.cgi?id=1758814 |
||||||||
Attachments: |
|
Description
Michael Catanzaro
2019-06-26 09:58:02 PDT
*** Bug 200711 has been marked as a duplicate of this bug. *** *** Bug 197267 has been marked as a duplicate of this bug. *** (In reply to Michael Catanzaro from comment #0) > Don't have a reproducer, only have the backtrace: I found a reproducer! Visit https://bugs.chromium.org/p/chromium/issues/detail?id=939804 and attempt to select any text on the page. Crash. *** Bug 204401 has been marked as a duplicate of this bug. *** Moving component to DOM. It isn't really a CSS issue. Adding Ryosuke and Dino as they were involved in the fix for bug 191921 Actually the component should be "HTML Editing" (In reply to Sergio Villar Senin from comment #6) > Adding Ryosuke and Dino as they were involved in the fix for bug 191921 The problem is indeed nextSkippingChildren() that returns nullptr, so it's related to bug #191921 I can confirm this is not GTK specific, I managed to reproduce it with layout test editing/pasteboard/copy-paste-across-shadow-boundaries-with-style-2.html in Safari. Steps: 1. Open the test 2. Start selecting from hello 3. When reaching the space the selection moves and the rest is actually selected 4. Right click -> copy -> Web process crashes In GTK it crashes just selecting the text because we copy the selection to the primary clipboard. *** Bug 212222 has been marked as a duplicate of this bug. *** Created attachment 406503 [details]
Patch
Comment on attachment 406503 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406503&action=review > LayoutTests/editing/pasteboard/copy-across-shadow-boundaries-crash.html:2 > +<body> Nit: you don't need those two. Simply use <!DOCTYPE html> and remove also the closing tags. > Source/WebCore/editing/markup.cpp:671 > + if (pastEnd && (isDescendantOf(*pastEnd, *n) || !next)) Not sure if the !next check should be in a different if () block. For example what happens if !pastEnd and !next ? In theory we'd end up having n == nullptr in the next iteration leading to a crash, wouldn't we? Comment on attachment 406503 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406503&action=review >> LayoutTests/editing/pasteboard/copy-across-shadow-boundaries-crash.html:2 >> +<body> > > Nit: you don't need those two. Simply use <!DOCTYPE html> and remove also the closing tags. Does it matter? >> Source/WebCore/editing/markup.cpp:671 >> + if (pastEnd && (isDescendantOf(*pastEnd, *n) || !next)) > > Not sure if the !next check should be in a different if () block. > > For example what happens if !pastEnd and !next ? In theory we'd end up having n == nullptr in the next iteration leading to a crash, wouldn't we? And what do we use then for next if pastEnd is also nullptr? I would need a test to understand that case, I'm afraid. Comment on attachment 406503 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406503&action=review >>> Source/WebCore/editing/markup.cpp:671 >>> + if (pastEnd && (isDescendantOf(*pastEnd, *n) || !next)) >> >> Not sure if the !next check should be in a different if () block. >> >> For example what happens if !pastEnd and !next ? In theory we'd end up having n == nullptr in the next iteration leading to a crash, wouldn't we? > > And what do we use then for next if pastEnd is also nullptr? I would need a test to understand that case, I'm afraid. The loop will terminate if next is null and pastEnd is also null because the loop invariant is that n != pastEnd. Committed r265647: <https://trac.webkit.org/changeset/265647> |