Changeset 211471 in webkit

Timestamp:

Jan 31, 2017 11:46:31 PM (7 years ago)

Author:

Wenson Hsieh

Message:

Regression (Safari 10.1): Pressing Return in a contenteditable no longer inserts a line break under certain conditions
​https://bugs.webkit.org/show_bug.cgi?id=167525
<rdar://problem/30270210>

Reviewed by Ryosuke Niwa.

Source/WebCore:

Test: fast/events/input-events-insert-newlines-after-mutation.html

Reverts an unintended change made while refactoring code for input events that caused input events to be
dispatched immediately rather than on the scoped queue. Normally, input events are dispatched in
CompositeEditCommand::apply after the end of the scope, but TypingCommands may fire input events *from within*
the scope by calling typingAddedToOpenCommand.

Instead, TypingCommands should always dispatch events
synchronously after the end of the scoped queue in CompositeEditCommand::apply, but this is a riskier change
than we should currently allow, so we should revert to our old behavior for the time being.

• editing/Editor.cpp:

LayoutTests:

Adds a new test covering newline insertion with mutation observers and an input event handler. Also rebaselines
a drag and drop test to account for dispatching input events on the scoped queue.

• fast/events/input-events-drag-and-drop-expected.txt:
• fast/events/input-events-insert-newlines-after-mutation-expected.txt: Added.
• fast/events/input-events-insert-newlines-after-mutation.html: Added.
• platform/ios-simulator/TestExpectations:

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/fast/events/input-events-drag-and-drop-expected.txt (modified) (1 diff)
• LayoutTests/fast/events/input-events-insert-newlines-after-mutation-expected.txt (added)
• LayoutTests/fast/events/input-events-insert-newlines-after-mutation.html (added)
• LayoutTests/platform/ios-simulator/TestExpectations (modified) (1 diff)
• Source/WebCore/ChangeLog (modified) (1 diff)
• Source/WebCore/editing/Editor.cpp (modified) (1 diff)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2017-01-31  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        Regression (Safari 10.1): Pressing Return in a contenteditable no longer inserts a line break under certain conditions
+        https://bugs.webkit.org/show_bug.cgi?id=167525
+        <rdar://problem/30270210>
+
+        Reviewed by Ryosuke Niwa.
+
+        Adds a new test covering newline insertion with mutation observers and an input event handler. Also rebaselines
+        a drag and drop test to account for dispatching input events on the scoped queue.
+
+        * fast/events/input-events-drag-and-drop-expected.txt:
+        * fast/events/input-events-insert-newlines-after-mutation-expected.txt: Added.
+        * fast/events/input-events-insert-newlines-after-mutation.html: Added.
+        * platform/ios-simulator/TestExpectations:
+
 2017-01-31  Ryan Haddad  <ryanhaddad@apple.com>
 

trunk/LayoutTests/fast/events/input-events-drag-and-drop-expected.txt

@@ -4 +4 @@
 Performing drag and drop
 (source): type=beforeinput, inputType=deleteByDrag, data=`null`
+(destination): type=beforeinput, inputType=insertFromDrop, data=`Input events!`
 (source): type=input, inputType=deleteByDrag, data=`null`
-(destination): type=beforeinput, inputType=insertFromDrop, data=`Input events!`
 (destination): type=input, inputType=insertFromDrop, data=`Input events!`
 

trunk/LayoutTests/platform/ios-simulator/TestExpectations

@@ -1234 +1234 @@
 fast/events/input-events-spell-checking-datatransfer.html [ Failure ]
 fast/events/input-events-selection-forecolor-data.html [ Failure ]
+fast/events/input-events-insert-newlines-after-mutation.html [ Failure ]
 fast/events/before-input-events-prevent-default.html [ Failure ]
 fast/events/before-input-events-prevent-default-in-textfield.html [ Failure ]

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2017-01-31  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        Regression (Safari 10.1): Pressing Return in a contenteditable no longer inserts a line break under certain conditions
+        https://bugs.webkit.org/show_bug.cgi?id=167525
+        <rdar://problem/30270210>
+
+        Reviewed by Ryosuke Niwa.
+
+        Test: fast/events/input-events-insert-newlines-after-mutation.html
+
+        Reverts an unintended change made while refactoring code for input events that caused input events to be
+        dispatched immediately rather than on the scoped queue. Normally, input events are dispatched in
+        CompositeEditCommand::apply after the end of the scope, but TypingCommands may fire input events *from within*
+        the scope by calling typingAddedToOpenCommand.
+
+        Instead, TypingCommands should always dispatch events
+        synchronously after the end of the scoped queue in CompositeEditCommand::apply, but this is a riskier change
+        than we should currently allow, so we should revert to our old behavior for the time being.
+
+        * editing/Editor.cpp:
+
 2017-01-31  Zalan Bujtas  <zalan@apple.com>
 

trunk/Source/WebCore/editing/Editor.cpp

@@ -118 +118 @@
 {
     auto* settings = element.document().settings();
-    if (settings && settings->inputEventsEnabled())
-        element.dispatchEvent(InputEvent::create(eventNames().inputEvent, inputType, true, false, element.document().defaultView(), data, WTFMove(dataTransfer), targetRanges, 0));
-    else
+    if (settings && settings->inputEventsEnabled()) {
+        // FIXME: We should not be dispatching to the scoped queue here. Normally, input events are dispatched in CompositeEditCommand::apply after the end of the scope,
+        // but TypingCommands are special in that existing TypingCommands that are applied again fire input events *from within* the scope by calling typingAddedToOpenCommand.
+        // Instead, TypingCommands should always dispatch events synchronously after the end of the scoped queue in CompositeEditCommand::apply. To work around this for the
+        // time being, just revert back to calling dispatchScopedEvent.
+        element.dispatchScopedEvent(InputEvent::create(eventNames().inputEvent, inputType, true, false, element.document().defaultView(), data, WTFMove(dataTransfer), targetRanges, 0));
+    } else
         element.dispatchInputEvent();
 }