Opened 17 years ago
Closed 17 years ago
#1654 closed Bug (fixed)
E.contentWindow.document.body.innerHTML does not exist
Reported by: | Jörg Roßdeutscher | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | FCKeditor 2.6 |
Component: | General | Version: | FCKeditor 2.5 |
Keywords: | Review+ | Cc: |
Description (last modified by )
Line 48 in fckeditor_gecko.js gives me an error in Firefox with FCKeditor release 2.5.
I tracked it down to:
if (E.contentWindow ) E.contentWindow.document.body.innerHTML='';
Even I don´t know exactly what´s happening here the "style" seems not to be clean for me: Checking if an object exist and then accessing two levels deeper than checked.
I changed to:
if (E.contentWindow && E.contentWindow.document && E.contentWindow.document.body ) E.contentWindow.document.body.innerHTML='';
and now everything works as expected.
Attachments (3)
Change History (12)
comment:1 Changed 17 years ago by
Changed 17 years ago by
Attachment: | fckeditorcode_gecko.js added |
---|
mentioned file with applied changes
comment:2 Changed 17 years ago by
Description: | modified (diff) |
---|---|
Keywords: | Pending added |
Version: | → FCKeditor 2.5 |
What are you doing to get the error?
What's your version of Firefox?
Did you make any other changes?
Before applying any changes it's better that we can understand exactly what we are doing, and besides that, the changes need to be done to the _source files as any changes to the compressed file that you have uploaded will be lost automatically.
comment:3 Changed 17 years ago by
Sorry for incomplete informations. Firefox 2.0.0.11 for Mac OS X.
We have indeed applied changes to FCKeditor, but only in sections that should not have to do anything with the problem (Upload path in the filemanager etc…)
I use FCKeditor in our internal CMS. The envirnoment is huge, it´s impossible to document everything that´s a bit special here: The editor is inside an hidden div, is created on the fly as needed, can be flipped with another editor dynamically… so, I cannot provide a testcase. But I can provide debugging informations.
I restored the code the way it was and catched the error:
try { if (E.contentWindow) E.contentWindow.document.body.innerHTML=''; } catch (errr) { alert(E.tagName + " | " + E.id + " | " + errr); }
The Tag that is causing the message is the IFRAME tag. The error message is: Type Error: E.contentWindow.document.body has no properties
Now I try to find out, where in hierarchie the object starts to be undefined.
alert(E.contentWindow);
E.contentWindow does exists and is "Object Window"
E.contentWindow.document exists and is "Object HTML document"
Finally:
alert(E.contentWindow.document.body);
results to "null".
OK. We don´t have a body here. But what do we have? I make a list of childNodes that indeed exist:
try { if (E.contentWindow) E.contentWindow.document.body.innerHTML=''; } catch (errr) { for(zzz=0 ; zzz<E.contentWindow.document.childNodes.length ; zzz++ ) { alert(E.contentWindow.document.childNodes[zzz].innerHTML ); } }
I unfortunately can´t copy the content of alert boxes in Mac OS X, but I only get one reply, and that is a HEAD section. No BODY. I upload a screenshot. The HEAD section contains a customized css file. To be on the safe side I remove our css:
FCKConfig.EditorAreaCSS = '' ;
That does not remove the problem.
So, finally, I simplyfy my workaround to
if (E.contentWindow.document.body ) E.contentWindow.document.body.innerHTML='';
That solves it for me, but does not explain the problem. Please let me know if I can help any further.
Bye, Jörg
Changed 17 years ago by
Attachment: | screenshot.gif added |
---|
comment:4 Changed 17 years ago by
P.S.: The problem also occurs under Windows, tested with Firefox 2.0.0.4 (Mac was the recent 2.0.0.11 one)
comment:5 Changed 17 years ago by
In the meantime we found out that
if (E.contentWindow.document.body ) E.contentWindow.document.body.innerHTML='';
broke sourcecode-mode, so we reverted back to
if (E.contentWindow && E.contentWindow.document && E.contentWindow.document.body ) E.contentWindow.document.body.innerHTML='';
Changed 17 years ago by
Attachment: | 1654.patch added |
---|
comment:6 Changed 17 years ago by
Keywords: | Review? added; Pending removed |
---|
The code ratti is talking about has been introduced with [770], which aims to restrict memory leaks when switching between WYSYWYG and Source views.
The proposed patch removes [770]. I was not able to detect any difference or improvement with those lines of code.
As we don't have a ticket for [770], I couldn't find any information on how to detect that leak. Maybe Martin has further to say about it.
In any case ratti, we are not able to reproduce the problem, which makes any attempt to fix this ticket senseless. Also, does it happen when loading the editor, or when doing some kind of operation on it?
comment:7 Changed 17 years ago by
We have a CMS where you can click pencils to edit HTML elements. The js errormessage appears immediately when the editor opens, and it does not contain the HTML code it should contain. The sourcecode was completely empty until the last release two weeks ago. Now it contains
<br type="_moz" />
, but that appears in every empty editor sincle last release, so I think we should count it as „empty“.
To create the editor a lot dynamic html/js is done, the editor is a hidden layer inside other hidden layers. That might be the reason why my problem is not reproducable. For example, my style menue doesn´t have scrollbars while it has if I just plain use the editor. FCKeditor seems to behave differently when made invisible/visible.
I can offer to setup an empty CMS website where you can see the problem in action. But since I have to create an admin account I would not do that in a public bugtracker.
comment:8 Changed 17 years ago by
Keywords: | Review+ added; Review? removed |
---|
The fix in [770] doesn't seem to do anything to help the memory leak problem. So it's reasonable to remove it in order to fix this bug.
comment:9 Changed 17 years ago by
Milestone: | → FCKeditor 2.6 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed with [1405]. Click here for more info about our SVN system.
The bugtracker deleted the two quote characters from my report. The string is set empty after the equal sign.