| Summary: | Crash in WebCore::Node::lastChild while running ReplaceSelectionCommand::doApply | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED DUPLICATE | ||||||
| Severity: | Normal | CC: | Hironori.Fujii, jfernandez, mcatanzaro, rniwa | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=1570275 https://bugs.webkit.org/show_bug.cgi?id=182784 https://bugs.webkit.org/show_bug.cgi?id=186555 |
||||||
| Attachments: |
|
||||||
According to the bt, > insertedNodes = {m_firstNodeInserted = {static isRefPtr = <optimized out>, m_ptr = 0x7fa803ef2ae0}, m_lastNodeInserted = {static isRefPtr = <optimized out>, m_ptr = 0x0}} m_firstNodeInserted is not null, but m_lastNodeInserted is null. This must not happen. Both should be null or non-null. There is an unresolved bug in InsertedNodes::willRemoveNodePreservingChildren (Bug 182784) which can cause such inconsistency. I'm not confident it is relevant. *** This bug has been marked as a duplicate of bug 186555 *** |
Created attachment 338586 [details] Backtrace We got this Evolution crash report. (Full backtrace attached.) Truncated backtrace: Thread no. 1 (10 frames) #0 WebCore::Node::lastChild at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/dom/ContainerNode.h:189 #1 WebCore::Node::lastDescendant at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/dom/Node.cpp:386 #2 WebCore::ReplaceSelectionCommand::InsertedNodes::lastLeafInserted at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/ReplaceSelectionCommand.h:77 #3 WebCore::ReplaceSelectionCommand::doApply at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/ReplaceSelectionCommand.cpp:1187 #4 WebCore::CompositeEditCommand::apply at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/CompositeEditCommand.cpp:366 #5 WebCore::executeInsertFragment at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/EditorCommand.cpp:162 #6 WebCore::executeInsertHTML at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/EditorCommand.cpp:469 #7 WebCore::Document::execCommand at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/dom/Document.cpp:5115 #8 webkit_dom_document_exec_command at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebKit/WebProcess/InjectedBundle/API/gtk/DOM/WebKitDOMDocument.cpp:1223 #9 e_editor_dom_exec_command at /usr/src/debug/evolution-3.26.6-1.fc27.x86_64/src/modules/webkit-editor/web-extension/e-editor-dom-functions.c:625 Note it's executing an editing command: #3 WebCore::ReplaceSelectionCommand::doApply (this=<optimized out>) at /usr/src/debug/webkitgtk4-2.20.1-1.fc27.x86_64/Source/WebCore/editing/ReplaceSelectionCommand.cpp:1187 We're not sure how to reproduce, but here's some thoughts posted in the downstream bug: """ It looks to me, based on the backtrace, like there had been selected a text in the composer and it had been copied to a different place in the composer. Like this happened on Paste of some HTML content, possibly from the same composer. I cannot reproduce the crash myself, but I see that when having set the HTML composer format and trying to paste into a set of three empty lines, then one more line is deleted, the text is not pasted at the line where the cursor was. It can be an issue of evolution code, because I cannot reproduce this one-more-line-deleted issue in the MiniBrowser. In any case, evolution only calls webkit_dom_document_exec_command() with a well-formatted HTML code, possibly returned by webkit itself, thus I agree with you that it might be an issue in webkit, which "only" depends on certain state of the DOM structure. """