ID attributes removed on drag and drop and copy and paste

[Piotr Jasiun]

After changes introduced in #13042 id attributes are removed on drag and drop and copy and paste block widgets. They seems to be generally removed during these operations and they should not, so anchors may work fine.

This is most probably because getHtmlFromRange and extractHtmlFromRange do this.

[Piotr Jasiun]

I restored IDs in tests removed in #13042 and pushed it to ​t/13128.

[Olek Nowodziński]

​branch:t/13128

It was too easy. But worth a shot.

[Piotrek Koszuliński]

One question - did you consciously avoid cloning ids of a partially selected elements? Did you compare this behaviour with the native cloneContents()?

[Piotrek Koszuliński]

To make sure that one day I'll get an answer to the above question - R- :P

[Olek Nowodziński]

Replying to Reinmar:

One question - did you consciously avoid cloning ids of a partially selected elements? Did you compare this behaviour with the native cloneContents()?

Nice catch.

For the following ranges

<p>[xxx<b id="y">abc</b>zzz]</p>
<p>xxx<b id="y">ab[c</b>zzz]</p>

native range.cloneContents() returns the following docFragments in Chrome, FF and IE11

xxx<b id="y">abc</b>zzz
<b id="y">c</b>zzz

which means that ids of partially selected elements are preserved. And this is the right thing to do, I believe.

I pushed a test for such a case to ​branch:t/13128. Focusing on the fix at the moment.

[Olek Nowodziński]

Let's see what it's worth: ​branch:t/13128d.

[Piotrek Koszuliński]

I made some small docs and tests improvements and merged the branch to major with ​git:0514f02.

Note - do not alter too many existing tests in cases like this one without adding a separate TC for the issue. For example, in range/* the changes were ok, because you changed existing tests and added new ones. But in widgets you only modified existing tests. So it may be unclear in the future that this small ids were meant to check something.