Wysiwyg 6.x-2.1 with FCKEditor crashes IE on save

Are you using a custom theme? Have you tried with Garland?

If you use FF and Firebug and click "Save" on its Console tab (to keep output between page loads) before saving a node, does it log any errors there?

Are you using the Optimize CSS or Optimize JavaScript options on the Performance page?

We recently made a change to FCKeditor to fix another crash in IE (it's in 2.1) when the form was submitted after the editor had been disabled. It basically removes FCKeditor's onsubmit handler just after removing the editor itself as it's no longer needed. This also happens when the form is submitted and the editor is still active, but not until after the original textarea has been synced with the editor. Meaning, the errors you're seeing probably happen before that.

The Save button was added to several tabs in a recent release of Firebug. Red items in the DOM tab are usually ok, not so if items on the Net tab are red.

I can't confirm that hitting the 31 stylesheet limit will cause that problem in FCKeditor, but maybe it will, I usually don't see the editor at all when hitting it.

Anyway, the problem seems to have been solved by "upgrading" to a later version/rewrite of FCKeditor so I'll mark this fixed. But please do post the results if you get time to run that FCKeditor test.

I also was running Drupal 6.16, Wysiwyg 6.x-2.1 with FCKEditor 2.6.5 and have IE8 crashing when I click save. No crash in FF though. I came across this thread and changed to 2.x-dev (Wysiwyg) and 2.6.6 for FCK.

I still had this problem. I have 6 profiles - 3 with FCK and 3 with no editor. When I edited anything with any editor-based profile, I crash. After much playing, I think I isolated the problem.

When the editor has focus and you click 'save', you crash. If you change focus to any other fields on your page, it doesn't crash.

Just installed Druapl 6.16, Wysiwyg-6.x-2.1 on a test site. I added a new input format called Small Editor. I set up a WYSIWYG profile for Filtered HTML and One for Small Editor. To small editor, I added just the basic formatting (bold, italic, underline, left, right, center justify) and smilies. I set no buttons for Filtered HTML. Small shows FCK with just a few buttons. Filtered shows with all buttons enabled.

With Filtered as a default, I add a page - Add title, add description, click in FCK area to keep it active and click preview. It crashes.

If I create a new page and change input formats to Small, add a title, description, click in the FCK area and click preview it works fine.

Then I changed Filtered to have only the formatting buttons that I previously selected for Small and save my settings.

Everything works fine.

Then, I go into the Filtered profile and add either Link/Unlink or Image. Clicking in the FCK editor prior to clicking preview (or save) crashes.

I then updated my FCK from 2.6.5 to 2.6.6, cleared my browser cache and reproduced everything above. It seems to be the Link and Image buttons.

Could someone else please verify this?

If you use FF and Firebug and click "Save" on its Console tab (to keep output between page loads) before saving a node, does it log any errors there?

No

Are you using the Optimize CSS or Optimize JavaScript options on the Performance page?

Yes

I'm not seeing any errors reported in Firefox. This seems to be limited to IE only. I'm running IE8 (but have tried running in IE7 mode with the same results).

Initially, I thought that it might be a problem with the IE-specific js file (fckeditor/editor/js/fckeditorcode_ie.js), but when I run the sample page included with FCK (fckeditor/_samples/default.html) I have no problem clicking the Submit button.

Very strange...

OK. A little more info...

I did a clean install of Drupal 6.16, WYSIWYG 2.1, and FCKEditor 2.6.6 in the libraries folder. I enabled WYSIWYG in Admin Modules. I Changed the editor to FCKEditor 2.6.6 for the Full HTML Input Format. No other changes to any configuration. Then I created a Story, entered the title ('test') and description ('test') and clicked Preview.

I got a crash every time. I set up my IE Developer Tool to catch and debug js errors and what I found was that the offending line was:

var data = instance.FCKDataProcessor.prototype.ConvertToDataFormat.call(this, rootNode, excludeRoot, ignoreIfEmptyParagraph, format);

Which is line 85 of fckeditor-2.6.js.

This is where the code halted. As I would step through the code after this, each line returned a 'Premission Denied' error. When I disable the debugger, IE just crashes reporting a very generic message indicating that it tried to do 'something' too many times.

I sometimes see different behavior depending on which form elements have focus before I click either Submit or Save.

Hope this is helpful.

I also have this problem on two sites that I manage.

Both use wysiwyg 6.x-2.1 one with FCKeditor 2.6.5 and one with FCKeditor 2.6.4.1

So far I have found this happens either when I inset a link or an image.

It doesn't happen using Mozilla Firefox but it does when I use IE8.

The only solution I have found is to disable rich-text before saving the page.

Does anyone have any other suggestions of how to prevent it from crashing IE8?

Having the same error, with IE 7. So far unable to track down the cause...

Yes, exact same result here. No crashes in FF, but always crashes in IE when submitting nodes using Drupal 6.16, Wysiwyg 6.x-2.1 with FCKEditor 2.6.5. Also confirmed that if the focus is not in the editor then it does not crash. Seems clear to be a Wysiwyg 6.x-2.1 or FCKEditor 2.6.5 problem.

Also I thought it was my Drupal configue, but I observe the problem on two separate websites, just not sure when the problem began. I may not have noticed because in the past I was always moving the focus off the editor to change things further down on the node, but recently create a node type with no settings after the body, so the focus stayed there. It could possibly be a conflict with a module that I've recent installed as well. Also I ripped IE8 off my system and reinstalled thinking that this was the problem, but same result after the reinstall.

I am using the Zero point theme.

Also note that in my case the node actually gets created most times, so it seems that the error happens when trying to load the following screen.

Exactly.

I only noticed the problem around the time i did the upgrade to Wysiwyg 6.x-2.1 and assumed the problem was in the module. I also use FF much more. And the IE7 upgrade was also around the same time. Like I said above, having experienced this crash over a hundred times now (mostly to try to isolate the problem) i got a js debug window to popup once and it's looking like the offending code is within FCK. The problem is that I found this same problem with CKEditor as well. The error had to do with a document object being referenced that hadn't been set. The code resides in the IE-specific js file in FCK. I'm not sure whether WYSIWYG is not dealing with focus correctly in terms of FCK's events or if IE7 is breaking FCK or both or none.

I agree with webmaster_prwa about the error occurring on the return trip. I had only been working with existing nodes in edit mode and hadn't tried adding one. I also get the crash when I click Preview. This is really a showstopper for me. I've set my defaults in Better Formats to non-WYSIWYG editors allowing users to switch to a WYSIWYG at their own risk.

And once again, I encountered the crash on a completely vanilla install with no changes to which default installed modules are enabled and only adding the WYSIWYG module with FCK 2.6.5 (and 2.6.6).

I've been debugging this for a time now and I've narrowed it down to the editor->textarea synchronization being caalled over and over until the browser crashes. My initial findings indicate that Wysiwyg's submit handler (the wysiwygDetach function) has been attached several times using jQuery's .submit() method.
Why this crash often [always?] happens when the editor has focus is yet to be determined. Wysiwyg doesn't currently care about what has focus, but maybe IE gets a bit cranky if the focused element is destroyed - when the submit handlers are eventually done.
I have a few leads which I'm trying to follow up as time permits, it's a slow and tedious process but I'm sure there's a solution to be found.

Thanks for the last two replies. I also am eager to see this problem solved because it is a show stopper for me as well if my users see this error.

I wonder if a quick hack is possible if your add logic for Wysiwyg to simply move the focus off itself on submit. Just trying to brainstorm here to get a solution.

Also I wonder what performance is observed on other browsers and if that would give a clue.

I little more info... same problem with IE 8.0 on a Win7 pro box as well ( I use IE 8.0 on WinXP pro ). Win7 displays some error codes and an attempt to check the MS website for more information about the error.

Problem signature:
Problem Event Name: BEX
Application Name: iexplore.exe
Application Version: 8.0.7600.16385
Application Timestamp: 4a5bc69e
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 4b83891a
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

The trip to the MS website however yields nothing useful. In fact the codes above are likely not very useful either, but just trying to do something with the tools I have to help those concerned to locate a solution for this problem.

Also let me repeat that in my case the error is consistently on the return trip to the node view after the submit. That is the node gets created and then the browser fails, apparently when attempting to load the view of the newly created node.

I trapped an object not set error on line 49 of fckeditor/editor/js/fckeditorcode_ie.js
while setting this.Document.body.innerHTML=""

Changing issue title to reflect the true problem.

actually I think this is a more accurate title. CKEditor works fine.

yes, better title. thanks.

The crash happens in the function used to prevent memory leaks in IE, which runs during the outer iFrame's unload event. It also takes care of moving focus away from the editor before it is removed.
It crashes because it doesn't expect that the iFrames have/are being removed, which they normally aren't during submits. As we have to remove the iFrames when switching between the editors and the same code cleans things up on submit, we'll just run the cleanups before removing the iFrames.

From what I can tell, this fixes the issue we're having here. =)

The wysiwygDetach method does get added multiple times to jQuery's submit handler (once per input format), but that's fine as long as the FCKeditor instance is properly removed from FCKeditorAPI.__Instances - which this patch makes sure.

I had this problem and i can confirm that this patch solves it for me.

This patch solves the problem on both my Drupal installs.
Thank you for the effort in figuring this out, greatly appreciated!

@TwoD

You rock!!!

I've confirmed that this works with IE7 and IE8 with:

switching input formats:

• from non-wysiwyg to wysiwyg
• from wysiwyg to another wysiwyg
• from wysiwyg to non-wysiwyg

and then submitting the form using Save, Preview, and Delete.

Thanks for your efforts in finding and submitting a solution so quickly.

For those of you whose dev environment are 'patch-impared' (Running WAMP without Linux-emulating dlls and you cant use patch files), and want to test here's the code to change.

Thanks again, TwoD!

I can confirm that this stops IE from crashing (testing just on IE7 here).

The only thing I do notice is that often when hitting Save or Preview the entire browser window sometimes scrolls back up a bit and it is as if you hadn't clicked the button .. you have to scroll back down and press it again to get anything to happen. Probably this is unrelated to this issue .. in Firefox the screen shakes briefly but the form does submit OK (I get this behavior with and without the patch). As I've not used FCKeditor with Wysiwyg before I don't know if it's always been like this. I get this behavior in Garland. To reproduce choose a page with enough content to more than fill the editor textarea, and scroll around in the editor a bit/move the insertion point by clicking/using the keyboard arrow keys. Then hit the Save or Preview buttons.

Hmm strange, I now can't get IE7 to crash after reverting to the original JS file, even after clearing cache both browser and server end, and restarting IE. Anyway what I can confirm is that the "jumping" behavior when you hit Preview or Save *is* present with the original JS file, so it does look to be a different issue.

Thanks for testing!

I need to get around to committing things soon, been too busy with other things for a while.

This "jump" you are experiencing happens because the editor is completely removed from the DOM before the form is actually submitted, and the original textarea is shown again. The difference in height between the editor and the original textarea determines how far the document will jump. The same code is used both when switching between editors and syncing with the original textarea prior to submit, but we may change that when we have a getContent() - or maybe a updateField() - method for each editor. If so, the editor won't actually be removed prior to a submit, so no jump will occur.

@27, thanks for the info, the jump is only problematic in IE since it prevents the form from submitting but yes would be good to get rid of it altogther if poss! Thanks for all your work on this module BTW. :-)

I've not had that problem with IE, and I don't think the jump itself would cause it, but I'll look into it when I have the time. Thank you for helping improving it. =)

Repeating the song that started in #23:

@TwoD

You rock!!!

:)

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Hello all,

Not sure if I should reopen this bug but I still have IE8 crash on save. The patches are applied and they do work on a simple one instance fckeditor page.
My (CCK) page however contains 4 fckeditor instances and on this page IE8 still crashes while having an image selected and pressing save.

I think I understand the concept of the crash prevention patch, but I do not fully grasp how to apply this logic to all instances (if that's what this problem is about).

Thanks in advance for any help

Hmm, the code removing the event handlers runs once for each instance so it should work no matter how many instances there are.

Reopening this so it'l show up in the queue and I'll remember to re-test again later.
I'll be testing with 2..x-dev as the patched code is in there already.

Thanks for looking into it.
I was wrong in my assumption that multiple fckeditor instances where the root of the issue. It also happens with just one.
(update: removed incorrect clue on when this crash happens)
Will have to investigate a bit more..

My findings so far:
Having the module "Administration menu" activated makes IE8 crash in every theme.
Disabling this module but having a custom javascript file loaded from the theme.info using "scripts[] = myscript.js" makes IE8 crash even without the module "Administration menu".
The js file can be as simple as:

$(document).ready(function() {
var myVar = "";
});
UPDATE
This is so weird, now I can't reproduce the above findings anymore. Just the crashing regardless of theme or active modules, using the latest dev build (6.x-2.x-dev)

I switched to ckeditor and the problems are gone.

Ok, then we know it's isolated to FCKeditor. I'll see if I can debug this today.

Sorry but I'm not able to reproduce this at all. Included the example file you mentioned via garland.info and verified it was added, but IE8 doesn't crash with any editor.

I'm closing this issue again, but if you can find exact steps to reproduce from a clean Drupal installation then please open a new issue. I think the cause for the original crash has been fixed and it'll be easier to track down a new crash cause without being confused by the above discussions. (And the previous participants won't have to see this issue pop up on their drupal.org/user/#/track list hehe.)

Same problem - same as #36

Sorry but that doesn't help. If I can't reproduce the problem you're experiencing I can't fix it.
If you're willing to give me access to a site where this can be reproduced I'd be happy to debug it. I'd just need enough permissions so I'd see the editors, no admin stuff. Use my contact form to send details if you don't want them to be public.

I have reinstalled FCK for you and configured only with one plugin (picture) and tried - it worked ....
I now have to test if it has to do somethig with plugins ...
Quite funny

Oh no - after clearing cache (I think with cached ck library it works) I can reproduce it - I will send data