This is a migrated thread and some comments may be shown as answers.

Problems with Input Controls in Content Area

6 Answers 156 Views
Editor
This is a migrated thread and some comments may be shown as answers.
Jeff
Top achievements
Rank 1
Jeff asked on 13 May 2010, 08:38 PM
Good Afternoon,

I'm trying to do something a bit tricky: Embed input controls within the content area.

This is a big problem in Firefox and Opera. Other browsers can handle it.

Here's what I've found:

  • Firefox and Opera: Content within <textarea> is simply not selectable or editable. Additionally, in Firefox, buttons don't fire their onclick event.
  • Internet Explorer: Clicking once selects the control. Clicking again allows you to edit or manipulate. This is acceptable.
  • WebKit: Works beautifully. Click inside a textarea to edit. Click a button to fire the onclick event. This is how I wish the rest worked.

I have tried all kinds of Mozilla extensions to no avail, including: -moz-user-modify: read-write; -moz-user-focus: normal; -moz-user-input: enabled; -moz-user-select: text.

Is there a way to get input controls working Firefox and Opera?

Here's some sample code:
<%@ Page Language="C#" %> 
<%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="telerik" %> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml"
<head id="Head1" runat="server"
    <title>Untitled Page</title> 
</head> 
<body> 
    <form id="form1" runat="server"
        <asp:ScriptManager ID="ScriptManager" runat="server"></asp:ScriptManager> 
        <telerik:RadEditor runat="server" ID="RadEditor" Width="100%" 
            Height="350px" EditModes="Design" Enabled="true"
            <Content> 
                <p>Some text</p> 
                <textarea rows="5" cols="40">Text area text</textarea> 
                <input type="button" onclick="alert('button clicked');" value="Press Me" /> 
                <input type="checkbox" /> 
                <p>More text</p> 
            </Content> 
        </telerik:RadEditor> 
        <input type="button" onclick="alert($find('<%=RadEditor.ClientID%>').get_html(true))" value="Show HTML" /> 
    </form> 
</body> 
</html> 
 

6 Answers, 1 is accepted

Sort by
0
Rumen
Telerik team
answered on 14 May 2010, 01:00 PM
Hello Jeff,

Under Firefox you cannot click in an input element or change the checkbox state when it is inside the editor's content - this is a browser limitation.

You can easily verify this by testing any other web editors or editable IFRAMEs in Firefox. You can test the attached EditableIFRAME html page in order to see that this is a browser related behavior not controlled by RadEditor.

Unfortunately, we do not have control over this behavior and override it.

I found in the past that it is possible to check the checkboxes in Preview mode and programmatically apply the changes to the checkboxes in Design mode. For your convenience I have attached here a sample aspx page demonstrating how to implement this feature. You can try to write a similar solution for the textarea elements.

BTW I recently I posted a comment about this issue in the following BugZilla link. Here it is: Comment #4 From speedo 2008-10-16 05:48:52 PDT (-) [reply] -------

In Firefox 2.x and 3.x it is not possible to select and check-in/out the

checkbox input elements inside the editable DIV / IFRAME elements. Here is an

example:


<div style="border: 1px solid red;width: 500px;height:300px;overflow:scroll;" id="editableDIV" contenteditable="true">
    <input type="checkbox" />
</div>

Put this DIV in a standard HTML page and load it in Firefox -> click on the
checkbox and you will see that it could not be checked. The context menu did
not show as well.

<!--[endif]-->

Best regards,
Rumen
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Jeff
Top achievements
Rank 1
answered on 16 May 2010, 08:58 PM
Yes, I do see the behavior when I simply create an IFrame with designMode=On.

The solution seems simple: Turn designMode off when an input control has focus.

I was able to do this using editor.enableEditing(false) and editor.editable = false. Unfortunately, it didn't work consistently. I'm not sure why.

Here's the code I was working with (along with some other things I tried commented out). Would you be willing to experiment with it and see if you can get it working?
        <script type="text/javascript"
            var TheEd = null
            function ClientLoaded(editor, args) 
            { 
                TheEd = editor; 
                TheEd.editable = false
                //var conarea = TheEd._getTextIframe().contentDocument; 
                //conarea.designMode = "Off"; 
                //TheEd.enableContentArea(false); 
                //TheEd.enableEditing(false); 
 
                editor.attachEventHandler("click"
                    function(e) 
                    { 
                        var targ; 
                        if (!e) var e = window.event; 
                        if (e.target) targ = e.target; 
                        else if (e.srcElement) targ = e.srcElement; 
                        if (targ.nodeType == 3) // defeat Safari bug 
                            targ = targ.parentNode; 
 
                        if (targ.nodeName == "TEXTAREA"
                            TheEd.editable = false
                        else 
                            TheEd.editable = true
                    } 
                    ); 
            } 
</script> 

0
Dobromir
Telerik team
answered on 18 May 2010, 03:13 PM
Hi Jeff,

The problem with active input elements is caused by the different behavior of the different browsers. Regarding the provided JavaScript code, I noticed that you are trying to access non-existent property of RadEditor - ThEd.editable = true / ThEd.editable = false. In order to set the mode of the RadEditor's content area you need to use the set_editable(true) / set_editable(false) client side method. Also, when the designMode is set to on, the FORM elements do not raise any DOM events.

For your scenario I recommend you to add a custom tool to the RadEditor's toolbar to toggle designMode of the content area's document, e.g.:
<telerik:radeditor ID="RadEditor1" runat="server">
    <Tools>
        <telerik:EditorToolGroup>
            <telerik:EditorTool Name="ToggleDesignMode" />
        </telerik:EditorToolGroup>
    </Tools>
</telerik:radeditor>
<script type="text/javascript">
    Telerik.Web.UI.Editor.CommandList["ToggleDesignMode"] = function (commandName, editor, args)
    {
        editor.set_editable(!editor.get_editable());
    }
</script>

Unfortunately, at present, I cannot offer another suitable workaround to this behavior.

Sincerely yours,
Dobromir
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Jeff
Top achievements
Rank 1
answered on 18 May 2010, 07:04 PM
Hi Dobromir,

Thank you for introducing me to set/get_editable. I found editor.editable by inspecting the editor in Firebug but I guess it's not a Telerik property.

Getting the click event is not a problem. It fires whether designMode is on or off.

The problem is .set_editable(false) is unreliable when called from the click event. It works every time when called from custom tool that you suggested I create.

Is this something you can debug to see why it fails when calling it from the click event?

Thanks,
Jeff



0
Dobromir
Telerik team
answered on 20 May 2010, 04:29 PM
Hi Jeff,

The click event is unreliable because of couple of reasons:
  1. By default, RadEditor has already attached a click handler, which is calling set_editable() and it is actually fired twice. This can be prevented by manually canceling the execution of the default handler by calling $telerik.cancelRawEvent(e); at the beginning of the custom handler.
  2. When you click on the check-box to enable it, the event "click" of the editor's content area will be fired again. 

Kind regards,
Dobromir
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Jeff
Top achievements
Rank 1
answered on 21 May 2010, 06:57 PM
Hi Dobromir,

Thanks for the tips, especially canceling the RadEditor click event. That makes a lot of sense.

I will see if I can do something with it.

Jeff
Tags
Editor
Asked by
Jeff
Top achievements
Rank 1
Answers by
Rumen
Telerik team
Jeff
Top achievements
Rank 1
Dobromir
Telerik team
Share this question
or