Certain markup causes infinite loop in Javascript

[dustball]

1. Load the demo at http://www.fckeditor.net/demo in Firefox and paste in the following code in Source mode:

<div style="text-align: center;">
  <font size="6">
    <font size="2">
      Hello
    </font>
  </font>
  <div style="text-align: right;">
    There
  </div>
</div>

2. Click on "Hello"

3. Click the Left Justify button

The browser freezes.

[martinkou]

I've traced the script execution for a while but I still don't get what's really happening. The infinite loop is located in the FCKDomRangeIterator class, and when it is looping it is splitting out empty <DIV> blocks endlessly. I don't really understand why it is splitting out the <DIV> blocks in Firefox, however. The usual reasons to such bugs (e.g. the bookmark span, the bogus BR nodes, CheckStart|EndOfBlock() giving out wrong results, etc.) do not apply.

Maybe Fred can better handle this ticket since he wrote the iterator class.

[martinkou]

#1656 is marked as dup of this ticket.

[fredck]

Confirmed also with Safari and Opera.

[fredck]

The proposed patch should fix the editor behavior in this case. Now, div elements are considered block elements only if they are not "containers", containing other block elements.

The sample in this ticket should be a rare case (even if we all know it is not). The first div element is containing inline elements as well as block elements. It is ambiguous. This situation is well defined in the HTML5 specifications for the DIV element.

To fix the situation, the editor will properly place the inline elements in a block element, before applying the alignment. With EnterMode=p, the block element used for that is <p>. So, we'll endup with the following result:

<div style="text-align: center;">
  <p style="text-align: left;">
    <font size="6">
      <font size="2">
        Hello
      </font>
    </font>
  </p>
  <div style="text-align: right;">There</div>
</div>

If EnterMode != p, then we'll have a <div> instead of <p>.

[martinkou]

I've tested the patch, it works. And the HTML output after FCKDomRangeIterator runs through the ambiguous line matches the description from Fred. So I'm giving it a Review+.

[fredck]

Fixed with [1218]. Click here for more info about our SVN system.