Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#239 closed Bug (fixed)

<xml> in html make IE truncate paragraphs (solution included)

Reported by: Guillaume Outters Owned by:
Priority: Normal Milestone: FCKeditor 2.4.3
Component: General Version: FCKeditor 2.4.2
Keywords: Confirmed IE Cc:

Description

Example: IE6 or IE7, go to http://www.fckeditor.net/demo, Source, insert "<xml>toto</xml>" before "You", Source, Source.

Result: Everything has disappeared after the newly-introduced "<xml>" (well, it was transformed to an "<!-- Element not supported - Type: 9 Name: #document-->").

Analysis: While generating the DOM for something like "<p><span>s</span><xml>x</xml><span>s</span></p>", IE creates a document node in which it incorrectly includes, not only "<xml>", but its nextsiblings too. Thus FCK receives it as "<p><span>s</span><!-- Element […] --></p>".

Solution: Filter out those. On line 299 of internals/fck.js (revision 203), add "|XML" to sTags.

Why, oh why: Because we had a Word-generated HTML that included some "<xml><o:OLEObject>[…]</o:OLEObject></xml>", sometimes embracing the OLE into IE-specific conditional comments.

Attachments (1)

process xml node.patch (1.4 KB) - added by alfonsoml 10 years ago.
Alternative solution

Download all attachments as: .zip

Change History (6)

comment:1 Changed 10 years ago by fredck

  • Keywords Confirmed IE added
  • Milestone set to FCKeditor 2.4.3
  • Version set to FCKeditor 2.4.2

Confirmed with IE6. Ok with FF2.

Changed 10 years ago by alfonsoml

Alternative solution

comment:2 Changed 10 years ago by alfonsoml

I've attached a patch with an alternative solution that tries to take care of the serialization of the DOM instead of changing the namespace of the tag.

The differences from my point of view are as follow with very little testing:
With the first patch the contents of the xml tag are visible while editing, and those contents are parsed (so special elements are converted to entities).

With the second patch the contents aren't visible and the output is the same string that it was there at the start.

So if we want to show the contents in the editor we should go for the first patch. On the other hand, if it is better to not show or change them, then the second patch would be a better solution.

comment:3 Changed 10 years ago by fredck

Alfonso, wouldn't the following be a much simpler and efficient solution, resulting the same exact behavior in IE and FF?

  • editor/_source/internals/fck.js

     
    297297
    298298                // IE doesn't support <abbr> and it breaks it. Let's protect it.
    299299                if ( FCKBrowserInfo.IsIE )
    300                         sTags += sTags.length > 0 ? '|ABBR' : 'ABBR' ;
     300                        sTags += sTags.length > 0 ? '|ABBR|XML' : 'ABBR|XML' ;
    301301
    302302                var oRegex ;
    303303                if ( sTags.length > 0 )

comment:4 Changed 10 years ago by alfonsoml

wow, it still surprises me the nice integration between trak and SVN :-)

The nicely shown patch is what Guillaume proposed in the original report, and I wanted to take a look at other options to fix the problem, the results are as explained some minor differences, and I think that Guillaume should say if one solution is better than the other for the real code that he's facing.

If it doesn't matter then it's clear that just protecting the <xml> tag is quite simpler.

comment:5 Changed 10 years ago by fredck

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

For now, I'll go with the simpler way. I don't really care about interpreting the contents of <xml> tags. Let's just see them as normal <span> tags.

Fixed with [351].

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