[Webkit-unassigned] [Bug 30116] WebCore::InsertLineBreakCommand::shouldUseBreakElement ReadAV at NULL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30116





--- Comment #17 from Tony Chang (Google) <tony at chromium.org>  2010-06-09 00:17:40 PST ---
(In reply to comment #15)
> (From update of attachment 58097 [details])
> Doesn't this make it so that we no longer canonicalize the position we're going to use when we hit enter?

I'm not sure I understand, which canonicalization isn't happening?

> I wonder if a better (albeit harder) fix would be to make it so that "VisiblePosition caret(selection.visibleStart())" doesn't create a VisiblePosition with a null deepEquivalent. Specifically, VisiblePosition::canonicalPosition would need to not return null. If I understand this all correctly, we return null because we skip over visibility:hidden nodes when looking for the canonical position. This makes sense in general, but I don't think it makes sense when the rootEditableElement is the visibility:hidden node. Maybe we should change that logic. WDYT?

VisiblePosition::canonicalPosition returns null because PositionIterator checks for visibility.  Changing this would be a big change which seems beyond the scope of this bug.  But maybe you're asking about only changing visibleStart some of the time?  That also seems tricky to implement (e.g. what happens if the rootEditableElement is visible but some child editable node is hidden)?

I found another crasher except with contenteditable areas, so I've uploaded a new patch.

If the goal of this bug is to just fix the crash, then perhaps we should just return early in both cases (or even return in EventHandler::defaultTextInputEventHandler.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.