Bug 19219

Summary:

ASSERT in editing code, when redo called after disabling design mode

Product:

WebKit

Reporter:

Eric Seidel (no email) <eric>

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

justin.garcia

Priority:

Version:

528+ (Nightly build)

Hardware:

Mac

OS:

OS X 10.5

Bug Depends on:

Bug Blocks:

18858

Attachments:

Description	Flags
test case, triggers ASSERT in debug mode	none

Eric Seidel (no email)

Reported 2008-05-23 12:01:20 PDT

ASSERT in editing code, when redo called after disabling design mode Another ASSERT found by the editing fuzzer. ASSERTION FAILED: enclosingNodeOfType(Position(m_refChild->parentNode(), 0), &isContentEditable) || !m_refChild->parentNode()->attached() (/Users/eseidel/Projects/WebKit/WebCore/editing/InsertNodeBeforeCommand.cpp:47 virtual void WebCore::InsertNodeBeforeCommand::doApply())

Attachments
test case, triggers ASSERT in debug mode (223 bytes, text/html) 2008-05-23 12:03 PDT, Eric Seidel (no email)	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Eric Seidel (no email)

Comment 1 2008-05-23 12:03:17 PDT

Created attachment 21317 [details] test case, triggers ASSERT in debug mode

Eric Seidel (no email)

Comment 2 2008-06-27 09:47:38 PDT

This still triggers on TOT. The parent note is attached. It's probably simply that it can't find an editable enclosing node, since contentEditable is off at that point. We should probably fail silently before we get to this ASSERT?

Eric Seidel (no email)

Comment 3 2009-02-19 11:59:59 PST

This no longer triggers an ASSERT for me in Debug mode. Closing.

Note You need to log in before you can comment on or make changes to this bug.