[Webkit/Blink] Exception thrown on refocusing blurred inline editor

[Jakub Ś]

Steps to reproduce

1. Open div area sample.
2. Clear up the editor content.
3. Put the selection inside the editor.
4. Select "Marker" style from a styles dropdown and type some text.
5. Blur the editor (by clicking outside of the editor).
6. Click on styles button.
7. Blur the editor (by clicking outside of the editor).
8. Click on styles button.

Expected result

No JS error is thrown

Actual result

JS error is thrown:

Uncaught DOMException: Failed to execute 'setStart' on 'Range': The offset 13 is larger than or equal to the node's length (6).

Other details (browser, OS, CKEditor version, installed plugins)

[Jakub Ś]

Please also see the video showing the issue.

[Marek Lewandowski]

It does not necessarily require you to change tabs. Here'se a simplified TC:

1. Open div area sample.
2. Clear up the editor content.
3. Put the selection inside the editor.
4. Select "Marker" style from a styles dropdown.
5. Blur the editor (by clicking outside of the editor).
6. Click on styles button and apply "Big" style.

Edit: Above is no longer reproducible on 4.7.0.

[Piotrek Koszuliński]

The error is thrown when unlocking a selection. The locked one has much higher offsets than the number of typed letters which means that it's a problem with the filling chars. The selection is locked in a DOM with a filling chars, but when it's unlocked, there are no filling chars.

I'm curious how the filling chars behave in other cases. First of all, it's obvious that all this works fine in an iframed editor because there's no selection locking as iframe can keep its own selection. But can we find some cases with inline editables in which unlocking selection works if the selection had filling chars upon lock?

[kkrzton]

Replying to Reinmar:

The error is thrown when unlocking a selection. The locked one has much higher offsets than the number of typed letters which means that it's a problem with the filling chars. The selection is locked in a DOM with a filling chars, but when it's unlocked, there are no filling chars.

It looks like the filling char sequence is removed on editor refocus. The selectionChange event is fired after refocusing and it starts the process of checking and removing filling chars (​https://github.com/ckeditor/ckeditor-dev/blob/master/core/selection.js#L859).

[Piotrek Koszuliński]

Any idea how it works in e.g. tab, and then shift+tab case that it doesn't throw? How is this case different from other ones?

[kkrzton]

I'm still looking into where is the difference between refocusing with tab/shift+tab and mouse (via dropdown). It works well with tab/shift+tab and also when focusing toolbar (alt+F10) and applying "Big" style using keyboard.

The one strange case is when focusing toolbar (alt+F10) and then using left/right arrows. It should switch between buttons in a toolbar group but instead, focus is set back in the editable area and the above exception is thrown (it happens only in the case which will throw this error ofc).

[kkrzton]

It can also be reproduced following the steps:

1. Open div area sample.
2. Clear up the editor content.
3. Put the selection inside the editor.
4. Select "Marker" style from a styles dropdown and type some text.
5. Blur the editor (by clicking outside of the editor).
6. Click on styles button.
7. Blur the editor (by clicking outside of the editor).
8. Click on styles button.

It seems like at the first refocus (step 6), removeFillingCharSequenceNode method (which removes filling chars) runs without any error and ranges cache is updated with the proper range. However, after refocusing for the second time (step 8), selection unlocking uses the previous range (with offset involving filling char sequence).

[Tade0]

While checking one solution to this bug I found another one, that's not related by code, but definitely related from the user's perspective: ​http://dev.ckeditor.com/ticket/16895#ticket

[Tade0]

Cherry-picked the changes made by k.krzton on top of major, updated tags.

Changes pushed to ​branch:t/14714.

[Tade0]

Added unit tests.

Changes pushed to ​branch:t/14714.

[Marek Lewandowski]

Unit tests are ​failing.

[Marek Lewandowski]

I'll take over this issue.

[Marek Lewandowski]

Tests fixed with ​git:60b4261ae0.

[Marek Lewandowski]

Changed reproduce steps in the summary - the former involved some redundant steps. Adding original TC below:

Steps to reproduce

1. Open two tabs in Chrome or Opera
2. Open divarea sample and clear editor contents.
3. Type text, select Big from styles dropdown, type more text, select Small and type more text
4. Click on another tab, click on tab with editor and select e.g. Typewriter style from dropdown.

Expected result

No JS error is thrown

Actual result

Code: selection.js 
Line: 1921 
Message: Uncaught IndexSizeError: Failed to execute 'setStart' on 'Range': The offset 22 is larger than or equal to the node's length (15).

Code: style.js
Line: 331 
Message: Uncaught TypeError: Cannot read property 'elements' of null

[Marek Lewandowski]

Fixed with ​git:e0e0043f5c.