Opened 14 years ago

Closed 14 years ago

#5570 closed Bug (fixed)

[IE] SCAYT load blind cursor in document

Reported by: Garry Yao Owned by:
Priority: Normal Milestone: CKEditor 3.3
Component: UI : Spell Checker Version:
Keywords: Confirmed IE Review+ Cc: WebSpellChecker.net

Description

Environment

All IE versions.

Reproducing Procedures

  1. Open the 'replacebyclass' sample page;
  2. Enable SCAYT, before SCAYT get really enabled, put cursor into the document;
  3. Do nothing until SCAYT button has shown toggled on.
    • Actual Result: Cursor is not blinking inside the document anymore.

Attachments (2)

5572.patch (1.2 KB) - added by WebSpellChecker.net 14 years ago.
5570.patch (1.2 KB) - added by WebSpellChecker.net 14 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 14 years ago by Garry Yao

Note that disable/re-enable SCAYT also blink the cursor necessarily.

comment:2 Changed 14 years ago by WebSpellChecker.net

confirm

comment:3 Changed 14 years ago by Garry Yao

The bug is fixed by recent SCAYT core updates, but when using menu button to enable SCAYT, the cursor still get blinded by that, we need put focus manually into editor after SCAYT menu get closed, BTW, attachment:ticket:5572:5572.patch doesn't fix the problem.

comment:4 Changed 14 years ago by WebSpellChecker.net

Keywords: Review? added

attachment:ticket:5572:5572_2.patch and new core resolve the problem

comment:5 Changed 14 years ago by Garry Yao

Keywords: Review- added; Review? removed

The cursor has to be blinking inside document as soon as the SCAYT menu is closed, instead of on load of SCAYT.

comment:6 Changed 14 years ago by WebSpellChecker.net

attachment:ticket:5572:5572_3.patch and new core resolve the problem

comment:7 Changed 14 years ago by Garry Yao

By looking at the patch, I recognize a misunderstanding here, that SCAYT should NOT imply editor focus, by meaning of that, any SCAYT operations could only continue the focus status of the editor instead of changing it, e.g. when editor doesn't have initial focus, open SCAYT won't force it.

comment:8 Changed 14 years ago by Garry Yao

#5650 has been marked as a DUP.

comment:9 Changed 14 years ago by WebSpellChecker.net

Block Styles, Paragraph Format, Font Name, Font Size, Text Color, Text Background are changing the focus status. Should SCAYT do the same or should it behaves differently?

We use editor.focus(); on line 343 in exec method to make SCAYT behaves the same way as controls described above do.

comment:10 Changed 14 years ago by Garry Yao

The listed commands are to change the editor contents and thus are different with SCAYT, SCAYT behavior could be compared to commands like 'maximize' and 'showblock'.

comment:11 Changed 14 years ago by WebSpellChecker.net

We have tried to prepare the solution which stores editor focus state (by attaching listeners to onfocus and on blur) on scayt toolbar button click and restore it on scayt.exec.

We have reviewed the implementation and found that scayt toolbar button is implemented on the base of menubutton plug-in, which is based on contextmenu plug-in. menubutton plug-in directly calls contextMenu.show method, while its' first routine is editor.focus(). menubutton plug-in allows to attach onMenu listener, but it fires after the show method is called. So we always get the same value for the focus state (focused), i.e. couldn’t get focus state from scayt plug-in using current architecture.

Could you please advice how we can correctly obtain focus state from the CKEditor perspective?

comment:12 in reply to:  11 Changed 14 years ago by Garry Yao

Could you please advice how we can correctly obtain focus state from the CKEditor perspective?

We've opened #5681 to resolve the problem you described here.

comment:13 Changed 14 years ago by Frederico Caldeira Knabben

In the editor point of view, it's ok for the menu button to always move the focus into the editor. So, if SCAYT is activated through the menu, it can move the focus to the editor (so it's ok to always have the state "focused", as you're having).

But note that, there is a delay between the menu click and the SCAYT activation. So, after the click, the focus can go to the editor (as it's going), but if the user moves out of the editor, SCAYT must *not* move the focus back to the editor once the (asynchronous) activation is complete.

Changed 14 years ago by WebSpellChecker.net

Attachment: 5572.patch added

Changed 14 years ago by WebSpellChecker.net

Attachment: 5570.patch added

comment:14 Changed 14 years ago by WebSpellChecker.net

Patch 5570 is based on patches for #5572 and *restore* focus on SCAYT load and set focus on SCAYT enable/disable

comment:15 Changed 14 years ago by WebSpellChecker.net

Keywords: Review? added; Review- removed

comment:16 Changed 14 years ago by Garry Yao

Keywords: Review+ added; Review? removed
Resolution: fixed
Status: newclosed

Fixed with [5505].

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