Text Controls don't lose highlighting when unselected (TextBox / RichEditBox)
Describe the bug
Selecting text highlights the text, but unselecting it still maintains the highlighted background colour. Interestingly foreground colour doesn't persist after unselection. This weird behaviour only occurs after the first visual row, which behaves normally. Only multiline selections that include the first row behave normally. This is a problem in both TextBox and RichEditBox.
All highlighting is lost when the control regains focus. (As expected)
Steps to reproduce the bug
Loaded the normal WinUI 3 app template. Added a RichEditBox and a TextBox.
Highlight some text after the first visual row. (it doesn't matter if done by the keyboard or mouse) Highlighted some other text to clicked elsewhere, the highlighting background colour still persists in the now unselected text.
No custom styling has been applied. Light/Dark theme doesn't change anything. This bug occurs with both the default and newest WASDK
Expected behavior
Selected text should lose its highlighting if unselected. This should happen no matter what line it is.
Screenshots
NuGet package version
WinUI 3 - Windows App SDK 1.6.1: 1.6.240923002
Windows version
Windows 11 (22H2): Build 22621
Additional context
No response
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:
- TextBox selection is broken when there are multiple lines (#9965), similarity score: 0.82
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
Further testing.
Partial success
- If I locally set the text background to another background colour via
ITextRange.CharacterFormat.BackgroundColor = (this.Background as SolidColorBrush)?.Color ?? Colors.Transparent;selection highlighting doesn't persist.
Failures
- Calling InvalidateArrange() nor Document.ApplyDisplayUpdates() in a SelectionChanged event have no positive effect.
- Setting the RichEditBox Background property doesn't change the weird behaviour.
- Putting this in my Loaded event doesn't work,
var myFormat = Document.GetDefaultCharacterFormat(); myFormat.BackgroundColor = (this.Background as SolidColorBrush)?.Color ?? Colors.Transparent;
The same problem with WASDK 1.6.241106002.
The same problem with WASDK 1.6.241106002.
Urgh, I won't be able to update or release anything until this is fixed. Text input is pretty much essential to any app.
CC: this is affecting customers of MAUI as well.
I have found a partial fix with only a small amount of jumping of the scrollerviewer if the text box is inside of a scrollerviewer.
you need to hookup to the selectionchanged event, i left in the some old code of stuff that does not work or work well
private bool WasFullTestSelected = false;
private void FullTextBox_SelectionChanged(object sender, RoutedEventArgs e)
{
if (sender is TextBox textBox)
{
bool isSelected = textBox.SelectionLength > 0;
if (isSelected is true)
{
if (WasFullTestSelected is true)
{
//is selected true && was selected true
//no change
if (false)
{
//cant run this because it will not work for a mouse move selection to continue
//but when dragging froward then backwards the issue will be on those chars
//that where selected then deselected
var horizontalOffset = FullTextBoxScroll.HorizontalOffset;
var verticalOffset = FullTextBoxScroll.VerticalOffset;
FullTextBox.Visibility = Visibility.Collapsed;
FullTextBox.Visibility = Visibility.Visible;
FullTextBox.Focus(FocusState.Keyboard);
FullTextBoxScroll.ChangeView(horizontalOffset, verticalOffset, null, true);
}
}
else
{
//is selected true && was selected false
//now selected
}
}
else
{
if (WasFullTestSelected is true)
{
//is selected false && was selected true
//lost selection (the issue)
if (false)
{
//FullTextBoxScroll.InvalidateArrange();//does not work
}
if (false)
{
//FullTextBox.InvalidateArrange();//does not work
}
if (false)
{
//FullTextBox.InvalidateMeasure(); //does not work
}
if (false)
{
//does not work
//var horizontalOffset = FullTextBoxScroll.HorizontalOffset;
//var verticalOffset = FullTextBoxScroll.VerticalOffset;
//FullTextBoxScroll.ChangeView(horizontalOffset, verticalOffset, null, true);
}
if (false)
{
//works but buggy
//var horizontalOffset = FullTextBoxScroll.HorizontalOffset;
//var verticalOffset = FullTextBoxScroll.VerticalOffset;
//var selectionStart = FullTextBox.SelectionStart;
//var selectionLength = FullTextBox.SelectionLength;
//FullTextBox.SelectAll();
//FullTextBoxScroll.ChangeView(horizontalOffset, verticalOffset, null, true);
//FullTextBox.Select(selectionStart, selectionLength);
//FullTextBoxScroll.ChangeView(horizontalOffset, verticalOffset, null, true);
}
//works but jumps when it clears the selection can tolerate
//least buggy of what i found.
FullTextBox.Visibility = Visibility.Collapsed;
FullTextBox.Visibility = Visibility.Visible;
FullTextBox.Focus(FocusState.Programmatic);
}
else
{
//is selected false && was selected false
//not selected
}
}
WasFullTestSelected = isSelected;
}
}
I just met this bug with a RichEditBox, Windows App SDK 1.6.241114003, Windows 10 22H2 I quickly tested this workaround, similar to what @ReneeHuh posted, but not sure if it is sufficient...
reb1.SelectionChanged += (sender, args) =>
{
var reb = (RichEditBox)sender;
var childElement = FindChildElementByName(reb, "ContentElement");
if (childElement != null)
{
var sw = (ScrollViewer)childElement;
var h = sw.HorizontalOffset;
var v = sw.VerticalOffset;
sw.ChangeView(h, v + 1, 1.0f, true);
sw.ChangeView(h, v, 1.0f, true);
}
};
with :
#nullable enable
private Microsoft.UI.Xaml.DependencyObject? FindChildElementByName(Microsoft.UI.Xaml.DependencyObject? tree, string sName)
{
for (int i = 0; i < Microsoft.UI.Xaml.Media.VisualTreeHelper.GetChildrenCount(tree); i++)
{
Microsoft.UI.Xaml.DependencyObject child = Microsoft.UI.Xaml.Media.VisualTreeHelper.GetChild(tree, i);
if (child != null && ((Microsoft.UI.Xaml.FrameworkElement)child).Name == sName)
return child;
else
{
Microsoft.UI.Xaml.DependencyObject? childInSubtree = FindChildElementByName(child, sName);
if (childInSubtree != null)
return childInSubtree;
}
}
return null;
}
#nullable disable
@castorix The normal textbox issue is said to be fixed in the upcoming update, so I'm gonna wait and see if it fixes the RichEditBox too before trying a workaround.
Great work on the SwapChainPanel btw, it really shows what winui can do.
i have the same problem too, if the text is not highlighted, select some texts, click other places, the selected part is still blue(default). But if i highlight these texts, select some texts, click other places, the selected part is not blue, which is normal the pictures below represent the bug and normal situation, respectively. hope the problem be noticed lol.......
Windows App SDK 1.6.3 (1.6.241114003) (newest till 1/8/2025)
版本 运行时下载项
1.6.3 (1.6.241114003)
Good news! It has been fixed in the latest experimental version.
@zhaoqianbiao 你app设计挺好, 但我建议你用.resw文件存string, 英文版只有英文,中文版只有中文。 https://learn.microsoft.com/zh-cn/windows/apps/windows-app-sdk/mrtcore/localize-strings
As @AlexanderBlackman said, looks like it is fixed in the latest experimental version. I will be closing this issue as resolved, please re-open if the issues still persists.
@AlexanderBlackman gotcha! thanks for your suggestions!