Opened 9 years ago

Last modified 6 years ago

#6443 confirmed Bug

SelectionChange not firing in all instances

Reported by: Lynne Kues Owned by:
Priority: Normal Milestone:
Component: General Version: 3.0
Keywords: IBM Discussion Cc: jamcunni@…, satya_minnekanti@…

Description

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.

Attachments (1)

selection-ticket.html (672 bytes) - added by Lynne Kues 9 years ago.

Download all attachments as: .zip

Change History (10)

Changed 9 years ago by Lynne Kues

Attachment: selection-ticket.html added

comment:1 Changed 9 years ago by Garry Yao

Keywords: Discussion added

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.

comment:2 Changed 9 years ago by James

Cc: jamcunni@… added

comment:3 Changed 9 years ago by 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?

comment:4 Changed 9 years ago by Satya Minnekanti

Cc: satya_minnekanti@… added

comment:5 in reply to:  3 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by 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).

comment:7 Changed 8 years ago by Jakub Ś

Status: newconfirmed
Version: 3.43.0

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

comment:8 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by Ben Duncan

This is still an issue as of version 4.2

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy