Non-editable widgets can be edited in IE

[pollyfahey]

Steps to reproduce

1. Add custom table widget as attached.
2. In editor add table.
3. Click on the bottom border of the widget and type.

Expected result

The text should be added underneath the widget.

Actual result

The text is added in the widget.

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

Observed in IE 11. Using CKEditor 4.5.3. Windows 10.

[Jakub Ś]

Attached corrected version of the plugin.

[Jakub Ś]

Screen cast showing the problem

[Marek Lewandowski]

We won't be able to contain it within 4.6.1 - moving to next major release.

[Tade0]

I noticed that after creating that widget and adding the attribute contenteditable="false" to some of its elements it's still possible to edit them.

[Tade0]

Given that what is happening here is something, that should be impossible I went with a solution that covers this specific case.

Changes pushed to ​branch:t/14407.

[Tomasz Jakut]

Test is not working at all – it seems that it tries to load nonexistent plugins. After removing these imports, there is no way to add widget into editable. Apart from that test could be moved into tests/plugins/widget.

After dealing with the test I noticed that I still could insert something into noneditable widget:

1. Move into the widget using Up Arrow.
2. Immediately after moving into it, press any character key.

The letter appears at the beginning of the widget.

[Tade0]

Apparently in this case IE11 in Windows 7 behaves differently than IE11 in Windows 10.

[Tade0]

There's one solution, but it isn't pretty:

For now, a selection check is done on keyup with a timeout(cited reason was performance, but that was in 2011, so it probably doesn't apply now). Adding the same check on keydown solves this particular problem, but breaks several tests.

Currently trying to determine why does it do that and is it significant enough to justify not going with this solution.

[Tade0]

Improving the selection check so that it doesn't touch nested editables within non-editable elements solved most of the problems, but there still remain tests that report an Unspecified error, which is troubling.

[Tade0]

In hindsight it wasn't a good idea to do manipulate the selection in the selection change handler - not that it didn't work.

Apparently in order not to break e.g. link handling in read-only elements it's better not to do that.

As a last resort measure I'm letting the user place the caret inside the non-editable element, but once a key is pressed the event gets prevented and the whole element is selected.

I put the unit tests in core/selection, because the change applies not only to widgets, but also any other read-only elements. Also, the changes were made in core/selection.js only.

Changes pushed to ​branch:t/14407.

[Tomasz Jakut]

Still not working correctly:

1. Open manual test.
2. Create widget after the paragraph.
3. Select some text in the widget (place cursor slightly below the widget and start selecting; ensure that widget is not focused).
4. Press Backspace.

The selected text in non-editable area is deleted. In the same way it's possible to type a single letter

[Tade0]

Verifying also non-collapsed ranges, updated manual test.

Changes pushed to ​branch:t/14407.

[Tomasz Jakut]

The issue described in ​comment is reproducible also in IE8 and IE9 (strangely I didn't manage to reproduce it in IE10). What's more, unit tests for this ticket are failing in all IEs but IE11.

[Tade0]

Apparently it's not possible to create such a selection in the unit tests in IE's other than 11 - the selection is changed automatically.

Nevertheless all that was required to make this work on other IE's was to change the browser detection check accordingly.

[Tomasz Jakut]

Now LGTM. Merged with ​git:a3b2b66.