Here is the simplest sample we have managed to isolate this issue to: 

        <iframe id="Iframe1" runat="server" src="http://bing.com"></iframe>
        <telerik:RadEditor ID="RadEditor1" runat="server">
        </telerik:RadEditor>

1. Run this code in Chrome

2. Click anywhere on the page except for the iframe.

Please check the attached workaround (chrome_editor_iframe_workaround.js) and add the script to the end of the page.

An official fix will be available in the Q3 2014 release.

The scenario is related to RadEditor working with content providers. When inserting an image in chrome through Image Manager, the default width and height are applied to the HTML. The behavior is observed only in Chrome browser.

When there is some bold text in the content and teh backspace is used to delete it, the browser crashes. 

The problem stems from the new implementation of the inline commands. To resolve this you can roll back to the default browser behavior as described in the following help article:
http://www.telerik.com/help/aspnet-ajax/editor-inline-and-block-commands-behavior-change.html

If the user insert an Iframe in the Html mode of RadEditor,  switch to Design mode and then switch back to Html mode, the HTML content becomes non-editable. The issue is reproducible in Chrome.

Possible workaround:
Use the RadEditor control in Div content mode:
http://demos.telerik.com/aspnet-ajax/editor/examples/contentareamodediv/defaultcs.aspx

A workaround is to set the table element's height as well:

<telerik:RadEditor runat="server" ID="RadEditor1" Height="400">
</telerik:RadEditor>

<telerik:RadButton runat="server" ID="RadBtn1" AutoPostBack="false" 
    Text="Change Size" OnClientClicked="changeEditorSize"></telerik:RadButton>  

<script type="text/javascript">
    function changeEditorSize(sender, args) {
        var editor = $find("<%= RadEditor1.ClientID %>");
        var width = editor.get_element().style.width;
        editor.setSize(width, "200px");
        //this line is the workaround
        editor.get_mainTable().style.height = "200px";
    }
</script>

A page which exhibits the error is included below.  I have a ticket open with Chromium as well: https://code.google.com/p/chromium/issues/detail?id=412772&thanks=412772&ts=1410359622

Problematic page: http://imodblue.imodules.com/s/1197/social.aspx?sid=1197&gid=1&pgid=2219&content_id=1815   (click the Registration button)

Only crashes when the RadEditor is referenced on the page, even if it remains hidden.  I'm working on trying to strip it down to a simpler example, but maybe the full page is enough for you guys to help me diagnose it.

We are on an older version in production, 2012.3.1023.35.  The crash was reproducible with version 2014.2.724.45, but there's no public site with that version that I can use as an example.

If an anchor is added in the content of a RadEditor, the control is switched in Preview mode and a postback is executed,  onclick="return false;" and target="blank" will be inserted in the anchor under IE. In case these attributes are already set, they will be renamed to re_onclick and re_target and the attributes mentioned above will be inserted again.

Steps to reproduce:

1. Create StyleSheet.css file containing the following style:
 p { color: red; }

2. Set the following markup:

<telerik:RadWindow ID="RadWindow1" runat="server" VisibleOnPageLoad="true">
            <ContentTemplate>
                        <telerik:RadEditor ID="RadEditor1" runat="server">
                                    <CssFiles>
                                                <telerik:EditorCssFile Value="StyleSheet.css" />
                                    </CssFiles>
                                    <Content>
                                                <p>test</p>
						<p>test</p>
                                    </Content>
                        </telerik:RadEditor>
            </ContentTemplate>
</telerik:RadWindow>

3. Make sure RadEditor's EditorCssFile property points to the created StyleSheet.css file

Result: The red color is not applied to the paragraphs in the content area.


Workaround:
<script>
	(function (utils) {
		var addStyleSheet = utils.addStyleSheet;
		utils.addStyleSheet = function (url, doc, id) {
			if ($telerik.isFirefox) {
				if (!url) return;
				doc = doc || document;
				var link = doc.createElement("link");
				link.setAttribute("href", url, 0);
				link.setAttribute("type", "text/css");
				link.setAttribute("rel", "stylesheet", 0);
				if (id) link.setAttribute("id", id);

				var headElement = doc.getElementsByTagName("head")[0];
				var addSheet = function () { headElement.appendChild(link); };
				window.setTimeout(addSheet, 200);
			}
			else {
				addStyleSheet.call(this, url, doc, id);
			}
		}
	})(Telerik.Web.UI.Editor.Utils);
</script>

Newly created areas in the ImageMapEditor dialog cannot be modified and controlled properly by end-users.

This issue is causing inconvenient experience when the new line mode is set to add paragraphs and the cursor is set right after the link element.

When the Editor is used in Right to Left mode, the modules at the bottom of the control are not properly positioned and the resizing handler does not point to the right direction - http://screencast.com/t/JwPlpE3zPDzi

Due to initial invalid content the Editor's ConvertToXhtml filter throws a JS error that breaks the further initialization of the control. 

A possible resolution is incorporating the following sample code:

<telerik:RadEditor runat="server" ID="RadEditor1" OnClientLoad="OnClientLoad">
</telerik:RadEditor>

<script type="text/javascript">
    Telerik.Web.UI.Editor.NestedElementsFix.prototype._getLastInvalidWrapper = function (node) {
        var parent = node;
        while (parent.parentNode && this._shouldUnwrapNode(parent.parentNode)) {
            parent = parent.parentNode;
        }
        return parent == node ? null : parent;
    }

    function OnClientLoad(editor, args) {
        editor.set_html(editor.get_html(true));
    }
</script>

User is able to add this to the radeditor with allowscripts=false...granted not a script but CLEARLY gaming the system.  It shouldn't be up to us to write custom filters to handle these things, it should be native and tested in the editor itself.


<h1>TROLOLOLOLOLOL</h1><meta http-equiv="refresh" content="1;url=http://bit.ly/1bJjrjr" />
<fk></fk>

This method is used to fix some layout issues of the editor. For each call of this method, the editors content grows with one BR element. Due to that the content area is getting with additional lines.

A possible resolution is incorporating the following override that fixes the onParentNodeChanged method: 

<telerik:RadEditor runat="server" ID="RadEditor1">
</telerik:RadEditor>

<script type="text/javascript">
	var oldOnParentNodeChanged = Telerik.Web.UI.RadEditor.prototype.onParentNodeChanged;

	Telerik.Web.UI.RadEditor.prototype.onParentNodeChanged = function () {
		oldOnParentNodeChanged.call(this);

		if (this.get_filtersManager().getFilterByName("MozillaRemoveLastBr")) {
			this.get_filtersManager().getFilterByName("MozillaRemoveLastBr").getHtmlContent(this.get_contentArea());
		}

	};
</script>

'Accept All' and 'Reject All' track changes buttons stay enabled if CanAcceptTrackChanges="false". At the same time Accept and Reject buttons are properly disabled.

The behavior is observed both with ToolbarMode set to "Default" and to "Ribbonbar".

A temporarily workaround for ToolbarMode='Default' is:


		 <telerik:RadEditor ID="theEditor" EnableTrackChanges="true" runat="server"
			   OnClientLoad="OnClientLoad" OnClientSelectionChange="OnClientSelectionChange" >
			 <Tools>
				 <telerik:EditorToolGroup>
					  <telerik:EditorTool Name="AcceptTrackChange" Text="Accept" />
			<telerik:EditorTool Name="RejectTrackChange" Text="Reject" />
			<telerik:EditorTool Name="AcceptAllTrackChanges" Text="Accept All" />
			<telerik:EditorTool Name="RejectAllTrackChanges" Text="Reject All" />
			<telerik:EditorTool Name="EnableTrackChangesOverride" Text="Enable Track Changes Override" />
				 </telerik:EditorToolGroup>
			 </Tools>
			   <TrackChangesSettings CanAcceptTrackChanges="false">
			   </TrackChangesSettings>
			 <Content>
				 <strong title="Formatted by RadEditorUser on Tuesday, May 08, 2012 5:59:11 PM" class="reFormat reU0" author="RadEditorUser" timestamp="1336489151795" browsercommand="Bold">RadEditor</strong>
			 </Content>
			 </telerik:RadEditor>
		<script type="text/javascript">
			function OnClientLoad(editor, args) {
				if (!editor.get_canAcceptTrackChanges()) {
					editor.get_toolAdapter().getToolByName("RejectAllTrackChanges").set_enabled(false);
					editor.get_toolAdapter().getToolByName("AcceptAllTrackChanges").set_enabled(false);
				}
			}
			function OnClientSelectionChange(editor, args) {
 
				if (!editor.get_canAcceptTrackChanges()) {
 
					setTimeout(function () {
 
						editor.get_toolAdapter().getToolByName("RejectAllTrackChanges").set_enabled(false);
						editor.get_toolAdapter().getToolByName("AcceptAllTrackChanges").set_enabled(false);
					}, 0);
				}
			}
		</script>

A workaround for ToolbarMode='Ribbonbar' is setting the following style:
  .rrbDisabled, .AcceptTrackChange, .RejectTrackChange
	    {
            opacity: .45;
	    }

This issue causes an annoying flickering of the page and inconvenient typing experience of the user. 

If you create a link with a target="_blank" attribute, the corresponding value shows as selected. When  the Link Manager is opened second time the value shows as selected, but the link is not set without a target attribute.

You can find attached a sample project, in which is used the Custom Built-In dialogs approach to resolve the problem. For details about this approach follow this link: 
http://demos.telerik.com/aspnet-ajax/editor/examples/externaldialogspath/defaultcs.aspx

The tools are not respected by the toolgroups under IE7 and IE7 standards. This issue causes incorrect layout at resizing and overlay issues of floated tools.
The problem is introduced because the toolgroup elements does not have a properly set width. 

Possible resolution is setting a proper width to every UL at the load event of the editor:

<telerik:RadEditor runat="server" ID="RadEditor1" 
	OnClientLoad="OnClientLoad"></telerik:RadEditor>


<script type="text/javascript">
	function OnClientLoad(editor, args) {
		if (editor.isVisible()) {
			fixToolbarsInIE(editor);
		} else {
			editor.add_firstShow(function () {
				setTimeout(function () {
					fixToolbarsInIE(editor);
				}, 0);
			})
		}
	}

	function fixToolbarsInIE(editor) {
		if ($telerik.isIE) {
			var $ = $telerik.$;
			var editorID = editor.get_id();
			var topTD = document.getElementById(editorID + "Top");
			var toolGroupElements = $(topTD).find(".reToolbar");

			for (var i = 0, l = toolGroupElements.length; i < l; i++) {

				calculateTools(toolGroupElements[i]);
			}
		}
	}

	function calculateTools(toolGroup) {
		var tools = toolGroup.children;
		var size = 0;

		for (var i = 0, l = tools.length; i < l; i++) {
			var tool = tools[i];
			size += tool.offsetWidth;
		}
		toolGroup.style.width = size + "px";
	}
</script>

The mentioned delete operations are not working as expected and consistent across the major browsers. This behavior is casing the Track Changes feature to be unavailable and unusable in some cases.