[iOS, Android, WP] Fire editor#selectionChange on selection changes caused by touch events

[Piotrek Koszuliński]

Currently editor#selectionChange is based on:

• native selectionchange,
• keyboard events,
• mouse events.

Therefore, CKEditor does not know about selection changes done on touch devices if browser does not implement selectionchange itself. It may also happen that we have some bugs in this system.

Lack of editor#selectionChange and checkSelectionChange() calls result in various issues like wrong selection being locked on focus (we store a reference to the last selection) and lack of updates in commands states. I think that related tickets may be:

• #13522
• #13573
• #10180
• #13648
• #13659

[Olek Nowodziński]

The solution pushed to ​branch:t/13593. It fixes #13522 and #13573 straight away.

[Piotrek Koszuliński]

Unfortunately on iOS making a non-empty selection does not trigger selectionChange. I wonder if iOS fires any event when you modify the selection ;/

[Olek Nowodziński]

It looks like iOS fires selectionchange on document instead of editable. The additional listener fixes all selection issues in iOS, as well as in Android.

​branch:t/13593b

[Piotrek Koszuliński]

There's something wrong with this branch. I have one red test here ​http://tests.ckeditor.dev:1030/tests/core/editable/status (on Chrome and Edge at least). Plus, I think that there's some inf loop or something in some other tests as they crashed.

[Piotrek Koszuliński]

I've just checked that the selectionchange listener that we had isn't necessary at all as on every browser I checked the event is fired on document only. Well, the only reason that it must exist is that our code fires custom selectionchange event on editable once it changed the selection. So we can easily have two listeners and there will be no overlapping at all. Uuuunless... One day the selectionchange event will start to fire on the editing host as well but that should not happen:

When the selection is dissociated with its range, associated with a new range or the associated range's boundary point is mutated either by the user or the content script, the user agent must queue a task ([HTML5]) to fire an event with the name selectionchange, which does not bubble and is not cancelable, at the document associated with the selection.

source: ​http://w3c.github.io/selection-api/#selectionchange-event

[Piotrek Koszuliński]

Waiting for ​http://dev.ckeditor.com/ticket/13377#comment:17

[Olek Nowodziński]

Pushed experimental ​branch:t/13593c based on ​branch:zws. It looks like the new FC system solved the problem with loops (doc#selectionchange->remove FC from DOM->doc#selectionchange). It requires further testing and research though.

[Piotrek Koszuliński]

!! Thanks !!

[Olek Nowodziński]

Development of the new FC strategy can be tracked in #13816. Rebased ​branch:t/13593c on ​branch:t/13816.

[Marek Lewandowski]

Moving tickets to the next milestone.

[Marek Lewandowski]

We won't be able to contain it soon, moving to nice to have list.