Check RTL support

[Reinmar]

We should check how engine and existing features work with RTL content.

[Reinmar]

1. Open any sample.
2. Change language to Arabic.
3. Press 'a' multiple times.
4. Shift+left.

As you can see the range boundaries are reversed when printed on the console. It must be checked whether they really are reversed in the DOM.

But I'm afraid they are, because if you press Ctrl+B, then:

[Reinmar]

Note: The above can only be reproduced in Chrome and Safari. In Firefox you get:

However, when I copied the console output here, I got:

<heading1>شششش[]</heading1>
<heading1>ششش[ش]</heading1>
<heading1>شششش[]</heading1>
<heading1>ششش[<$text bold="true">ش</$text>]</heading1>

[Reinmar]

Contiguous DOM selection, non-contiguous box.

[fredck]

A good way to test it is comparing the behavior we have in our implementation with the one in the native contenteditable.

[Reinmar]

This is weird:

[Reinmar]

OK, it works as expected if the editable has dir=rtl. Previously, I wrapped the whole editor in div[dir=rtl] but, apparently, it must be the editable which has the attr.

[fredck]

Remember that we must, additionally, checked "mixed direction" in the content, like an Arabic word or phrase inside English content. Such content may appear within a <span dir="rtl"> element but also without any element around it.

[Reinmar]

I created a manual test in which you can compare, and eventually debug, RTL support issues.

The most important thing I understood is that if you have a mixed content (RTL text next to LTR or RTL text in LTR container), then really weird things happen. Fortunately, it's exactly the same behaviour which you get in native contenteditable. Browsers also tend to differ between themselves in such cases.

So, I consider this done and everything is working fine (tested in Chrome and Firefox).

Tests were added in ckeditor/ckeditor5-typing@64ad8c1

[Reinmar]

Remember that we must, additionally, checked "mixed direction" in the content, like an Arabic word or phrase inside English content. Such content may appear within a element but also without any element around it.

I tested mixed content without those spans. I don't think that something could be wrong with spans, because it's browser who renders that mess and moves the selection. In the DOM everything is in the right order – range end is always after range start in DOM order. E.g. this works nice, even though visually the range is discontiguous:

[aliqasemzadeh]

Hello,
I think having RTL support is so easy.
Just don't add dir=ltr when replace editor.