Typing in Find dialog is not possible when having an ElementHost in a WinForms Windows to host a WPF User Control which contains the RadRichTextBox.

If I setup the richtextbox content through the UI as shown in P1.png and try to restore it by pasting the generated html, I get instead P2.png. Expected to be the same. 

I attached the sample project. We're using the recommended settings to use the same html in telerik reports, but can't find the reference on your site, it used on the on this link http://docs.telerik.com/devtools/wpf/controls/radrichtextbox/import-export/features-import-export-settings#htmlformatprovider

 

The same issue is observed with heading styles. 
The HtmlExportSettings property PropertiesToIgnore can't be used to control how the paragraph or character properties of a list will be exported.
Steps to reproduce:
Create a document with a list of different levels.
Set fp.ExportSettings.PropertiesToIgnore["li"].Add("margin-left");
Export to HTML.
Observed: The PropertiesToIgnore doesn't work for paragraph properties of a list.

Finding text with regex for the last paragraph is not possible. This is caused by the fact that the search treats the last paragraph symbol as the last paragraph.

Character properties applied on the last paragraph symbol for a paragraph in a list, e.g. font size, are not exported to HTML when StyleExportMode is Inline. 

As a side effect, when the document is imported back, and the text of the bullet is deleted, its properties switch back to the default ones.

Workaround: Change the styles to export as inline properties:
 
Please be aware that this may cause side effects, as described in this issue: RichTextBox: Character properties of the paragraph symbol are exported to HTML for the whole list item when StyleExportMode is Classes

Nested ol/ul list should be inside a <li> element of the list in which it is nested. For example:

<ul>
<li>Option A</li>
<li>Option B
  <ul>
    <li>Sub 1</li>
    <li>Sub 2</li>
  </ul>
</li>
</ul>

 

The character properties applied on the last paragraph symbol for a paragraph in a list (e.g. font family), are exported to HTML for the whole paragraph which is in the list. 

As a notable side effect, when such HTML is imported, the default font size for a paragraph in a default bullet list changes to Symbol.

Regression: The bug is introduced in 2016_2_613.


Workaround: Change the styles to export as inline properties:

but be aware that this may cause issues as described in the related RichTextBox: Character properties of the paragraph symbol are not exported to HTML when StyleExportMode is Inline

Font weight, size and other current editing style properties are not preserved when document layout is performed, for example in the following cases:
- the document is in web layout mode and the controls is resized
- scroll bar changes its visibility.

Steps to reproduce:
- Set RadRichTextBox to Web layout mode.
- Type a word, select it and make it bold.
- Press enter and type a word
- Repeat the previous step until RadRichTextBox height is reached and scrollbar appear.
- Type a word.
Expected: The last word is bold.
Actual: The last word is not bold.

Applying negative LeftIndent or FirstLineIndent of a paragraph in web layout mode will visualize the paragraph to the left of RadRichTextBox boundaries.

When importing an image, defined with a Base64 string which doesn't have its size explicitly set, it is rendered with ImageInline.DefaultImageSize instead of using its real size.

Workaround: Check the size defined in the ImageSource:

Currently table's Rows collection only accepts adding of rows that have cells.

When you first insert a table, and try to grab the right border and resize it, the result is that the inner cells resize, while the total width of the table remains the same. If you move the inner borders a bit and then try again to resize the whole table, it will work.

When the first table row of each table (main as well as nested) has RepeatOnEveryPage set, the table header of the nested table overlaps the row on the new page.

When a DOCX document contains a table with fixed layout, and the table contains <tblGrid> element with improper widths (not coinciding with the ones visualized by MS Word), and such document is imported, the table is laid out with the width of the sum of the column widths imported from the table grid (tblGrid), instead of ones that could be correctly computed by the preferred width of the table cells. 



MS Word, for example, may ignore the widths specified in the tblGrid and compute new ones.



As a side effect, fixed-width tables can be laid out longer than their preferred width.

When the MoveToDocumentElementStart is called with parameter that is PermissionRangeStart and then is called a second time, the position moves to the previous position instead.

When the user copy-pastes an image from Outlook, it is pasted as an IncludePictureField and visualized as expected. The field code looks like

{INCLUDEPICTURE :image001.png@01D15D16.4FAF0970 \* MERGEFORMATINET}

However, when the fields in the document are updated, the image is no longer shown because of its invalid Uri. In MS Word, when you paste the image, it is directly inserted as image and the field is skipped.

Workaround - remove the field start/ends (in the attachments)

 

First Scenario: During layout of specific documents where the first section is with Continuous section break type, the layout algorithm enters in an infinite loop causing the application to hang.

Workaround: Change the section break type for the first section after the import of the document and before the layout:

Second Scenario: During the layout of specific documents where the last section is with Continuous section break type and has specific page size width and height, the layout algorithm enters in an infinite loop causing the application to hang.

Workaround 2: Slightly modify the size of the section which causes the issue after the import of the document and before the layout:

Third Scenario: During layouting of specific documents containing anchored elements, the layout algorithm enters in an infinite loop causing the application to hang. No workaround.

When custom annotations are created by inheriting AnnotationRangeStart and AnnotationRangeEnd classes, and the reaction to the delete commands is customized by overriding the DeleteBehavior, BackspaceBehavior, and DeleteSelectedBehavior, the delete command doesn't work as expected in some cases.

When exporting with RtfFormatProvider (including when the users copy content), an additional \par tag is added at the end of the document.

Workaround: Process the RTF after it is generated. 

Here is an example how to achieve it when copying:

this.radRichTextBox.CommandExecuted += radRichTextBox_CommandExecuted;
...
void radRichTextBox_CommandExecuted(object sender, CommandExecutedEventArgs e)
{
    if (e.Command is CopyCommand)
    {
        DocumentPosition end = this.radRichTextBox.Document.Selection.Ranges.Last.EndPosition;
             
        RadDocument clipboardDocument = ClipboardEx.GetDocument().ToDocument();
        RtfFormatProvider provider = new RtfFormatProvider();
        string rtfString = provider.Export(clipboardDocument);
        int indexLastParOpening = rtfString.LastIndexOf("{");
        int indexLastParClosing = rtfString.IndexOf('}', indexLastParOpening);
        string newRtf = rtfString.Remove(indexLastParOpening, indexLastParClosing - indexLastParOpening + 1);
        Clipboard.SetData("Rich Text Format", newRtf);
    }
}

The header of the first page can have only settings applied without any content. In such scenarios, RtfFormatProvider doesn't import the whole header, which can lead to a different layout of the document.