[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
https://bugs.webkit.org/show_bug.cgi?id=167525
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