Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#581 closed Bug (fixed)

FitWindow is broken if <input name="style"> is found inside the editor form

Reported by: fredck Owned by:
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: SVN (FCKeditor) - Retired
Keywords: Confirmed IE Cc: jonhubbard@…

Description

In IE, if a <input name="style"> field is available inside the editor's <form>, a JavaScript error is thrown when clicking in the FitWindow button.

Attachments (1)

fit_window_tc.html (1000 bytes) - added by fredck 9 years ago.
Test Case

Download all attachments as: .zip

Change History (5)

Changed 9 years ago by fredck

Test Case

comment:1 Changed 9 years ago by alfonsoml

The problem is that form.style now turns to be the input instead of the style attribute of the form itself.

But that's not the only problem, if the content of the editor (in source mode) is set to

<form style="border: 1px dotted blue;" method="get" name="myForm">
    <input type="text" id="style" name="style" value="" />
</form>

then the editor also fails when trying to serialize the contents from design mode (switching to source or saving)

Firefox, Opera and Safari all handle this without problems.

I can think of two workarounds, but I'm not too pleased with them:

  • Get the outerHtml of the node, and parse the style attribute that way. Something like this:
    FCKTools.SaveStyles = function( element )
    {
    	var oSavedStyles = new Object() ;
    
    	if ( element.className.length > 0 )
    	{
    		oSavedStyles.Class = element.className ;
    		element.className = '' ;
    	}
    
    	// Getting or setting element.style from a form fails if there's an element named style in the form #581
    	var tag = element.outerHTML.replace( element.innerHTML, '' ) ;
    	var matchInlineStyle = tag.match(/style=("|')?(.*)\1/) ;
    
    	if ( matchInlineStyle !== null )
    	{
    		oSavedStyles.Inline = matchInlineStyle[2] ;
    		this.SetAttribute( element, 'style', '') ;
    	}
    
    	return oSavedStyles ;
    }
    
    FCKTools.RestoreStyles = function( element, savedStyles )
    {
    	element.className = savedStyles.Class || '' ;
    	this.SetAttribute( element, 'style', savedStyles.Inline) ;
    }
    
    FCKTools.SetAttribute = function( element, attName, attValue )
    {
    	if ( attValue == null || attValue.length == 0 )
    		element.removeAttribute( attName, 0 ) ;			// 0 : Case Insensitive
    	else
    		element.setAttribute( attName, attValue, 0 ) ;	// 0 : Case Insensitive
    }
    
    But this still fails if the form contains an input named "className", I haven't managed to make it work in that situation and I'm not so sure that even the rest of the code is OK
  • The other option would be to detect that situation, remove for a moment the offending element (replacing it with a span so we don't lose its position), read the property that we want and then reinsert that element back to where it was.

I don't like too much neither of those options. Maybe someone else has another idea about how to fix this problem in all the situations (the serializing problem might go away if it's changed to get the innerHTML of the document or the body and clean it up as Fred pointed out in another bug)

comment:2 Changed 9 years ago by martinkou

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

Fixed with [543].

Click here for more info about our SVN system.

comment:3 Changed 9 years ago by alfonsoml

It looks that [543] only takes care of "style", but as I said it also fails if theres's an input named "className" (that should have the same kind of protection), and we should have a bug to remember that having in the content of the editor

<form style="border: 1px dotted blue;" method="get" name="myForm">
    <input type="text" id="style" name="style" value="" />
</form>

will make it fail to submit the contents or switch to source view if it can't be fixed right now.

comment:4 Changed 9 years ago by martinkou

Ok, I've committed the change set [568] which fixes the following issues:

  1. Form input named "className" in the editor form would cause errors in the maximize feature.
  2. Form input named "style" inside the editor document would cause errors when calling FCKXhtml.GetXHTML().
Note: See TracTickets for help on using tickets.
© 2003 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy