[Bug] SelectableTextBlock SelectionStart-/End incorrect in some Scenarios

Normally when clicked outside the Text in a SelectableTextBlock the SelectionStart and SelectionEnd properties are set to the last character index + 1. So just outside the Text. For the Text “Test” SelectionStart will be 4 when the user clicks somewhere outside the Text.

Also normally if there are multiple lines in the SelectableTextBlock and a letter (or word) not in the first line is selected, SelectionStart is just the index of that letter (or word) as if there were no linebreaks (each linebreak is just \r\n so this adds 2 Characters per linebreak).

But when there are multiple lines and the user clicks outside the Text, I would expect SelectionStart to be either the last index in that line (the line where the user clicked) or just the last index of the whole Text. But instead it is the last index of the first line.

Examples: “Test” -> click outside will set index to 4

“Test -> click on “s” in second line will set index to 8 (because line break is \r\n so 2 characters, 8 - 2 would be 6 -> so that’s correct) Test”

“Test -> click outside in line 1 will set index to 4 (which is still correct) Test”

“Test -> click outside in line 2 will still set index to 4 (expected would be 10, 10 -2 cause of line break would be 8 so just after the last “t”) Test”

Desktop information

• OS: Windows 11
• Avalonia Version: 11.0.0-rc1.1

I hope that this is understandable, it’s difficult to explain

[timunie]

@nuc134r setting Background=Transparent should also work, as transparent is totally valid background for hit-testing. But the default null will not work as it it not hittestable.

@Gillibald do we maybe want to add Transparent by default to make it work for everyone?

[Gillibald]

@nuc134r setting Background=Transparent should also work, as transparent is totally valid background for hit-testing. But the default null will not work as it it not hittestable.

@Gillibald do we maybe want to add Transparent by default to make it work for everyone?

Yes we need to fallback to transparent instead of leaving the brush null