Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#581 closed Bug (fixed)

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

Reported by: Frederico Caldeira Knabben 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 Frederico Caldeira Knabben 17 years ago.
Test Case

Download all attachments as: .zip

Change History (5)

Changed 17 years ago by Frederico Caldeira Knabben

Attachment: fit_window_tc.html added

Test Case

comment:1 Changed 17 years ago by 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)

comment:2 Changed 17 years ago by Martin Kou

Resolution: fixed
Status: newclosed

Fixed with [543].

Click here for more info about our SVN system.

comment:3 Changed 17 years ago by 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.

comment:4 Changed 17 years ago by 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().
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