FCKeditor does not get attached when changing inputs in IE

What was the exact error? A JavaScript error can halt all scripts if it happens at the wrong time.

Are you using the 'Optimize CSS files' option on the Performance page? If IE encounters more than 31 or so stylesheets, it simply ignores the last ones. These are usually the files loaded by the editors. The editors actually load and start up nicely, which is why no errors show up, it's just not visible because its styles are missing. Enabling the 'Optimize CSS files' option compresses almost all files to a single file which can drastically reduce the number of files, allowing IE to load those for the editor. Several people have had this problem when using the Zen theme.

Just to be sure, try enabling the script optimization option too (not likely to work).
Does it say on which line and in which file the error appears?
Which plugins have you enabled? Teaser Break? Image Assist? Some other?

I can't reproduce this on my servers so I can't debug it. I'm guessing IE fails on something in fckeditor-2.6.js as it's the only file affected by that option and contains a reference to FCKeditorAPI.
It seems likely that the point of failure would be in the detach method, as we check to make sure FCKeditorAPI is defined in one place, but not the other.
That code does not run before the editor has been attached and is about to be detached, so it should only run when switching from a format using FCKeditor, not when switching to one...

I made a quick patch to fix the FCKeditorAPI check, but I don't think it will fix this issue.

Which exact editor version are you using?
Does the editor show up if you set it to be used on the default input format, so it's loaded when the page is loaded, or does it only break when switching to it?

The only way for FCKeditorAPI to not be defined would be if the editor was not attached at all, which seems to be the case. Kinda good we did try to access the API without checking if it existed first, or we would not seen an error to indicate this. For IE, FCKeditorAPI is defined in fckeditor/editor/js/fckeditorcode_ie.js which is loaded by fckeditor/editor/fckeditor.html. That .html file is loaded into the iFrame created by the editor in fckeditor/fckeditor.js (which is included in the document by Wsywigy modyle's serverside editor implementation).
Somewhere along the way, there's a problem. Maybe a file is missing, incorrectly referenced, or something like that. The only relevant parts of that process which Wysiwyg module controls are the name of the original textarea and the basepath, the rest is handled by the editor itself. Normally, the editor can also figure out the basepath to its files, but when fckeditor.js and other .js files are combined into a single file during JS optimization, autodetection is not possible.
Therefore it seems likely that the basepath set by Wysiwyg module is wrong, so the rest of the files can't be loaded.

To confirm this; It should also be possible to find the iFrame created by fckeditor.js in the document. This could be located using tools like the "Web Developer toolbar" for IE, or something else capable of walking the DOM or showing the generated source. When viewing the DOM, you should also be able to inspect the Drupal.settings.wysiwyg.config.fckeditor.format#.EditorPath value, which should match where the actual files are on your server (relative to index.html). A proxy tool like Fiddler should also be able to see the HTTP requests made by IE when trying to access these files, and they should be easy to distinguish because of the 404 status code. Now that I think of it, the iFrame would probably show you the standard Drupal 404 page if fckeditor.html could not be located, but I don't remember if its set to be displayed before the contents are loaded.

In any case, this should provide some help when debugging the issue. Just ask if you wish to know something specific.

Sorry, without further information this issue can only be marked as won't fix.

Feel free to re-open this issue if you want to provide further information. Thanks.