#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