Opened 16 years ago

Closed 16 years ago

#2135 closed Bug (fixed)

Null is saved when submiting the form in IE6

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

Description

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)

_samples.zip (2.1 KB) - added by telesto 16 years ago.
Test files for this bug
TC_2135.png (5.4 KB) - added by Wojciech Olchawa 16 years ago.
Screenshot of th output data
2135.patch (2.2 KB) - added by Martin Kou 16 years ago.
2135_2.patch (2.1 KB) - added by Martin Kou 16 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 16 years ago by Wojciech Olchawa

Component: GeneralCore : 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.

Thanks

Changed 16 years ago by telesto

Attachment: _samples.zip added

Test files for this bug

comment:2 Changed 16 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 16 years ago by Wojciech Olchawa

Keywords: Confirmed IE added; Pending WorksForMe removed
Version: 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 16 years ago by Wojciech Olchawa

Attachment: TC_2135.png added

Screenshot of th output data

comment:4 Changed 16 years ago by Frederico Caldeira Knabben

Milestone: FCKeditor 2.6.2

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

comment:5 Changed 16 years ago by Martin Kou

Owner: set to Martin Kou
Status: newassigned

comment:6 Changed 16 years ago by Martin Kou

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

comment:7 Changed 16 years ago by Martin Kou

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 16 years ago by Martin Kou

Attachment: 2135.patch added

comment:8 Changed 16 years ago by Martin Kou

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 16 years ago by Frederico Caldeira Knabben

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

Changed 16 years ago by Martin Kou

Attachment: 2135_2.patch added

comment:10 Changed 16 years ago by Martin Kou

Keywords: Review? added; Review- removed

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

comment:11 Changed 16 years ago by Frederico Caldeira Knabben

Keywords: Review+ added; Review? removed

comment:12 Changed 16 years ago by Martin Kou

Resolution: fixed
Status: assignedclosed

Fixed with [2255].

Click here for more info about our SVN system.

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