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

[Frederico Caldeira Knabben]

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.

[Frederico Caldeira Knabben]

Test Case

[Alfonso Martínez de Lizarrondo]

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)

[Martin Kou]

Fixed with [543].

Click here for more info about our SVN system.

[Alfonso Martínez de Lizarrondo]

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.

[Martin Kou]

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