Disable drag and drop of BODY element in content area Iframe

[Paul Robertson]

Hi all

I have a radEditor which has suddenly for some reason developed the habit of displaying handles on the content area when the user clicks on the content area to start typing. Specifically, it appears that these are selection handles, for moving and /or resizing, which appear on the BODY element inside the Iframe of the content area. I'm not exactly sure what change could have been made to the radEditor code to cause the BODY element to begin behaving like this, but I'm assuming that I need to use Javascript on the radEditor elements to explicitly disable this behaviour.

I have so far been working on the basis that I need to use addExternalHandler on the Iframe element, to disable drag and drop behaviour of the BODY element within that IFrame, but I can't get this to work in the way I was expecting, using a client-side OnClientLoad event handler for the radEditor in question - and no amount of research has revealed a relevant answer. This is what I have so far, which I have found from piecing together other info on the forum etc, and which runs OK and gives no error ... but also seems to have no effect on the problem: the OnClientLoad function is as follows, with input parameters 'editor' and 'eventArgs' from the event:

var contentelement = editor.get_contentArea;  //gets reference to content area BODY element 

var myeditoriframe = contentelement.parentNode.parentNode;   //navigates up to the iFrame object

var myevent = myeditoriframe.all ? "drop" : "dragstart";  // *** I think this is the problem line!! ****

$telerik.addExternalHandler(myeditoriframe, myevent, function(e) {

      $telerik.cancelRawEvent(e);

      return false;

});

But the 'addExternalHandler' function never appears to run when the content area is clicked, so it looks like I am either not constructing the external handler parameter object 'myevent' correctly, or that this is simply the wrong approach to addressing this issue! 

Would it be possible for somebody to point me in the right direction with this problem. If you could help me out I would be enormously grateful!

Many regards

[Paul Robertson]

PS I've also tried the .childNodes property instead of .all, as I have been led to believe .all is only found in IE - no difference though ... perhaps there is some fundamental limitation of catching iframe events in this way?

PPS I should have mentioned that I also tried this approach originally just using the reference to the editor object instead of the iframe, but this doesn't work either:

var myevent = editor ? "drop" : "dragstart";  

$telerik.addExternalHandler(editor, myevent, function(e) {

       $telerik.cancelRawEvent(e);

       return false;

});

[Rumen]

Hello,

Do you experience this behavior in IE only? Could you please provide a screenshot or video demonstrating the occurring behavior?

The issue could be due to that you have applied any of the hasLayout causing CSS properties below:

CSS property	Value
display	inline-block
height	any value
float	left or right
position	absolute
width	any value
-ms-writing-mode	tb-rl
zoom	any value

If at least one of the above properties is set to an HTML element, as it looks in your case to the BODY tag, it will cause it to have a layout and to edit it the user should double click on it and the resize handlers along with a border will appear. The hasLayout is an IE feature that cannot be disabled. It is also not supported by the other browser vendors. You can find more information about this browser functionality in the following MSDN article: http://msdn.microsoft.com/en-us/library/ms533776%28VS.85%29.aspx. You will experience this behavior in all DHTML based competitors' editors as well as in the standard editable IFRAME / DIV elements.

The only possible way to stop the hasLyaout feature of Internet Explorer is to make sure that none of the above CSS properties are applied to the HTML elements in the content area.

Best regards,
Rumen
the Telerik team

[Paul Robertson]

Hi there

Thanks for the info. Unfortunately, the symptom I have is shown in Firefox - I attach a screen grab of the handles in question, and also a second image that shows how the browser is letting the user drag and drop/resize the BODY element within the iframe, a 'feature' which I am also trying to disable - presumably this is just a different side to the same problem, and requires the same solution as that for disabling the selection handles in the first place. 

Unfortunately it does not appear that any of the CSS you mention is being applied to the BODY element, except that there is a height: 100% apparently leaking through from the parent document. But surely that is not a cause of the handles in question? I was under the impression from similar forum threads that this sort of problem could not be addressed directly through applying CSS, and had to be corrected with Javascript using the onclientload editor client-side event. I didn't think it was possible to manually attach individual style attributes to the radEditor BODY element, or isolate the readEditor CSS completely from the parent document, but if this is the case perhaps there is an example that I could be pointed at? At the moment I have an external content area CSS file that I programmatically attach server-side at the Load event, so if there is a CSS solution, presumably I should be modifying the styles in that file ...

I notice in firebug that Firefox is adding two properties to the BODY element: _moz_resizing = "true" and _moz_abspos="white" ... this seems a little suspicious - does anyone know where these properties arise from, and if they might cause the symptoms I am seeing?

Regards

[Rumen]

Hi,

Can you try to set the CssFiles property to point to an empty CSS file so that not external stylesheet is applied to the content area as shown in this article: Content Area Appearance Problems?

If the problem still persists, try to reproduce it in the live demos of RadEditor and isolate it in a simple working project and send it for examination on our end.


Best regards,
Rumen
the Telerik team

[Paul Robertson]

Hello

Just to clarify this, do you mean that the declarative syntax in the radEditor markup, e.g:

<CssFiles>
  <telerik:EditorCssFile Value="~/DummyEditorContentArea.css" />
</CssFiles>

can be used in combination with a programmatically added CSS file, but that using the declarative syntax is the only way of overriding the inheritance of styles from the parent page? If I understand correctly, you are advising me to try pointing the declarative markup (as above) to a dummy file through the declarative syntax, to block style inheritance, and that this will also allow me to keep my existing programmatically added stylesheet, to which I can then make any changes as necessary to fix the problem, free from complications from the parent page styles?

Thanks if you can clarify this for me ...

Regards

[Rumen]

Hello,

If doesn't matter whether the CssFiles property is set in the codebehind or inline. Just set it to point to an empty css file, and see whether the problem still persists. By setting this property, the editor will not pick up the styles from the page and they will not change the appearance in the content area.

All the best,
Rumen
the Telerik team

[Paul Robertson]

Hi there

I've come to the conclusion that the CSS approach might be a bit of red herring, in that I think the problem is more to do with a glitch in Firefox, in that it switches on object resizing for the BODY element because the Iframe is set to contentEditable. The symptom of this is that the _moz_resizable='true' property is added to the BODY element. I'm still not sure why Firefox wasn't doing this to me before, but even so, the way I finally got rid of the property and the resize handles was to run the 'enableObjectResizing' command on the editor Iframe. I am doing it like this:

(where 'editor' is a variable reference to the editor control obtained using $find ... )

setTimeout(function(){

     var mydoc = editor.get_document();

     mydoc.execCommand('enableObjectResizing', false, 'false');

} , 500);

The execCommand evidently has to be delayed in a timeout because it only seems to work if all other initialization and CSS formatting has been completed.

There is still a small rectangular block highlighted in the top left hand corner, but this is not a resize handle - does anybody have an idea where it is originating from, or how to remove it? (Screen grab included)

Regards

[Rumen]

Hello,

The rectangular box looks like the handler that Firefox renders when some elements has applied style="position:absotute". For example select an image in the content area, click on the Set Absolute Position button of RadEditor, and the handler will be rendered over the image. Using it the user can drag the image in the content area of the editable iframe.

Kind regards,
Rumen
the Telerik team