SelectionChange not firing in all instances

[Lynne Kues]

Run the attached code example. Click to put the cursor at beginning of first line - event fired. Now drag select within the same line - event NOT fired. Now drag select within the second line - event fired.

[Garry Yao]

Confirm only in non-IEs, the 'selectionChange' event is a bit lazy in other browsers than in IE, actually it should NOT be understood as 'selection range changed' but instead as 'anchor element changed', in short it will only fire when the anchor element of the selection changes.

Leave this ticket open for discussion on whether we should offer a more active 'selection change' event as the one IE natively provides.

[Lynne Kues]

I'm kind of surprised that API doesn't exist for this, but with the different browsers, I guess this is not simple? Anyway, I want to enable a tool bar element based on whether or not something is selected. How would you suggest doing that?

[Garry Yao]

Replying to lynne_kues:

I'm kind of surprised that API doesn't exist for this, but with the different browsers, I guess this is not simple? Anyway, I want to enable a tool bar element based on whether or not something is selected. How would you suggest doing that?

We'd suggest avoid doing that, as even been implemented (with mousemove event), it would become a performance hurt for the editor.

[Lynne Kues]

I think this is doable without tracking mouse moves. The event should be fired after the selection is complete (e.g., drag end, mouse click if a current selection exists).

[Jakub Ś]

Confirm only in non-IEs, the 'selectionChange' event is a bit lazy

[Ben Duncan]

Yes, this traces back to checkSelectionChange in selection.js. It is basically verifying if the selection has changed based on the path of the selection element, not the selection start and end points (which is more accurate). Because of this, if the selection starts in the same node as the previous selection, it will not fire a change. You can select one letter, then start at that letter and select the entire editor, and no change will be fired.

I think it would be better to store an object with references to the start and end nodes and offsets, or the range it it's entirety though that might be too bloated.

---

In response to lynne_kues: This is definitely doable, and in fact built into ckeditor core in many places, and there are a few helper methods for you. When you add the command to the menu, use ​contextSensitive:true and the refresh method. An example of this being used to change a command's availability can be found ​here.

[Ben Duncan]

This is still an issue as of version 4.2