#1717: Table inside of Div producing unresponsive script
----------------------------+-----------------------------------------------
  Reporter:  mattleff       |       Owner:  martinkou    
      Type:  Bug            |      Status:  assigned     
  Priority:  High           |   Milestone:  FCKeditor 2.6
 Component:  Core : Styles  |     Version:  SVN          
Resolution:                 |    Keywords:  Confirmed    
----------------------------+-----------------------------------------------
Comment (by martinkou):

 I've spent a whole day today looking at this bug and thinking of a
 reasonable solution.

 First... an analysis of why the bug happened. The infinite loop happens in
 the FCKDomRangeIterator class - this class have caused quite a number of
 infinite loop bugs since 2.5 was released. And every time there's an
 infinite loop, the loop's behavior has always been the same - the iterator
 tries to split a block tag to two parts, one small and visibly empty part
 on top, and one big visibly untouched part in the bottom. The iterator
 then returns the top part, and keeps the untouched bottom part for the
 next iteration. Since the bottom part was untouched, the next iteration's
 logic finds itself in the same situation - need to split, return an
 "empty" block, and leave the same problematic block for the next
 iteration.

 What's happening in this case... in each run of the
 FCKDomRangeIterator::GetNextParagraph() function...
  1. A range object was initialized as a collapsed range and pointing to
 the beginning of the <div> block.
  1. The range object was gradually expanded just before the <table>
 element. The scanned area inside the range is one paragraph.
  1. A block split was determined to be needed by the GetNextParagraph()
 function since the range object doesn't include the whole block, yet
 GetNextParagraph() still needs to return an independent block as the next
 paragraph.
  1. A shallow copy of the <div> block is created, lets call it newBlock.
  1. The contents inside the range (i.e. the start tag of <span> node) is
 extracted into a document fragment.
  1. Since DOM operations do not permit extracting only the start tag of a
 DOM node, the <span> node is instead shallow copied to the document
 fragment, while the original <span> in the master <div> block is
 untouched.
  1. The document fragment was appended to newBlock.
  1. newBlock was added into the document, just before the old <div> block.
  1. newBlock was returned by GetNextParagraph(), while the old <div>
 block's reference was stored in the FCKDomRangeIterator object as the DOM
 node to be scanned in the next iteration.


 There are two errors here:
  1. Why is splitting a block needed when I'm formatting a block? Or
 changing the text alignment of the block? Or putting the block into a
 blockquote? (all three operations mentioned would hang the browser with
 the same test input) The block splitting operation in GetNextParagraph()
 makes sense for things like making lists, but not for others.
  1. The very possibility of GetNextParagraph() going into infinite loop
 needs to be eliminated. If the next block to be scanned is just the same
 as the block I'm scanning, I'm guaranteed to have an infinite loop.

 I've coded some logic today to try to eliminate the possibility of
 GetNextParagraph() of going infinite loop. It works by examining the
 returned contents from range.ExtractContents() in line 265 of
 fckdomrangeiterator.js. If the returned contents has only one editable
 point and that the corresponding node is empty (e.g. a stack of <span>,
 <b>, <i> nodes with no text inside), then we conclude that
 ExtractContents() hasn't removed anything visible from the master block
 and thus we're gonna run into an infinite loop if we proceed to split the
 block. The block splitting operation would be stopped at this point to
 prevent an infinite loop.

 This stops the infinite looping in the provided test case, but it still
 wouldn't completely stop GetNextParagraph() from splitting the <div> block
 for a finite number of times. Anyway I'm attaching the infinite loop
 avoidance code I've got so far here to get some comments on whether the
 current approach is reasonable.

-- 
Ticket URL: <https://dev.fckeditor.net/ticket/1717#comment:3>
FCKeditor <http://www.fckeditor.net>
The text editor for Internet
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
FCKeditor-Trac mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fckeditor-trac

Reply via email to