Opened 9 years ago

Closed 9 years ago

#1603 closed Bug (fixed)

Certain markup causes infinite loop in Javascript

Reported by: dustball Owned by: fredck
Priority: Normal Milestone: FCKeditor 2.6
Component: General Version: FCKeditor 2.5
Keywords: Review+ Cc:

Description

  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>
  1. Click on "Hello"
  1. Click the Left Justify button

The browser freezes.

Attachments (1)

1603.patch (2.6 KB) - added by fredck 9 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 9 years ago by martinkou

  • Keywords Confirmed Firefox added; firefox removed
  • Milestone set to FCKeditor 2.6
  • Owner set to martinkou
  • Status changed from new to assigned
  • Version set to FCKeditor 2.5

comment:2 Changed 9 years ago by martinkou

  • Owner martinkou deleted
  • Status changed from assigned to new

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.

comment:3 Changed 9 years ago by martinkou

#1656 is marked as dup of this ticket.

comment:4 Changed 9 years ago by fredck

  • Keywords Safari Opera added
  • Owner set to fredck
  • Status changed from new to assigned

Confirmed also with Safari and Opera.

Changed 9 years ago by fredck

comment:5 Changed 9 years ago by fredck

  • Keywords Review? added

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>.

comment:6 Changed 9 years ago by martinkou

  • Keywords Review+ added; Review? Confirmed Firefox Safari Opera removed

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+.

comment:7 Changed 9 years ago by fredck

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

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

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