Abnormal behavior when pasting /r/n into the contenteditable="plaintext-only" node
Reported by
vhp...@msn.com,
Sep 3
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Build a string: some normal characters with \r\n end, like this: 0x41 0x0d 0x0a 2. Select all the string, and paste it into a contenteditable="plaintext-only" node with no children 3. There will be an extra <div><br></div> appearing at the end of the editable node What is the expected behavior? What went wrong? I think the contenteditable="plaintext-only" node should NOT have child nodes other than the text node Did this work before? N/A Does this work in other browsers? N/A Chrome version: 68.0.3440.106 Channel: n/a OS Version: 10.0 Flash Version:
,
Sep 4
Unable to reproduce the issue on chrome reported version# 68.0.3440.106 using Windows-10 with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the '.html' file provided in comment# 0 2) Entered text "A" in the field and opened Devtools, in elements tab observed "<div>A</div>" @Reporter: Please find the attached screencast for your reference and provide your feedback on it which helps us in further triaging the issue in better way. Note: Tentatively adding Blink>Editing component to it. Thanks!
,
Sep 4
This is expected behavior. If you want to have newline characters in node, you need to have "white-space: pre" CSS property.
,
Sep 4
@ viswa.karala@chromium.org I recorded a GIF can reproduce the whole process, please check.
,
Sep 4
@ yosin@chromium.org After my test, even if "white-space: pre;" is set, this behavior will still occur. Please check the GIF of my last comment. "white-space: pre;" is not set in GIF, but you can follow my steps to reproduce it with "white-space: pre;".
,
Sep 4
The last <div><br></div>, aka placeholder <br>, is needed to represent newline. This is as same as <textarea>, which contents in UA shadow tree.
,
Sep 4
But why does the <div><br></div> appear only when \r\n is at the end of the pasted content? If \r\n is not at the end, after pasting, whole content will become an entire text node. The <div><br></div> will cause the continued input content to be entered into this sub <div> instead of the first-level-contenteditable-node.
,
Sep 4
I mean, after pasting, A\r\n ↑ will become ↓ ["A "<div><br></div>] but, A\r\nB ↑ will become ↓ ["A B"] ([ ] represents children of the contenteditable node, " " represents a text node) You can see, in first case, the text node already has an internal newline, so <div><br></div> is redundant. |
|||
►
Sign in to add a comment |
|||
Comment 1 by phanindra.mandapaka@chromium.org
, Sep 4