Opened 6 years ago

Closed 6 years ago

#4836 closed Bug (fixed)

SCAYT - when enabled, text formatting is working differently

Reported by: wwalc Owned by: garry.yao
Priority: Normal Milestone: CKEditor 3.3
Component: UI : Spell Checker Version: 3.0.1
Keywords: Confirmed Cc: SpellChecker.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 6 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 years ago by fredck

  • Cc SpellChecker.net added
  • Component changed from General to UI : Spell Checker
  • Milestone set to CKEditor 3.3

comment:2 Changed 6 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 6 years ago by SpellChecker.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 6 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 6 years ago by SpellChecker.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 6 years ago by garry.yao

comment:6 Changed 6 years ago by garry.yao

  • Keywords Review? added

Combine all the necessary patches for easy reviewing.

comment:7 Changed 6 years ago by garry.yao

  • Keywords Review? removed
  • Owner set to garry.yao
  • Status changed from new to assigned

The review is already conducted at #5567.

comment:8 Changed 6 years ago by garry.yao

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed with [5397].

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