Bug 24500 - ASSERT in editing code, ASSERTION FAILED: selection.isCaretOrRange()
Summary: ASSERT in editing code, ASSERTION FAILED: selection.isCaretOrRange()
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 18858
  Show dependency tree / graph
 
Reported: 2009-03-10 15:23 PDT by Eric Seidel (no email)
Modified: 2009-03-10 15:43 PDT (History)
3 users (show)

See Also:

Attachments
test case ASSERTs in debug mode (163 bytes, text/html)
2009-03-10 15:26 PDT, Eric Seidel (no email) 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2009-03-10 15:23:12 PDT 
ASSERT in editing code, ASSERTION FAILED: selection.isCaretOrRange()

<body>
<script>
var doc = document;
doc.execCommand('selectall');
doc.designMode = 'on';
doc.execCommand('insertimage', 0, '<pre>');
doc.execCommand('justifyfull', 0, 'javascript:1');
</script>

ASSERTION FAILED: selection.isCaretOrRange()
(/Users/eseidel/Projects/WebKit/WebCore/editing/ReplaceSelectionCommand.cpp:701 virtual void WebCore::ReplaceSelectionCommand::doApply())

Looks similar to bug 19075 which I closed as unreproducible.
Comment 1 Eric Seidel (no email) 2009-03-10 15:26:00 PDT 
Created attachment 28452 [details]
test case ASSERTs in debug mode
Comment 2 Eric Seidel (no email) 2009-03-10 15:39:41 PDT 
It seems somehow the selection is set to a rootless <br> just before the ReplaceSelectionCommand is run:

(gdb) p destination.m_deepPosition.container.get()->showTreeForThis()
*BR	0xde5240

    setEndingSelection(destination);
    applyCommandToComposite(ReplaceSelectionCommand::create(document(), fragment, true, false, !preserveStyle, false, true));

in CompositeEditorCommand::moveParagraphs
Comment 3 Eric Seidel (no email) 2009-03-10 15:43:23 PDT 
This could be the same root cause as https://bugs.webkit.org/show_bug.cgi?id=19066 ?  This is again an empty <img> at the beginning of a document, where the editing code could be getting confused as to if the best position should be [body, 0] or [img, 0] and doing strange things as a result...