Trying to use TinyMCE 3.2.1.1 on Internet Explorer 6 causes a memory leak, i.e. CPU eatin' up all resources, memory endlessly upping until no more system memory can be assigned.
The changelog for 3.0.7 contains:
Fixed memory leak in IE where if a page was unloaded before all images on the page was loaded it would leak.
So this might be the cause - we are initializing the editor *before* the DOM has initialized. Originally, this was implemented just because of dumb IE, and even resulted in the extra JS hook "init". Hence, the first attempt to fix this issue should be to remove this initialization, resp. move it into the regular attach function.
Comments
Comment #1
trofimchouk commentedI have the same issue with IE6, Wysisyg 5.x-1.x-dev and TinyMCE 3.2.1.1
Comment #2
sunI cannot replicate this issue with TinyMCE 2, so this seems to be a bug in the library itself.
I even tried to move all the code from init() into attach(), but that did not make any difference. Also tested whether removing all but the actual editor attachment from wysiwyg.js makes a difference, but it does not.
Anyone who encounters this issue: please search the net for the keywords IE 6, TinyMCE 3, memory, leak.
Comment #3
c-c-m commentedI have also the same problem with 5.x version and TinyMCE 3.2.1.1. I have made the search Sun suggested in TinyMCE forums with no success.
Comment #4
sunI also searched for some hours, but wasn't able to find any related pages on the net. So the next step is to open a critical bug in TinyMCE's issue tracker at SourceForge (and add a link to that issue here).
Comment #5
JustinJohnson commentedIf this helps anyone at all. I also was having the same issue, and for me it seems to happen whenever I turn on the "forecolor" button.
Comment #6
chaloalvarezj commentedThank you for the hint! removing forecolor made the editor work in IE6. Is this a bug on TinyMCE or in the wysisyg_api module? I've checked the TinyMCE homepage and there is nothing about a leak..
Comment #7
livingegg commentedTurning off the "forecolor" button does not work for me, even with the button turned off it still crashes IE6.
Also, Tiny works just fine in IE6 on this page. What if we could not reproduce this bug in Tiny alone, without using WYSIWYG API? Would that indicate that this is a problem with the way Tiny is being implemented and not with Tiny itself?
Comment #8
sunWhile debugging #353406: Javascript error in IE 6 and 7 causes blank page, I stumbled over the strict_loading_mode setting, which we obviously need to enable in Wysiwyg API:
http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/strict_loading...
It is enabled by default for Gecko-based browsers, but not IE, which would explain why only IE completely hi-jacked a site.
Tested in IE6, and seems to work - even with external plugins like Image Assist.
However, I can also confirm that the Forecolor/Backcolor buttons are causing the memory leak in IE6 - disabling them makes IE work. That's strange and needs further debugging.
Comment #9
sunI committed that patch.
This leaves us with the strange memory leak when the Forecolor (and Backcolor?) buttons are enabled. Does this only happen in IE6 ?
Comment #10
mokko commentedGreat. I added that line to my 6.x-0.5 and now it works for the first time in weeks in the IE! Good work! I had the memory leak before, but not today. No forecolor.
Comment #11
sunMore precise title.
Comment #12
simeIMCE plugin button causes an error 80020101 in IE.
This may not be totally relevant to the thread, but it does hightlight that people should try disabling ALL buttons and then reenable them until they identify the culprits.
Comment #13
RusRabbit commentedThis is TinyMCE vs IE6 thing.
The solution is described here, with the patch included:
http://sourceforge.net/tracker/index.php?func=detail&aid=2619922&group_i...
Comment #14
twodThe patch mentioned in #13 was committed in 3.2.2, is this still an issue?
This looks like a pure library issue, so I'm voting for closing it (and reporting it to TinyMCE's bug tracker if it persists).
Comment #15
sunAgreed.
We should double-check whether this is still needed or wanted.
Also, I'm not sure whether I didn't remove the Forecolor button entirely due to this issue
Powered by Dreditor.
Comment #16
sunComment #17
twodI tested this again today with IE8, Chrome, Chromium and FF4. Only used the standard system/activity monitors of Win Xp and Ubuntu so this won't be the most detailed summary...
The only thing I could determine for sure was that repeatedly deactivating and re-activating the editor (via "Disable rich-text") increased IE's memory usage by at least 0.5MB on each activation. The memory did not appear to be freed until IE was closed.
Chrome on Windows seemed unaffected, or at least the persistent memory increase was minimal.
Chromium on Ubuntu ate memory at about the same rate as IE but let it (or most of it) go after some time.
Firefox on Ubuntu did not seem affected to the same extent and released memory like Chrome/Chromium.
CPU usage was about the same in all browsers and decreased to idle as soon as the [de]activation was completed.
Most importantly, I could not see a difference depending on whether the forecolor or backcolor buttons were enabled or not. I also did not notice any difference in loading speed when enabling the editor. The strict_loading_mode setting was removed in TinyMCE 3.4 and had no effect. (
grep -r 'strict_loading_mode' tinymcereveals it is indeed ignored now).I thought IE's increase in memory usage might be because it reloads the TinyMCE files from the server each time and stores them in some RAM cache, but the Fiddler tool did not detect any HTTP requests after the first activation.
My conclusion? I'd say there is still a memory leak, but it's not caused by any of the things discussed here. I can't tell if it's in TinyMCE itself or our implementation layer since I have nothing to compare to at this moment.
Comment #18
twodI'm closing this as "won't fix" because I can't think of a way to fix it from Wysiwyg's side of things that doesn't mean simply disabling whatever feature[s] causing a leak. If someone still finds memory usage growing rapidly, I'd suggest filing a bug on the TinyMCE tracker instead and linking back here.