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.

RadEditor's content is messing up when links are generated through document manager and submit it from Preview mode. The issue is reproducible in Internet Explorer 7

However, a possible workaround for the issue would be to set the following code the OnClientSubmit event of the RadEditor:

<telerik:RadEditor OnClientSubmit = "OnClientSubmit" />
 
<script>
   function OnClientSubmit(editor)
   {
   editor.set_mode(1); //Force design mode
   }
</script>

Inline commands such as bold, italic, underline doesn't trigger each time with empty selection in Internet Explorer.

The paste functionality in RadEditor does not work when EnableTrackChanges property is set to true.  This behavior is observed under Chrome and Safari.

When text is pasted in RadEditor with ContentAreaMode="Div" under Firefox and Chrome, the cursor will be positioned before the pasted text.

In the ImageManager when using AsyncUpload as the upload manager control, the uploaded image is not selected. This prevents a fluent workflow of upload and insert of the image.

The image preview should react in a contextual way when deleting the image as well. Then the previewer should stay empty as is the case with a first load of the dialog.

The StripFormattingOptions feature does not work when the ContentAreaMode is set to Div mode. This behavior is introduced only in Chrome, Firefox and Internet Explorer 7.

 If there are textarea tags or style tags in the HTML content of RadEditor, after completing the spell check  the content is repeated several times. 

The Bold, Italic, Underline, Subscript and Superscript commands do not work in a combination with EnableTrackChanges="true" and ToolbarMode="RibbonBar".