Opened 10 years ago

Closed 10 years ago

#11980 closed Bug (fixed)

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

Reported by: Olek Nowodziński Owned by: Olek Nowodziński
Priority: Normal Milestone: CKEditor 4.4.2
Component: General Version: 3.0
Keywords: Webkit Blink Cc:


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

Example 1

  1. Set data
  3. Result:
      <p>fo<span style="line-height:1.6">^ar</span></p>
  4. Expected

Change History (7)

comment:1 Changed 10 years ago by Olek Nowodziński

Owner: set to Olek Nowodziński
Status: newassigned

comment:2 Changed 10 years ago by Piotrek Koszuliński


comment:3 Changed 10 years ago by Olek Nowodziński

Status: assignedreview

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.

comment:4 Changed 10 years ago by Piotrek Koszuliński

Status: reviewreview_failed

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.

comment:5 Changed 10 years ago by Olek Nowodziński

Status: review_failedreview

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).

comment:6 Changed 10 years ago by Piotrek Koszuliński

Status: reviewreview_passed

comment:7 Changed 10 years ago by Olek Nowodziński

Resolution: fixed
Status: review_passedclosed

git:a0510b6 landed in master (de1da25 tests).

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy