Text deleted in contenteditable="true" element on drag and drop
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: neil.ashford, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15
Steps to reproduce:
- Navigate to https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content and scroll to the live demo (under the text "Here's the above HTML in action:"
- Place the cursor at the very end of the text inside the editable div (after the whitespace)
- Press enter to create a new blank line after the text
- Place the cursor at the beginning of the word "user" on the first line
- Make a selection by pressing the down arrow key while holding shift
- Drag that selection to immediately before the word "by" on that same line and drop it
Actual results:
The blank line, and the content from inside the selection "user. ", was deleted. The cursor was left at the end of the line, where that content used to be.
Expected results:
The selected content ("user. " and a blank line) should be pasted before the word "by", and the cursor should be right before the word by (where the cursor was when the dragged text was dropped).
|
||
Updated•5 years ago
|
|
|
||
Comment 1•5 years ago
|
||
Hello masayuki and Edgar,
I can reproduce the symptom.
Could you take a look?
The problem only happens when we select the word with new line.
So the step 3 is important.
Press enter to create a new blank line after the text
|
||
Comment 2•5 years ago
|
||
I tried to search if there is any existing bug for this, but no luck.
Sorry, I am not familiar with Editor enough, could not give more input.
When typing Enter after ASCII white-space causes inserting invisible <br> element for making sure the white-space is rendered. Then, selecting the content to next line (#5) moves selection end to the new <div> element, so, the selection will contain the <br> element. Then, dragging and dropping the selection also moves the new <div> element too and the new <div> will have 2 <br> elements, and the <div> becomes a child of first <div>, rather than next sibling of the first <div>.
I think that there are 2 odd points:
- Moving
<div>element is odd. - Perhaps, invisible
<br>element in selection is treated as visible<br>element.
Honestly, I have no idea why the #1 happens, but the latter sounds like a bug of serializer.
Mirko, you're rewriting the inserting HTML code and serializer, do you have any idea? (Perhaps, we should stop inserting <br> element for web-compat, but anyway, this kind of issue may happen with content generated by web apps.)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #3)
When typing Enter after ASCII white-space causes inserting invisible
<br>element for making sure the white-space is rendered. Then, selecting the content to next line (#5) moves selection end to the new<div>element, so, the selection will contain the<br>element. Then, dragging and dropping the selection also moves the new<div>element too and the new<div>will have 2<br>elements, and the<div>becomes a child of first<div>, rather than next sibling of the first<div>.I think that there are 2 odd points:
- Moving
<div>element is odd.- Perhaps, invisible
<br>element in selection is treated as visible<br>element.Honestly, I have no idea why the #1 happens, but the latter sounds like a bug of serializer.
Mirko, you're rewriting the inserting HTML code and serializer, do you have any idea? (Perhaps, we should stop inserting
<br>element for web-compat, but anyway, this kind of issue may happen with content generated by web apps.)
I have thought about this and experimented with the example. The trailing whitespace is already confusing and Chrome behaves differently when copy-pasting it: it doesn't contain it. Moreover, Firefox's behavior is inconsistent, when typing "X" after the trailing whitespace, the whitespace is replaced with "X". Also, in devtool's inspector, the initial trailing whitespace is invisible. Is that behavior intended? I think this should be clarified and potentially be fixed first, before fixing the more complex scenario.
Moreover, Firefox's behavior is inconsistent, when typing "X" after the trailing whitespace, the whitespace is replaced with "X".
Editor module assumes that if text in block element ends with an ASCII white-space which should be visible, <br> element must follows it. Therefore, our editor is confused with generated HTML by web apps which have invisible leading or trailing white-spaces in block elements. On the other hand, Blink inserts without <br> element. This is much simpler solution and makes sense, but changing this behavior might require Blink-compat white-space normalizer because existing normalizer works various timings and that causes we change the behavior harder. So, we cannot change this behavior so soon.
Also, in devtool's inspector, the initial trailing whitespace is invisible. Is that behavior intended?
In this case, it's unexpected case to me that the ASCII white-space at the end of the <div> element in content is rendered. It looks like \n or \r\n. I don't remember this is right behavior or not...
emilio:
I have a question about white-space handling of CSS.
https://mdn.mozillademos.org/en-US/docs/Web/Guide/HTML/Editable_content$samples/How_does_it_work?revision=1609514
In this case, only \n appears between the last visible character and </div>. It's rendered by Gecko, but not rendered (i.e., removed) by Blink. According to the spec, Gecko's result is confirmed to the spec, but I'm 100% not sure. Which is the expected behavior?
|
||
Comment 7•5 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #6)
I have a question about white-space handling of CSS.
https://mdn.mozillademos.org/en-US/docs/Web/Guide/HTML/Editable_content$samples/How_does_it_work?revision=1609514
In this case, only\nappears between the last visible character and</div>. It's rendered by Gecko, but not rendered (i.e., removed) by Blink. According to the spec, Gecko's result is confirmed to the spec, but I'm 100% not sure. Which is the expected behavior?
I think we're on the wrong. I think that newline should be removed via step 3 in https://drafts.csswg.org/css-text-3/#white-space-phase-2
|
||
Updated•5 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 8•3 years ago
|
||
The severity field for this bug is set to S3. However, this bug has a P1 WebCompat priority.
:hsinyi, could you consider increasing the severity of this web compatibility bug?
For more information, please visit auto_nag documentation.
|
||
Comment 9•3 years ago
|
||
Per Masayuki, this depends on bug 1658699, which is a big change.
There are no web apps breakages linked in see-also. We're also interested in data about usage of DnD support in editing.
Dennis , are you the right person to ask for more rationales about the webcompat P1 for this bug? Is this still the right rating? Thank you.
|
||
Comment 10•3 years ago
|
||
I can't find any relation of this bug to actual site breakage. It's not mentioned in any web-bug, and it has no relevant see-also's. Based on that, let's unset the WebCompat Priority flag for now - we can always come back later.
Well, this is still reproducible if you drop text ending with collapsible white-space. The pasting handler does not normalize the white-spaces at end of dropping text.
Hmm, but this might contain a complicated issue. If you drag following text, you want to preserve the white-spaces:
<p>abc[ def ]ghi</p>
However, if you drag following text, you must not want to preserve the white-spaces before of they are invisible, but DOM Selection contains them:
<p>[ abc ]</p>
Although I don't know how the past/drop handler receives the HTML fragment, in the worst case, we'd meet this case:
<style>
span {
display: block;
}
</style>
<p>abc<span>[ def ]</span>ghi</p>
So, the coming data may not contain the <span> is a block.
Description
•