In Q2 2013 the block commands in RadEditor were greatly improved to match desktop editors closely. This means that now block elements like <p> or <div> are required for operations like creating lists, indent/outdent commands.

The default value for the NewLineMode property of the control is BR for historical reasons and thus when the end users press enter they do no longer create elements the block commands can work with. Changing it would be a breaking change, however.
Here is a list with possible implications of changing the default NewLineMode value to P:


Pros:
- The default text editing in modern browsers according to HTML5 specifications (https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command) requires that a paragraph is inserted when enter is pressed
- The content generated by the end users by default will integrate better with the improved commands of the control
- Most desktop rich text editing applications (like MS Word) insert a paragraph when enter is pressed


Cons:
- A breaking change in the current control behavior and configuration
- When paragraphs are inserted they will add more margins so the final appearance of the content and the editing process will require more height
- By default, the underlying rich-text editing engine of Firefox uses BR tags and Chrome's - DIV tags


Please use the buttons on the right to vote whether this change should be implemented. If you have anything to add - the comments below can be used.

Take a look at www.pasteboard.co/. It works fine in all major browsers except for IE.

Image content is inserted right in the image tag like: <IMG SRC="data:image/png;base64,...">, and that's exactly what we need. We don't even need the pasted images to be uploaded to the server side.

It seems www.pasteboard.co/ doesn't rely on the canvas element. You can remove it, and everything will work fine. Please see http://screencast.com/t/8IHQfHvq0e.

Also please see www.snag.gy. It doesn't contain a canvas, but still works well.

You can also take a look at strd6.com/2011/09/html5-javascript-pasting-image-data-in-chrome. It doesn't look great because it works in Chrome only. But still it works in Chrome.

AutoResizeHeight functionality is not working correctly under IE, Chrome and Opera, when it is set to true.

Behavior:
Under IE: Editor is not resized when content is deleted.
Under Chrome: Editor's content area is resized to cover the space but the editor preserve its height.
under Opera: Editor keeps expanding when removing content.

When you use the ApplyClass command to set CSS classes to selections in a paragraph element in the content of RadEditor, the CSS class is applied to the whole paragraph.

When a partially copied table is pasted into the Editor in Chrome, it is pasted wrapped in the folloing div, making it not visible:

<div class="telerik_paste_container" style="border-width: 0px; position: absolute; overflow: hidden; margin: 0px; padding: 0px; left: 3px; top: 215px; width: 1px; height: 1px;">
...
</div>


Steps to reproduce:
1. Open http://demos.telerik.com/aspnet-ajax/editor/examples/overview/defaultcs.aspx
2. Clear the contents of the editor
3. Insert a table (any configuration of rows and columns) 
4. Go to a new line
5. Type a word on the new line
6. Select the word and a partial amount of the inserted table
7. Copy
8. Paste
9. Navigate to the HTML browser of the editor
10. Observe the "telerik_paste_container" still wrapping the pasted content

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

<script type="text/javascript">
	var editorPrototype = Telerik.Web.UI.RadEditor.prototype;
	var onAfterPaste = editorPrototype._onAfterPaste;
	editorPrototype._onAfterPaste = function (range, tmpPasteContainer) {
		try {
			onAfterPaste.call(this, range, tmpPasteContainer);
		} catch (e) { }
		$telerik.$(this.get_contentArea()).find(".telerik_paste_container").remove();
	};
</script>

Feature request for implementing an improvement related to the current impossibility to select form elements like buttons in RadEditor content area. This is a browser behavior and it is currently preventing form editing element's properties in the module manager.

When trying to insert list in a table, the list is inserted outside the td tag.
Switching between Html and Design tag causes the list to be removed from the table.

Adding the following link should not change the URL:

http://test.com?a=bc%3do

An additional <br /> element is inserted in the editor when the following steps are executed:

1. Make sure ConvertToXhtml filter is turned on.
2. Switch the editor in HTML mode
3. Set the HTML bellow:
<div class="line1">first line of text</div>
<div class="line2">lastlineoftext</div>

4. Switch back to Design mode.
5. View the HTML using Module Manager - Real Time HTML Viewer
Expected HTML:
<div class="line1">first line of text</div>
<div class="line2">lastlineoftext</div>

 Actual HTML:
<div class="line1">first line of text</div>
<div class="line2">lastlineoftext</div><br>

 

Currently the <br> element cannot be removed from the HTML code of the content. This element exists by design and it is inserted in the editable iframe by the browser. The <br> element is used as a non-breaking line, which means that the following row can be selected and characters can be typed in it. If such element does not exist, the users will be unable to select the first row of the content area and start typing. 

The ConvertToXhtml filter actually removes this element when switched to HTML mode and retrieves it back as a last child of the <body> element, due to the above mentioned reasons. 

If you have issues with the retrieved content via the get_html() method, note that stripped content is returned when the method is used with an argument value "true".

editor.get_html(true) - returns the HTML content, stripped by the set filters.

editor.get_html(false) or editor.get_html() - returns the raw HTML content as it is currently. The same as the editor.get_contentArea().innerHTML property. 
 
 WORKAROUND:
Disable ConvertToXhtml filter in codebehind:
RadEditor1.DisableFilter(EditorFilters.ConvertToXhtml);

For example the Bold, Italic, Underline and Strike-trough commands are not accepted by invoking the AcceptTrackChanges() method. After the post back, the track changes stylization is still the same and the attributes set from the feature (cite, author, timestamp etc.) are not stripped. 

A possible workaround is using the corresponding method via the Client-side API. To do that you can use this example JavaScript method:

function acceptAllChanges() {
    var editor = $find("<%= RadEditor1.ClientID %>");
    var trackChanges = Telerik.Web.UI.Editor.TrackChanges;

    trackChanges.initialize(editor);
    trackChanges.acceptAllChangesSilently();
}

Note that you should get the correct editor object and pass it as an argument in the initialize() method's overload. 

Repro steps:    
    open Edge 41 (creator's update brings it)
    start an editor, e.g.: <telerik:RadEditor ID="RadEditor1" runat="server"></telerik:RadEditor>
    type "ab"
    press enter
    type "cd"

Actual: the second paragraph contains only "d"

Expected: the second paragraph contains "cd"

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.