[Webkit-unassigned] [Bug 67763] Crashes in WebCore::InsertNodeBeforeCommand constructor.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 8 13:21:30 PDT 2011


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


Annie Sullivan <sullivan at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-unassigned at lists.web |sullivan at chromium.org
                   |kit.org                     |




--- Comment #3 from Annie Sullivan <sullivan at chromium.org>  2011-09-08 13:21:30 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > I took a quick look at this in the debugger and it's a pretty weird case with a <span> inside a contenteditable <meter> tag, which has shadow DOM.
> 
> HTMLMeterElement::canContainRangeEndPoint returns false, so we shouldn't be inserting a node inside a meter element.

So does that mean that the code setting the selection outside of the meter element is doing the right thing?

> > When InsertParagraphSeparatorCommand::doApply() gets called, startingSelection() and endingSelection() both look like this:
> 
> We should bail out in that case because we're outside of the contenteditable area.

Sounds good to me. I'm going to work on a patch that bails out of InsertParagraphSeparatorCommand::doApply() if we're outside of the contenteditable area. Let me know if you think the bailout should go in a different place.

When I'm writing the check, should I worry about the case where the selection is partially inside the contenteditable area? It seems like the code that handles that is already working fine; I can't actually reproduce any problems where startingSelection() is in the contenteditable area and endingSelection() is outside, or vice versa. It would make the check much simpler just to bail if either of them is outside of the editing area.

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



More information about the webkit-unassigned mailing list