Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#12809 closed Bug (invalid)

Multiple '.cke_widget_selected' elements

Reported by: Pieter Eggermont Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:


I am using CKE in a Shared space. It is like Google Docs, an online reporting tool. I can add, through a widget, container boxes (just HTML elements).

If I add a widget-container on page 1 and later on page 2,3, .. and swap between pages I am capable of having multiple elements with the class 'cke_widget_selected'.

Am I wrong or should it be the goal of having only one element with this class? If I swap of a page, I swap of CKE instance which is logic. But what is not logic is that the 'cke_widget_selected' class is not deleted of the previous-active-page.

Change History (1)

comment:1 Changed 9 years ago by Piotrek Koszuliński

Keywords: sharedSpaces cke_widget_selected removed
Resolution: invalid
Status: newclosed
Version: 4.4.6

There are two classes involved - cke_widget_selected and cke_widget_focused and two corresponding states - widget can be selected and widget can also be focused. The difference is that many widgets can be selected at a time, but only one can be focused.

Let's consider a case when there are many widgets in an editor and someone presses CTRL+A. Now, the entire content of the editor is selected, so every widget in it is selected. That's why I said that many widgets can be selected at a time.

Now, someone clicks one of these widgets. You could say that someone selected it and that's true - the widget wrapper got the cke_widget_selected class and was added to the repository.selected array. However, widget is now in a different state than in the previous (select-all) case - now it got the focus. Hence, it also got the cke_widget_focused class and repository.focused was set. (Note that the blue outline is added by the cke_widget_focused class.)

The above explains the difference between focused and selected states, but of course it is not an answer to your question. The missing piece is that when an editor is blurred it retains the selection. Together with the editor the widget loses focus too, but it stays selected. You can check this by using TAB key to focus the editor - the widget will be focused again (this side effect may not work in some cases). You can also get the selection for the blurred editor instance and it should contain the widget.

The selection saving feature exists for at least two reasons:

  • It is true in native implementations as well. When you're using the classic (iframed) editor, when you made a selection inside it and then clicked outside, the text is still selected inside the editor, but a colour of the selection changes. Basically - there's one selection per document (in all browsers except IEs, but it will change in the future, because this is being standardised).
  • Without it it wouldn't be possible to implement dialogs and other focusable components around the editable. For instance when committing a dialog, the editor wouldn't know where to insert the new table or image. It must remember where was the selection even though selections were made in some other fields in the meantime.
Last edited 9 years ago by Piotrek Koszuliński (previous) (diff)
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy