id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
14813	Firefox fails to apply contentsCss to later editors in a rapid series	Alex-Dev		"== Steps to reproduce ==

1. Use the Firefox browser; with debugger turned OFF.
2. Create a program that loads five textarea/iframe CKEditors in rapid sequence.
3. Provide a contentsCss file to be applied.

== Expected result ==
The contentsCss file is applied to all five.

== Actual result ==
Last one or two don't have the contentsCss file applied.

== Other details (browser, OS, CKEditor version, installed plugins) ==
I have confirmed that the string going to ""doc.write()"" always has the proper <link> statement, so that string is consistently built correctly.  

I have confirmed, through the element Inspector, that the first three editors have had the stylesheet applied, and that the last one, (at least, often the last two,) have not had the stylesheet applied.

This, of course, looks like some sort of timing issue; but it is very strange.  Why would the <link> directive fail?  The data is all there, so the string is getting delivered to Firefox, but Firefox somehow does not fulfill the <link> directive.

By the way, I have confirmed that the ""try/catch"" around ""doc.write()"" in ""setData()"" has never triggered the ""catch""; so that's not it.

I have confirmed that ""setData()"" is getting called for each editor; obviously, since the data shows up, but also through ""console.log()"" I have confirmed that ""setData()"" is called twice for the editors failing to get ""contentsCss"" applied, just the same as for those that succeed in getting ""contentsCss"" applied.

Note: Within Firefox debugger, the issue does not occur.  As you know, such a ""disappearance"" of a problem is not unusual for timing related issues, since the debugger alters event sequences and timings.

Alexander

"	Bug	closed	Normal		General		expired