IE : Automatically save the selection when loosing focus

[Frederico Caldeira Knabben]

IE is not able to manage multiple selection, even cross frame. Because of this, the current selection gets lost when leaving the editing area.

The current selection should be automatically saved when the editing area looses the focus in IE and then reselected when the focus is moved back to it.

By doing that, we can remove all selection hacks we are doing now for dialogs, floating panes, etc.

[Martin Kou]

I've fixed some coding mistakes in the dialog plugin, and also updated the patch to account for changes in [3316].

[Frederico Caldeira Knabben]

Martin, the new patch is ok for me... if you give it R+ I'll proceed on committing it.

[Garry Yao]

Some issues have been found after the patch is applied:

1. L513 and L670 of _source\plugins\dialog\plugin.js should dedicate to IE.
2. Certain plugins( e.g Link/Image/Form ) require the selection been restored within 'onOk', which fired even before 'onHide' event of dialog, so the selection range is still not correct for them, reproduce with:
   

Reproducing Procedures

1. Open the replace by class example page;
2. Select the word 'you';
3. Open 'image' dialog to insert a image;
   • Actual Result: The image has been inserted at the front.

[Frederico Caldeira Knabben]

This new patch makes the selection issues much more self contained, so we can completely avoid selection hacks elsewhere in the code, specially in dialog definitions.

[Garry Yao]

It's worthy to takes a long time to validate all those changes introduced by the new patch, it really eliminate all those previous hacks everywhere, so R+.
Though, I found the following minor issues:

1. It's not necessary to have L132 of _source\plugins\selection\plugin.js, since a saving will be fired by 'selectchange' event at the moment;
2. Within selectElement method L766, maybe the cached type should be 'CKEDITOR.SELECTION_ELEMENT' instead.
3. Within selectRanges method L813, we can't leave 'selectedElement' to null, otherwise later it will be retrieved from native selection, which is error prone, also the 'type' and 'startElement' is not accurately calculated.

[Garry Yao]

And another point, not sure if we can also utilize the selection locking system in focus/blur selection management for the same purpose, which means lock on 'blur' event and unlock on 'focusin' event instead of performing the save on every single action.

[Frederico Caldeira Knabben]

Fixed with [3329].

[Frederico Caldeira Knabben]

Replying to garry.yao:

1. It's not necessary to have L132 of _source\plugins\selection\plugin.js, since a saving will be fired by 'selectchange' event at the moment;

It's needed. I've found some cases where selectionchange don't get fired, or it's fired before the focus event, making the saving be missed.

1. Within selectElement method L766, maybe the cached type should be 'CKEDITOR.SELECTION_ELEMENT' instead.

Ok... I've thought about <span> elements and so on, but it makes sense to have the type as element. I've changed it when committing.

1. Within selectRanges method L813, we can't leave 'selectedElement' to null, otherwise later it will be retrieved from native selection, which is error prone.

No problem to use "null". The cache checking is done using "!== undefined", which is "true" for "null.

also the 'type' and 'startElement' is not accurately calculated.

Not a big issue for now. It would just make our code larger with not real benefits.

[Frederico Caldeira Knabben]

Replying to garry.yao:

And another point, not sure if we can also utilize the selection locking system in focus/blur selection management for the same purpose, which means lock on 'blur' event and unlock on 'focusin' event instead of performing the save on every single action.

That's was my very first try, which looked obvious and much simpler. But, our dear IE looses the selection before the blur event (or focusout) get fired (in some cases), so we can't save it. It took me two days to come out with the final solution.