RichEditBox in UWP/WinUI3 Loses Font Family Settings for Subsequent Lines if the First Line Contains Only a Newline

[KennethVScom]

Describe the bug

When using the RichEditBox control in UWP or WinUI3, if the content's first line consists solely of a newline character, the font family settings for subsequent lines are lost after calling the RichEditBox.Document.GetText() method. This results in the text reverting to the default system font family (Segoe UI), rather than retaining the user-defined font family settings.

Steps to reproduce the bug

1. Create a UWP or WinUI3 application with a RichEditBox control.
2. Set the initial content of the RichEditBox such that the first line is a newline character.
3. Add text to subsequent lines with a specific font family setting.
4. Use the RichEditBox.Document.GetText() method to retrieve the content of the RichEditBox.
5. Observe that the font family settings for the text after the first newline character revert to the default system font family.

Expected behavior

The font family settings for all lines, including those following the first newline character, should be preserved after calling the RichEditBox.Document.GetText() method.

Screenshots

NuGet package version

None

Windows version

Windows 11 (22H2): Build 22621, Windows 10 (21H2): Build 19044

Additional context

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Open similar issues:

• RichEditBox reverts to default font family on theme change (#8650), similarity score: 0.77
• [Regression] FontFamily resolution changed between WinUI 2 and WinUI 3 (#9247), similarity score: 0.77
• [RichEditBox] Text editing bar is not showing up correctly when it has a fixed MaxHeight (#8982), similarity score: 0.72

Closed similar issues:

• RichEditBox increases horizontal size when initial text entered (#7312), similarity score: 0.74
• FontSize of RichEditBox is limited to 130 (#8835), similarity score: 0.73

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[kmahone]

@KennethVScom I tried to repro this issue follow the steps in the description but did not reproduce the bug. Would you be able to share a WinUI3 sample app that demonstrates the problem?

In the scenario where you are seeing this bug, just calling RichEditBox.Document.GetText() causes the text formatting to disappear - is that correct?

[KennethVScom]

@KennethVScom I tried to repro this issue follow the steps in the description but did not reproduce the bug. Would you be able to share a WinUI3 sample app that demonstrates the problem?

@kmahone Sorry for the late reply.
Please refer to the sample project here, just click the Add Simple button and then click the Copy and Paste button to reproduce the issue.

In the scenario where you are seeing this bug, just calling RichEditBox.Document.GetText() causes the text formatting to disappear - is that correct?

Yes, that is correct!

Thank you.

[iomismo]

I have similar problems. Selecting last char of the last line also reverts font family to default one:

Also, if in a new document you type something and then undo it (leaving the text empty), it also reverts to default font properties:

There is a RichEditTextDocument.IgnoreTrailingCharacterSpacing property, but it has no impact whatever it is true or false (if this has something to do with the problem). Its description:
Gets or sets a value that indicates whether character spacing is applied to the last character in a line.
true if spacing is applied to the last character in a line of text; otherwise, false. The default is false.

Default is false, but the last char is applied. And as mentioned, there is no change if it is set to true or false.
It's also a bit ambiguous. If the property is called IgnoreTrailing, perhaps the true value should be don't add the last character.

Directly using Document.GetText also adds an extra rtf line to the end of the text. But if you set the range of the selection to the entire text and call GetText from that Selection, it gets the text correctly.