This is a migrated thread and some comments may be shown as answers.
IE9 and IE10 do not return appropriate element from RadEditor with Custom ContextMenu
7 Answers 20 Views
This is a migrated thread and some comments may be shown as answers.
Richard
Top achievements
Rank 1
Richard asked on 10 Feb 2014, 05:18 PM
Hello;

There is a bug in Telerik with IE9 and IE10 where the incorrect element is returned from editor.getSelectedElement() (or any related method) for the OnClientCommandExecuting event handler when trying to execute a custom context menu command. This issue is specific to the RadEditor control.

Instead of returning the element the conext menu is fired on, the method returns the root element of the content. I have also posted about this in the following thread: http://www.telerik.com/forums/permalink/IODUuF6XbEygesw-KqOMSg, however since that is not my thread and the title is misleading, I am creating a new post here.

I have verified that the correct value is returned in IE8, and in the thread linked above your developers posted proof that the correct value is returned in Firefox. I have also tested our implementation in Firefox and the correct element is returned as well. From what I can tell this issue is specific to IE9 and IE10. Please advise on a solution as we have a critical issue in production related to this.

Our application requires Internet Explorer due to other 3rd party dependencies so choosing a different browser is not a viable workaround for us.

Thanks,

Richard Shadman

7 Answers, 1 is accepted

Sort by
0
Ianko
Telerik team
answered on 11 Feb 2014, 07:48 AM
Hi Richard,

I tried to reproduce with the following scenario and the latest available version of Telerik UI for ASP.NET AJAX, but to no avail. Please review this screencast and let me know if I am missing something important.

<telerik:RadEditor runat="server" ID="RadEditor1">
    <Content>
        <div id="parent">
            <a href="#">Link</a>
        </div>
    </Content>
    <ContextMenus>
        <telerik:EditorContextMenu TagName="A">
            <telerik:EditorTool Name="CustomTool" />
        </telerik:EditorContextMenu>
    </ContextMenus>
</telerik:RadEditor>
 
<script type="text/javascript">
    Telerik.Web.UI.Editor.CommandList["CustomTool"] = function (commandName, editor, args) {
        var selElement = editor.getSelectedElement();
        alert(selElement.outerHTML);
    };
</script>
 

Regards,
Ianko
Telerik
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the UI for ASP.NET AJAX, subscribe to the blog feed now.
0
Richard
Top achievements
Rank 1
answered on 11 Feb 2014, 12:33 PM
Hello Lanko;

Thank you for your reply. The version we are using (should have been included in my original post, sorry) is 2010.1.519.0. I had thought it was a a more recent version - I have been working with our development teams recently to upgrade 3rd party dependencies more often, however this particular app is one of our older apps that is earmarked for an older end of life.

Do you possibly have a workaround for this version?

Thanks,

Rich
0
Richard
Top achievements
Rank 1
answered on 11 Feb 2014, 12:43 PM
I've just talked with the project manager, and it looks like we can assign a resource to handle upgrading Telerik to the latest version for this project. With that in mind, I don't think a workaround will be necessary anymore. Thank you!
0
Richard
Top achievements
Rank 1
answered on 11 Feb 2014, 08:16 PM
I've upgraded the project to version 2013.3.1324.40 and we are still seeing the same behavior. I have tried  implementing the code both using the OnClientCommandExecuting event handler and following your example posted in this thread. In both cases the wrong element is returned.

I have learned something new about the issue. it isn't necessarily the root element that is returned. It is the element at the location of the cursor. When testing generally I never moved the cursor from the original position at the top of the document, so the entire body is usually returned. If i move the cursor by clicking elsewhere in the document, that element is returned when I right-click on any anchor tag and choose a custom command.
0
Richard
Top achievements
Rank 1
answered on 11 Feb 2014, 08:41 PM
OK I have it figured out. the issue in IE9 and IE10 has to do with the fact that contentedtitable on these anchor tags is set to false. This is because they are inserted as links through a custom command and are meant to be used to fire a dialog window for reference (via the context menu command).

This worked fine in IE8. It seems the behavior of this has changed in IE9 and forward. Do you know of a way around this dilemma?
0
Richard
Top achievements
Rank 1
answered on 11 Feb 2014, 08:45 PM
<telerik:RadEditor runat="server"
    ID="RadEditor1">
   <Content>
        <div id="parent">
            <p>Text1</p>
            <a href="#" contenteditable="false">Link</a>
        </div>
    </Content>
    <ContextMenus>
        <telerik:EditorContextMenu TagName="A">
            <telerik:EditorTool Name="CustomTool" />
        </telerik:EditorContextMenu>
    </ContextMenus>
</telerik:RadEditor>
<script type="text/javascript">
    Telerik.Web.UI.Editor.CommandList["CustomTool"] = function(commandName, editor, args)
    {
        var selElement = editor.getSelectedElement();
        alert(selElement.outerHTML);
    };
</script>

The above example will demonstrate the issue. Run that in IE9 or IE10, click on the 'Text1' and then right-click on the link and choose the custom command from the context menu. You will see that the Text1 element is alerted.
0
Ianko
Telerik team
answered on 13 Feb 2014, 10:46 AM
Hello Richard,

You are correct, the getSelectedElement does not work when the anchor element is set with contenteditable="false" attribute. Although, note that the reason for that is because the cursor of the editable content cannot be placed in the link due to the default click handler.

Investigating further this issue with a simple editable iframe, I am able to reproduce the same problem. You can find attached a simple HTML page with an editable iframe, so that you could examine further that this is a browser behavior. I regret to inform you that without placing the cursor in the desired element, the logic of the getSelectedElement cannot get this element, because the browser selection is not changed.

Unfortunately such behavior, that comes from the browser logic cannot be handled through the controls' implementation and I can suggest only using anchor elements without the contenteditable="false" attribute.

Regards,
Ianko
Telerik
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the UI for ASP.NET AJAX, subscribe to the blog feed now.
Asked by
Richard
Top achievements
Rank 1
Answers by
Ianko
Telerik team
Richard
Top achievements
Rank 1
Share this question
or