radEditor Iframe content area loses CSS styles after Javascript move within DOM

[Paul Robertson]

Hi there

Most of my question is in the title, can anyone advise please? I have a radEditor that I am moving around the DOM using Javascript, so I can use the same control in different locations on the page, in a similar way to that discussed here:

http://www.telerik.com/community/forums/aspnet-ajax/editor/jquery---single-radeditor-for-multiple-editable-bodies-on-page.aspx

My particular problem is that I am using the facility for specifying in the markup, a dedicated ContentArea Iframe external CSS file, i.e.,

                        <CssFiles>
                            <trk:EditorCssFile Value="~/<pathtomyskinfiles...>/EditorContentArea.PD_RadSkin_1.css" />
                        </CssFiles>

The styles in this external file work fine, that is, until AFTER I use Javascript to perform the client-side move of the editor control within the DOM, at which stage the IFrame content reverts back to a default element styling, which Firebug for example reports as that the element has no styling at all, apparently not even in-line styles. I am calling onParentNodeChanged() on the editor after the move, as this is evidently necessary for the Iframe to reshow its content text ... unfortunately it does not seem to refresh the styling rendered from the external style sheet in question.

Any ideas have I can work around this? Thanks very much.

Regards

[Paul Robertson]

PS Forgot to mention this, which will probably be an important clue to finding the answer:

The problem does not appear if I include any sort of Javascript alert before calling onParentNodeChanged() - as you can imagine, this is making debugging any Javascript issue here rather tricky! When I dismiss the alert (any sort of alert I deliberately include), the radEditor content area then appears with the styling as expected.

[Paul Robertson]

After some research, it appears that IFrames in general are quite bad at being moved around in the DOM tree., Therefore, I have also tried to work around this problem by trying to work with ContentAreaMode = "Div", however, the control always appears to be rendered using an IFrame. Can somebody advise, when was this option to switch to a ContentArea with a 'Div' introduced, am I using an early version of RadEditor (in Telerik.Web.UI 2009.3.1208.20) that can only use an Iframe? I really would like to avoid an upgrade if possible, and all the chaos which that would cause!

 

[Rumen]

Hi Paul,

The ContentAreaMode="Div" property was introduced in Q2 2010 (version 2010.2.713), but you should know that the CssFiles property works for Iframe mode only. This property inserts a link tag(s) in the head tag of the iframe which point(s) to the specified CSS file(s) - therefore it is possible to style only the iframe content area which is not part of the current page as being a different document. The DIV content area is part of the current page and the styles are directly inherited from the page.

I investigated the problem with the CssFiles and onParentNodeChanged method and found that it appears in Firefox only. The CSS file imported through the CssFiles property was there after moving the editor in the DOM and executing the onParentNodeChanged method, but the browser did not evals it and its contents were not applied to the content area. In IE and Chrome everything was good so this leads me believe that this is a Firefox bug.

I was able to reproduce it with the following code:

<div id="div2" style="border: 3px solid red;">
<telerik:RadEditor ID="RadEditor1" runat="server">
    <CssFiles>
        <telerik:EditorCssFile value="~/styles.css" />
    </CssFiles>
</telerik:RadEditor>
</div>
<div id="div1" style="border: 3px solid blue;"></div>
<input type="button" value="Move Editor" onclick="MoveEditor();" />
<script type="text/javascript">
    function MoveEditor() {
        var editor = $find("<%=RadEditor1.ClientID%>");
        editor.onParentNodeChanged();
    }
</script>

<script type="text/javascript">
    function MoveEditor() {
        var editorContainer = document.getElementById("div2");
        document.getElementById('div1').appendChild(editorContainer);
        var editor = $find("<%=RadEditor1.ClientID %>");
        editor.onParentNodeChanged();
    }

</script>

I logged it in our bug tracking system and our developers will try to fix it. Here you can find the PITS Issue: Public URL.

I also updated your Telerik points for reporting it.

Best regards,
Rumen
the Telerik team

[Paul Robertson]

If it's any use to folks with a similar problem, I believe there is some timing factor involved in the problem. I think I managed to come up with a workaround to address the problem in Firefox, a delayed function call that runs onParentNodeChanged, which seems to remind the browser it has to redraw the iFrame:

e.g.

        var mycmnteditor = $find("[my editor client id]");
        var iframedrawdelay = 1000; // = 1s

        setTimeout(function(){  
            mycmnteditor.onParentNodeChanged();
          },iframeredrawdelay);

That seems so far to have had the required effect for me, anyway. Also you could include some lines in the function to set focus or manipulate the content here too:

e.g.

        setTimeout(function(){  
            mycmnteditor.onParentNodeChanged();
            mycmnteditor.setFocus;
            mycmnteditor.pasteHtml("");  
            mycmnteditor.undo(1);
          },iframeredrawdelay);

There is a lot more about this sort of approach here:

http://www.telerik.com/community/forums/aspnet-ajax/editor/jquery---single-radeditor-for-multiple-editable-bodies-on-page.aspx
           
Cheers

[Nazrul Muhaimin]

Hi Rumen,

Is there any update with regards to this? Because I'm facing the same issue.

Sorry for replying old post but I really need to know something on this after many try and error process failed.

rgds,
Nazrul

[Ianko]

Hi Nazrul,

The CSS file disappearance problem is due to reinitialization of the iframe of the content area.

When calling the onParentNodeChanged() method, the RadEditor destroys the content area and recreates it dynamically. Due to that, the css links added are not rendered as expected and are not synched with the load event of the inner document.

There are two options to resolve this:

1. Using the setTimeout approach as Paul described. This way the iframe is created a bit later and teh css links are loaded correctly.
2. Using further logic to remove the links from the head element of the content area and reattach them. This is a little tricky and if this approach is going to be used I suggest you testing it thoroughly for side effects.

This issue is quite complex and it is directly related to the moving of the RadEditor across the DOM. Such matter is quite specific and custom, this is why it should be handled per case.

Regards,

Ianko
Telerik