selectionChange isn't fired when mouse selection finished outside editable

[Piotrek Koszuliński]

Extracted from #9699.

1. Focus editor.
2. Check that selection is collapsed so cut/copy buttons are disabled.
3. Start selection by dragging. Release mouse button outside editable. Check releasing mouse button over document, outside of it, outside body, but in html.
4. Check cut/copy buttons state.

• Expected: when selection changed from collapsed to not collapsed, then selectionChange should be fired and those buttons should change state.
• Actual: in many cases they stay disabled.

Reproducible on Webkits, Opera, FF. After #9699 some cases may be fixed - usually those target by that patch. But even when issue from #9699 was fixed, I was sometimes able to reproduce this one.

[Piotrek Koszuliński]

Most likely on #9699 this issue is reproducible only when elements path hasn't been modified by the selection change. So to reproduce it select the same paragraph in which you placed caret in step 1.

[Piotrek Koszuliński]

Perhaps related issue #9767.

[Jakub Ś]

I was able to reproduce this in all browsers from CKEditor 3.5.1 (when cut and copy buttons started reflected selection).

[Olek Nowodziński]

Created a fix for the issue in ​t/9851@cksource that consists of two separate commits:

• Fixed clipboard mouseup listener to handle out-of-editable cases when selection goes out of editable.
• Fixed selection system to fire selectionChange event if selection process ends out of editable.

[Olek Nowodziński]

Fixed issue with ​git:b862b5f2dff723.

[Olek Nowodziński]

​​git:b862b5f2dff723 changeset breaks clipboard behavior for divarea:

1. Open divarea sample.
2. Watch cut & copy buttons on the toolbar.
3. Click somewhere outside of the editor.
4. Cut & copy are enabled as if something was selected in the editor.

This is because checkSelectionChangeTimeout is now called when clicking the outer document. Cannot reproduce in framed editor.

[Olek Nowodziński]

Created branch ​t/9851b@cksource with clipboard fix. Apparently, selection type should be determined by calling editor.getSelection().getType().

[Olek Nowodziński]

Fixed with ​git:bcb07200a76f6b