Opened 9 years ago

Closed 8 years ago

#2135 closed Bug (fixed)

Null is saved when submiting the form in IE6

Reported by: telesto Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.6.3
Component: Core : Output Data Version: SVN (FCKeditor) - Retired
Keywords: Confirmed IE Review+ Cc:


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

Attachments (4) (2.1 KB) - added by telesto 9 years ago.
Test files for this bug
TC_2135.png (5.4 KB) - added by w.olchawa 9 years ago.
Screenshot of th output data
2135.patch (2.2 KB) - added by martinkou 8 years ago.
2135_2.patch (2.1 KB) - added by martinkou 8 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by w.olchawa

  • Component changed from General to Core : Output Data
  • Keywords Pending WorksForMe added

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.


Changed 9 years ago by telesto

Test files for this bug

comment:2 Changed 9 years ago by 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???

comment:3 Changed 9 years ago by w.olchawa

  • Keywords Confirmed IE added; Pending WorksForMe removed
  • Version set to SVN

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.

Changed 9 years ago by w.olchawa

Screenshot of th output data

comment:4 Changed 8 years ago by fredck

  • Milestone set to FCKeditor 2.6.2

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

comment:5 Changed 8 years ago by martinkou

  • Owner set to martinkou
  • Status changed from new to assigned

comment:6 Changed 8 years ago by 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:
    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".

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

Changed 8 years ago by martinkou

comment:8 Changed 8 years ago by martinkou

  • Keywords Review? added

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.

comment:9 Changed 8 years ago by fredck

  • Keywords Review- added; Review? removed

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
setTimeout( function()
			editArea.Window.document.documentElement.doScroll("left") ;
			setTimeout( arguments.callee, 0 ) ;
			return ;
		editArea.Window._FCKEditingArea = editArea ; 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).

Changed 8 years ago by martinkou

comment:10 Changed 8 years ago by martinkou

  • Keywords Review? added; Review- removed

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

comment:11 Changed 8 years ago by fredck

  • Keywords Review+ added; Review? removed

comment:12 Changed 8 years ago by martinkou

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

Fixed with [2255].

Click here for more info about our SVN system.

Note: See TracTickets for help on using tickets.
© 2003 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy