[Blink/Webkit] Span elements created while joining adjacent elements (non-collapsed selection)

[Olek Nowodziński]

This ticket corresponds with #11861 but for non-collapsed selections and belongs to #9998 "family".

Example 1

1. Set data

   <div>
     <p>fo[o</p>
   </div>
   
   <div>
     <p>b]ar</p>
   </div>
   

2. BACKSPACE
3. Result:

   <div>
     <p>fo<span style="line-height:1.6">^ar</span></p>
   </div>
   

4. Expected

   <div>
     <p>fo^ar</p>
   </div>
   

[Piotrek Koszuliński]

cc

[Olek Nowodziński]

Pushed fix to ​branch:t/11980 (+tests).

It brings support for most of the cases except tables, which, due to problems with range.deleteContents(), cannot be handled yet. I don't think it's a real issue though because users usually don't create selections anchored in two tables, paragraph and a table etc.

This branch also brings some major refactoring and code clean-up to existing delbackspacequirks tests.

[Piotrek Koszuliński]

I pushed additional commits which refactored the dev code. That by mistake fixed behaviour of the implementation which started correctly placing selection at boundaries of inline elements. It's also related to #11999. Basically, the selection at inline element boundary is being incorrectly normalised by Webkit and is not by Blink any more.

I also noticed one thing - some tests are wrong, because on Blink/Webkit it's not possible to manually place caret at beginning of inline element (<strong>^foo</strong>) but it's possible to place it at the end: <strong>bar^</strong>.

Perhaps this is the reason why some tests fails on old Blink and Webkit - because they place selection at the beginning of inline elements and only new Blink retain this position. Other engines normalize position and hence final position is different too.

So I think that we could ignore these tests. At some point Webkit will be fixed too, but for now we're testing unrealistic case just for sake of validating the implementation.

[Olek Nowodziński]

I added failing tests to regressions.js. As for Opera, we might accept failures because it will get updated soon to the same engine as Chrome 35 (hopefully).

[Olek Nowodziński]

​git:a0510b6 landed in master (de1da25 tests).