Opened 14 years ago

Closed 14 years ago

#4836 closed Bug (fixed)

SCAYT - when enabled, text formatting is working differently

Reported by: Wiktor Walc Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.3
Component: UI : Spell Checker Version: 3.0.1
Keywords: Confirmed Cc: WebSpellChecker.net

Description

Probably somehow related to #4793, but this problem exists in many browsers (tested on FF 3.5.5, Safari 4.0.4, IE8):

  • paste the following in source mode:
     <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
    
  • switch to wysiwyg mode
  • enable SCAYT
  • select "etur adipisicing elit, sed", press Ctrl + B
  • result:
    ... consect<strong>etur</strong><strong> adipisicing elit, sed</strong> do ...
    
    (when SCAYT is disabled, only one <strong> element is created, when enabled, another <strong> element is created straight after the end of first word)

Attachments (1)

4836.patch (5.1 KB) - added by Garry Yao 14 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 14 years ago by Frederico Caldeira Knabben

Cc: WebSpellChecker.net added
Component: GeneralUI : Spell Checker
Milestone: CKEditor 3.3

comment:2 Changed 14 years ago by Garry Yao

Obviously that's because of the SCAYT marker and the applied style is conflicting with each other, though it's possible to introduce something to make them coordinate with each other, or even yield to one other and fixing up on output, I would suggest of another more generic way of such kinds of troubles: The idea is to make SCAYT working isolated from the editor commands, by meaning that, SCAYT would reset the DOM state (including the selection) back to normal on 'beforeCommandExec' event( I don't know if there's an existing SCAYT API already capable of that) and then restart again after the command has completed on 'afterCommandExec', in this way editor and SCAYT could work in different *process* thus will not be interrupted by each other.
I would ask SpellChecker.net to evaluate the pros and cons of this approach, especially from the performance perspective, then we'll know better which way to head for.

comment:3 Changed 14 years ago by WebSpellChecker.net

The problem reproduces when the SCAYT markup overlaps editor markup. It is not reproduces when editor markup covers SCAYT markup and vise versa. The problem reason is that browser's DOM normalize the markup - when two markups are overlapped (<strong>a<em>b</strong>c</em>) then DOM closes the first tag and re-opens it after the second and etc. (<strong>a</strong><em><strong>b</strong></em><em>c</em>).

Removing SCAYT markup before running command and then applying it after the command ran will not solve the problem.

We are evaluating possibility to join split markups while removing SCAYT markup. It is easy enough for 2 overlapped markups but not so easy when there are 3 or more of them.

comment:4 Changed 14 years ago by Garry Yao

Removing SCAYT markup before running command and then applying it after the command ran will not solve the problem.

It depends on how SCAYT behaves there, we know there's really no win-win situation, where one of our "marker" has to yield.

// Apply strong style
consect<strong>etur adipisicing</strong>
// Current SCAYT markup
<span scaytid="1">consect<strong>etur</strong></span><strong> <span scaytid="2">adipisicing</span></strong>
// Markup *we* prefer
<span scaytid="1">consect</span><strong><span scaytid="1">etur</span> <span scaytid="2">adipisicing</span></strong>

We are evaluating possibility to join split markups while removing SCAYT markup...

This could be our secondary preference as it adds one more unmanageable DOM modification to us.

comment:5 Changed 14 years ago by WebSpellChecker.net

To resolve this issue need to publish 4836 patch provided to spellchecker.net earlier, ,take a patches from #5550 (scayt plugin updates) and #5551 (scayt core updates).

Changed 14 years ago by Garry Yao

Attachment: 4836.patch added

comment:6 Changed 14 years ago by Garry Yao

Keywords: Review? added

Combine all the necessary patches for easy reviewing.

comment:7 Changed 14 years ago by Garry Yao

Keywords: Review? removed
Owner: set to Garry Yao
Status: newassigned

The review is already conducted at #5567.

comment:8 Changed 14 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed

Fixed with [5397].

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