Null is saved when submiting the form in IE6

[telesto]

Set the EditorAreaCSS property:

oFCKeditor.Config['EditorAreaCSS'] = 'some/file.css';

in some/file.css is standard css file. Everything ok, no problems... But if I write into this file standard css function:

@import url('some/other/file.css');

Everything seems to work fine but that is not true. File was imported succesfuly, styles changed according to 'some/other/file.css', but try to do this: 1) Click into FCKeditor area and change some text 2) Click on Source button (the source code will appear) 3) Click on Source button again (you will get back into WYSIWYG area) - still everything seems fine, style is ok but follow the last step 4) Click on submit button The submited text is now 'null' and everything what was really in the FCKeditor area disappeared forever!!!! Even if everythink looked fine...

For reproducing the bug don't do anythink else than what is described in four steps above. When you write something in FCKeditor area after step 3 the submited text will be ok.

When I removed the @import function and copied the content of the 'some/other/file.css' file into 'some/file.css' everything was ok...

[w.olchawa]

I followed your reproduction steps but I didn't encounter any problem with the output data. I've used the current SVN version of FCKeditor on IIS Server Windows XP Professional. Perhaps it is only related to your server client so please let us know what server client do you use and in what version of FCKeditor did the bug occured.

Thanks

[telesto]

Test files for this bug

[telesto]

I added test files. Just copy files to _sample directory of your fckeditor. I have used Win XP Professional, last version of FCKeditor, Apache 2.0 and PHP 5.2.3. It is more complicated than I thought. The bug does not occure every time when you try submit form; however, it seems to occure only in IE6. Follow these steps.

1) load the sample page 2) click into editor area 3) click on Source button in toolbar 4) click on it again to get back to WYSIWYG mode 5) then submit the form with Send button 6) you will see the result with submited text 7) if bug did not occure go back, reload page and start with step 1

Sometimes it occures for the first time, but sometimes it occures during fifth attempt. When I removed the @import function from the css file this bug never occured!!!

I have swf file with screen captured operations but it has almost 2MB. Should I put it somewhere on the Internet???

[w.olchawa]

I've done some testing and I can definitely reproduce this bug on IE6 and IE7 using the latest SVN version of FCKeditor. FF2 doesn't seem to be affected.

[w.olchawa]

Screenshot of th output data

[fredck]

This one is related to lost of data. It definitely worth a look for the next release.

[martinkou]

This issue seems to be caused by slow loading imported CSS files.

I've got a method that can always reproduce this bug:

1. Set IE's cache to check for new version of the page on every visit.
2. Rename cssfile.css to cssfile.php.
3. Change the contents of cssfile.php to the following:

   <?php
   sleep(1);
   header('Content-type: text/css');
   ?>
   * { color: red; }
   

4. Change the import line in sample02.css to import cssfile.php.
5. Open sample02.html in IE.
6. Wait until the WYSIWYG text appears, switch to Source mode. Just keep trying if you have an error.
7. Switch back to WYSIWYG mode.
8. When the WYSIWYG text apepars again, press "Submit".
9. You've submitted "null".

[martinkou]

Oh, turns out the PHP sleep trick is not needed at all. The only thing needed is to modify IE's cache setting to check for new version of the page on every visit.

[martinkou]

IE apparently had a problem with turning readyState to "complete" when it loads CSS from @import directives, and when its cache setting is set to "Check for new version on every visit". This causes FCKEditingArea_OnCompleteStart in fckeditingarea.js to be called only well after (e.g. 15 seconds) the editing content is visible to the user.

I've written a patch to use a simplified version of the domReady event logic commonly found in modern AJAX libraries (e.g. MooTools), to fix the problem.

[fredck]

I'm sure that John Resig is aware about how limited his book is. That's why he's working on something a bit better now.

The following is one of the most common IE solutions for DOMContentLoaded. It's used by JQuery, btw:

// Using a IE alternative for DOMContentLoaded, similar to the
// solution proposed at http://javascript.nwbox.com/IEContentLoaded/
setTimeout( function()
	{
		try 
		{
			editArea.Window.document.documentElement.doScroll("left") ;
		}
		catch(e)
		{
			setTimeout( arguments.callee, 0 ) ;
			return ;
		}
		editArea.Window._FCKEditingArea = editArea ;
		FCKEditingArea_CompleteStart.call( editArea.Window ) ;
	}, 0 ) ;

Check out if it works on this case too. It is simpler and clearer.

In any case, I'm pretty happy to say that V3 changed this loading logic with a much more robust solution, saving us from all these tricks (there are some other tricks of course).

[martinkou]

The doScroll() check seems to work ok. Proposing new patch.

[martinkou]

Fixed with [2255].

Click here for more info about our SVN system.