WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
50218
chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c5dd65199668a34)
https://bugs.webkit.org/show_bug.cgi?id=50218
Summary
chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c...
Berend-Jan Wever
Reported
2010-11-30 02:53:39 PST
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 ...
Attachments
Repro
(214 bytes, text/html)
2010-11-30 02:53 PST
,
Berend-Jan Wever
no flags
Details
somewhat simpler repro
(181 bytes, text/html)
2010-12-04 16:50 PST
,
Ryosuke Niwa
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2010-12-03 18:45:33 PST
The problem is that visible start and end of the selection is null in ApplyBlockElementCommand::doApply. This possibly a bug in Position::isCandidate.
Ryosuke Niwa
Comment 2
2010-12-04 16:50:21 PST
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.
Ryosuke Niwa
Comment 3
2010-12-04 16:53:23 PST
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.
Benjamin (Ben) Kalman
Comment 4
2010-12-05 17:32:53 PST
> 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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug