Merge r221128 - DeleteSelectionCommand should be robust when starting…

… and ending editable positions cannot be found

https://bugs.webkit.org/show_bug.cgi?id=175914
<rdar://problem/29792688>

Reviewed by Ryosuke Niwa.

Source/WebCore:

DeleteSelectionCommand can cause a null dereference if editable start and end positions are not found. This can
happen when attempting to delete after selecting the contents within a canvas or output element with `read-write`
`-webkit-user-modify` style. To fix this, we make the initialization step of the DeleteSelectionCommand robust
when editable start and end positions are missing.

Test: editing/execCommand/forward-delete-read-write-canvas.html

* editing/DeleteSelectionCommand.cpp:
(WebCore::DeleteSelectionCommand::initializePositionData):

Make this initialization helper indicate failure via a bool return value. DeleteSelectionCommand::doApply bails
early if initializePositionData returned false.

(WebCore::DeleteSelectionCommand::doApply):
* editing/DeleteSelectionCommand.h:

LayoutTests:

Adds a new LayoutTest. This test passes if WebKit successfully loaded the page.

* editing/execCommand/forward-delete-read-write-canvas-expected.txt: Added.
* editing/execCommand/forward-delete-read-write-canvas.html: Added.

LayoutTests/ChangeLog

@@ -1,3 +1,16 @@
+2017-08-23  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        DeleteSelectionCommand should be robust when starting and ending editable positions cannot be found
+        https://bugs.webkit.org/show_bug.cgi?id=175914
+        <rdar://problem/29792688>
+
+        Reviewed by Ryosuke Niwa.
+
+        Adds a new LayoutTest. This test passes if WebKit successfully loaded the page.
+
+        * editing/execCommand/forward-delete-read-write-canvas-expected.txt: Added.
+        * editing/execCommand/forward-delete-read-write-canvas.html: Added.
+
 2017-08-21  Ms2ger  <Ms2ger@gmail.com>
 
         Stop media/video-controls-toggling.html from timing out.

LayoutTests/editing/execCommand/forward-delete-read-write-canvas-expected.txt

@@ -0,0 +1 @@
+PASS 

LayoutTests/editing/execCommand/forward-delete-read-write-canvas.html

@@ -0,0 +1,9 @@
+<code style="color: green">PASS</code>
+<canvas style="-webkit-user-modify: read-write"><span><input id="input"></input></span></canvas>
+<script>
+if (window.testRunner)
+    testRunner.dumpAsText();
+input.focus();
+input.remove();
+document.execCommand("ForwardDelete");
+</script>

Source/WebCore/ChangeLog

@@ -1,3 +1,27 @@
+2017-08-23  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        DeleteSelectionCommand should be robust when starting and ending editable positions cannot be found
+        https://bugs.webkit.org/show_bug.cgi?id=175914
+        <rdar://problem/29792688>
+
+        Reviewed by Ryosuke Niwa.
+
+        DeleteSelectionCommand can cause a null dereference if editable start and end positions are not found. This can
+        happen when attempting to delete after selecting the contents within a canvas or output element with `read-write`
+        `-webkit-user-modify` style. To fix this, we make the initialization step of the DeleteSelectionCommand robust
+        when editable start and end positions are missing.
+
+        Test: editing/execCommand/forward-delete-read-write-canvas.html
+
+        * editing/DeleteSelectionCommand.cpp:
+        (WebCore::DeleteSelectionCommand::initializePositionData):
+
+        Make this initialization helper indicate failure via a bool return value. DeleteSelectionCommand::doApply bails
+        early if initializePositionData returned false.
+
+        (WebCore::DeleteSelectionCommand::doApply):
+        * editing/DeleteSelectionCommand.h:
+
 2017-08-23  Alex Christensen  <achristensen@webkit.org>
 
         Stop using PolicyChecker for ContentPolicy

Source/WebCore/editing/DeleteSelectionCommand.cpp

@@ -172,7 +172,7 @@ void DeleteSelectionCommand::setStartingSelectionOnSmartDelete(const Position& s
     setStartingSelection(VisibleSelection(newBase, newExtent, startingSelection().isDirectional())); 
 }
 
-void DeleteSelectionCommand::initializePositionData()
+bool DeleteSelectionCommand::initializePositionData()
 {
     Position start, end;
     initializeStartEnd(start, end);
@@ -182,6 +182,9 @@ void DeleteSelectionCommand::initializePositionData()
     if (!isEditablePosition(end, ContentIsEditable))
         end = lastEditablePositionBeforePositionInRoot(end, highestEditableRoot(start));
 
+    if (start.isNull() || end.isNull())
+        return false;
+
     m_upstreamStart = start.upstream();
     m_downstreamStart = start.downstream();
     m_upstreamEnd = end.upstream();
@@ -272,6 +275,8 @@ void DeleteSelectionCommand::initializePositionData()
     // node.  This was done to match existing behavior, but it seems wrong.
     m_startBlock = enclosingNodeOfType(m_downstreamStart.parentAnchoredEquivalent(), &isBlock, CanCrossEditingBoundary);
     m_endBlock = enclosingNodeOfType(m_upstreamEnd.parentAnchoredEquivalent(), &isBlock, CanCrossEditingBoundary);
+
+    return true;
 }
 
 void DeleteSelectionCommand::saveTypingStyleState()
@@ -857,7 +862,8 @@ void DeleteSelectionCommand::doApply()
 
 
     // set up our state
-    initializePositionData();
+    if (!initializePositionData())
+        return;
 
     // Delete any text that may hinder our ability to fixup whitespace after the delete
     deleteInsignificantTextDownstream(m_trailingWhitespace);    

Source/WebCore/editing/DeleteSelectionCommand.h

@@ -54,7 +54,7 @@ class DeleteSelectionCommand : public CompositeEditCommand {
 
     void initializeStartEnd(Position&, Position&);
     void setStartingSelectionOnSmartDelete(const Position&, const Position&);
-    void initializePositionData();
+    bool initializePositionData();
     void saveTypingStyleState();
     void insertPlaceholderForAncestorBlockContent();
     bool handleSpecialCaseBRDelete();