Bug 50218 - chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c5dd65199668a34)
Summary: chrome.dll!WebCore::canHaveChildrenForEditing ReadAV@NULL (4c335fdc0441ae912c...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Nobody
URL: http://code.google.com/p/chromium/iss...
Keywords: HasReduction
Depends on:
Reported: 2010-11-30 02:53 PST by Berend-Jan Wever
Modified: 2017-07-18 08:26 PDT (History)
5 users (show)

See Also:

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

Note You need to log in before you can comment on or make changes to this bug.
Description Berend-Jan Wever 2010-11-30 02:53:39 PST
Created attachment 75119 [details]

  with(window.getSelection()) {
  document.designMode = "on";

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
Comment 1 Ryosuke Niwa 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.
Comment 2 Ryosuke Niwa 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.
Comment 3 Ryosuke Niwa 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.
Comment 4 Benjamin (Ben) Kalman 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.