Tested the issue on Windows 7 & 10 using M58 #58.0.3029.110 and followed below steps :

1. Launched chrome and opened test.html
2. Opened elements tab in dev tools and selected the "test 2 " line and cut the text and undo it ctrl+z
3. reloaded the page and repeated the text cut and entered new line from test 3 line and copied the text .

Attached screencast for reference.

@thdoan-- Could you please check attached screencast and confirm us if this is the issue you are talking about , as i couldn't reproduce the same as your provided video. Also please check updating  your chrome to latest stable and update your observations.

Thanks!

Deleted: 721826.mp4 1.0 MB

	721826.mp4 1.0 MB View Download

@hdodda you are missing step 2: View the Elements tab in Developer Tools. Everything looks OK on the front end -- the issue is that the DOM does not reflect the changes that you make.

This may not seem like a big issue, but when you have JavaScript code that reads from the DOM as you make changes to contentEditable elements, it is a very big issue.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on windows 7,Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110 with the below steps

1. Open test.html and open dev tools.
2. Select the entire "test 2" line and cut it (Ctrl+X).Press Ctrl+Z to undo
3. Press F5 to reload the page and Repeat step 3
4. Add a new line below "test 3" by putting the cursor to the right of "3" and pressing Enter
5. Paste what you cut in step 6 ("test 2")

Observed - After step 7, the newly inserted <li> is supposed to have no id attribute, but instead it is assigned id="t2", which is already assigned to the previous <li>.

This is non regression issue as the issue seen from M30 old builds.Marking it as Untriaged to get more inputs from dev team.
Note:: Observed the same behaviour on Firefox as well.

Thanks,

@kavvaru note that the three issues I listed are probably non-conclusive, meaning there could be other issues related to editing child elements (e.g.,
 <li>, <dt>, etc.) inside a contentEditable block container (e.g., <ol>, <ul>, <dl>).

I would like to emphasize that the text editing/cutting/pasting in the presentation layer is fine -- the crux of the problem is that the underlying DOM is not updated to reflect the changes, which can break JavaScript code that works off contentEditable elements.

Thanks for the report, I'm able to reproduce all 3 issues you listed.

> - After step 3, the id for "test 3" changed from 't3' to 't2'.
I couldn't find info in the spec about how to resolve elements when cutting/pasting.  Here, DevTools seems to output the value from Blink, so I'll defer to someone on the editing team for addressing this.  Is it intended that cutting may result in moving textContent from one element to another?

> - After step 4, the third <li> ("test 3") becomes empty.
This looks like a DevTools bug, Elements panel becomes inconsistent after undoing a 'cut' operation.  I'd like to make this a separate crbug.   https://crbug.com/722923 

> - After step 7, the newly inserted <li> is supposed to have no id attribute, but instead it is assigned id="t2"
It looks like copying text from contentEditable area also copies attributes including 'id' in the clipboard.  @editing team, is this intended?

@luoe thanks for looking into this.

> Did this work before? N/A

Actually, this is incorrect. The only reason I noticed there was an issue is because I have a Chrome extension that relies on a contentEditable <ul> to manage some labels. It was working as early as 2011, but somewhere along the way it stopped working. If you test this in a version of Chrome that was released circa 2011-2012, I suspect you will not be able to reproduce the issues (or at least all of the issues).

In fact, I will install a portable version of Manifest 1.0 Chrome to re-test this and report back later.

UPDATE: I just tested this in Chromium 18 and was able to reproduce all three cases (even worse, after pasting in step 8 the "test 2" line was pasted inside a nested <ul>), so never mind, it appears these issues have always been present.

We can narrow this down to two separate issues:

1. DevTools not updating Elements console after an undo action (per comment #7)

2. Blink is copying attributes when an element is removed or added. Here is what I observed (you can play around with test2.html):

a) When an element is removed, its attributes are copied over to the next sibling.

b) When a new elemnt is added, it inherits attributes from its previous sibling.

I'm not sure whether this is an issue with the spec or Blink's implmentation of the spec.

Deleted: test2.html 651 bytes

test2.html 651 bytes View Download

Copy and Paste work as expected, Blink copies "id" attribute even if there are
elements having same "id". Note: HTML5 spec allows elements have same "id". You
can retrieves document.querySelectorAll('#some-id').

@yosin according to the latest published HTML5 spec:

"The id attribute specifies its element's unique identifier (ID). The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character."

"home subtree" in the context of a web page is Document.

Source: https://www.w3.org/TR/html5/dom.html#the-id-attribute

You may technically retrieve elements with the same id using document.querySelectorAll(), but it goes against the official HTML5 spec.

Since the separate bug was filed for the DevTools related issue, I'm removing the label, and updating the title to the original intent.

This title would more accurately describe the issue: Attributes are copied when adding & removing contentEditable child elements.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot