[Webkit-unassigned] [Bug 167525] New: Regression: Pressing Return in a contenteditable no longer inserts a line break under certain conditions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 27 12:53:36 PST 2017


            Bug ID: 167525
           Summary: Regression: Pressing Return in a contenteditable no
                    longer inserts a line break under certain conditions
    Classification: Unclassified
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Macintosh
                OS: macOS 10.12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: HTML Editing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sstephenson at gmail.com

Created attachment 299951
  --> https://bugs.webkit.org/attachment.cgi?id=299951&action=review
Minimal test case

Pressing the Return key in a contenteditable element no longer inserts a line break under the following conditions:

1) A mutation observer is observing subtree changes to the editor element and synchronously replacing the contents of the editor element in response.

2) An input event listener is installed anywhere on the page*.

3) The window's selection | is collapsed ahead of two line breaks, in the following configuration: <div>|<br></div><div><br></div>

This behavior is new in Safari 10.1/Safari Technology Preview, and is not present in other major browsers, including older versions of Safari.

Attached please find a minimal test case (contenteditable-return.html). Use the following steps to reproduce the issue:

1) Open the test case file. The element outlined in red is a contenteditable element. Observe that the contents of the editor are a <div> with a single <br> inside. The editor has focus and the window's selection is collapsed just before the <br>.

2) Press Return. Observe that the editor grows by one line in height, as expected. The contents of the editor are now <div><br></div><div><br></div>. The script on the page restores the cursor to its previous position, before the first <br>.

3) Press Return again. Observe that the editor, unexpectedly, does not grow in height. The contents of the editor are unchanged.

The test case is a simplified representation of the mechanics of the Trix rich text editor (https://github.com/basecamp/trix), which monitors mutations and input events to update an internal document model, and then renders that model back to the contenteditable element as it changes.

* Note that on at least one computer, I am able to reproduce the issue without an input event listener installed. That it is sensitive to the timing of different computers seems to suggest a race condition. I speculate that presence of an input event listener causes WebKit to do additional work on the JS thread that it wouldn't otherwise do, triggering the symptoms above.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170127/a8160822/attachment.html>

More information about the webkit-unassigned mailing list