| Summary: | chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c5dd65199668a34) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Berend-Jan Wever <skylined> | ||||||
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | CC: | enrica, eric, kalman, rniwa, tony | ||||||
| Priority: | P1 | Keywords: | HasReduction | ||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| URL: | http://code.google.com/p/chromium/issues/detail?id=64749 | ||||||||
| Attachments: |
|
||||||||
The problem is that visible start and end of the selection is null in ApplyBlockElementCommand::doApply. This possibly a bug in Position::isCandidate. Created attachment 75620 [details]
somewhat simpler repro
I don't know how to fix this crash. Right now, we're not allowing the first position inside body to be a candidate even if it didn't have any other candidate in the editable region at all. One way to fix this problem is to move the special case for unsplittable element in formatSelection to doApply. But this would only fix IndentOutdentCommand and FormatBlockCommand. I'm sure a similar problem exists for other editing commands as well. However, allowing the said position to be a candidate breaks so may assumptions we make in editing and causes hundreds of tests to fail / crash.
After debugging for a couple of hours, I'm almost convinced that Position::atEditingBoundary is broken:
// A position is considered at editing boundary if one of the following is true:
// 1. It is the first position in the node and the next visually equivalent position
// is non editable.
// 2. It is the last position in the node and the previous visually equivalent position
// is non editable.
// 3. It is an editable position and both the next and previous visually equivalent
// positions are both non editable.
bool Position::atEditingBoundary() const
{
Position nextPosition = downstream(CanCrossEditingBoundary);
if (atFirstEditingPositionForNode() && nextPosition.isNotNull() && !nextPosition.node()->isContentEditable())
return true;
Position prevPosition = upstream(CanCrossEditingBoundary);
if (atLastEditingPositionForNode() && prevPosition.isNotNull() && !prevPosition.node()->isContentEditable())
return true;
return nextPosition.isNotNull() && !nextPosition.node()->isContentEditable()
&& prevPosition.isNotNull() && !prevPosition.node()->isContentEditable();
}
Kalman, are you familiar with this function? This might be related to what you've been working on.
> Kalman, are you familiar with this function? This might be related to what you've been working on.
No, not really. I haven't run into a problem with it (yet?) but I also haven't been debugging a code path that touches it afaik.
|
Created attachment 75119 [details] Repro Repro: <body><script> with(window.getSelection()) { addRange(document.createRange()); collapseToStart(); } document.designMode = "on"; document.write('<video>'); document.execCommand("indent"); </script> id: chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c5dd65199668a34) description: Attempt to read from unallocated NULL pointer+0x24 in chrome.dll!WebCore::canHaveChildrenForEditing application: Chromium 9.0.596.0 stack: chrome.dll!WebCore::canHaveChildrenForEditing chrome.dll!WebCore::CompositeEditCommand::insertNodeAt chrome.dll!WebCore::ApplyBlockElementCommand::formatSelection chrome.dll!WebCore::ApplyBlockElementCommand::doApply chrome.dll!WebCore::EditCommand::apply chrome.dll!WebCore::applyCommand chrome.dll!WebCore::executeIndent chrome.dll!WebCore::Editor::Command::execute chrome.dll!WebCore::Document::execCommand chrome.dll!WebCore::DocumentInternal::execCommandCallback chrome.dll!v8::internal::HandleApiCallHelper<...> chrome.dll!v8::internal::Builtin_HandleApiCall chrome.dll!v8::internal::Invoke chrome.dll!v8::internal::Execution::Call ...