Opened 17 years ago

Closed 17 years ago

Last modified 16 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 Alfonso Martínez de Lizarrondo 17 years ago.
Alternative solution

Download all attachments as: .zip

Change History (6)

comment:1 Changed 17 years ago by Frederico Caldeira Knabben

Keywords: Confirmed IE added
Milestone: FCKeditor 2.4.3
Version: FCKeditor 2.4.2

Confirmed with IE6. Ok with FF2.

Changed 17 years ago by Alfonso Martínez de Lizarrondo

Attachment: process xml node.patch added

Alternative solution

comment:2 Changed 17 years ago by Alfonso Martínez de Lizarrondo

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 17 years ago by Frederico Caldeira Knabben

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 17 years ago by Alfonso Martínez de Lizarrondo

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 17 years ago by Frederico Caldeira Knabben

Resolution: fixed
Status: newclosed

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 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy