Describe the bug
Using InlineUIContainer controller inside SelectableTextBlock breaks the selection (InlineUIContainer counts as 1 character)
To Reproduce
The example from the Docs suffice if we swap TextBlock with SelectableTextBlock:
<SelectableTextBlock ClipToBounds="False" FontSize="32" TextWrapping="Wrap">
🚀 This <Span BaselineAlignment="TextTop">example</Span> shows the <Bold>power</Bold> of
<InlineUIContainer BaselineAlignment="Baseline">
<Image Width="32" Height="32" VerticalAlignment="Top" Source="/Assets/avalonia-logo.ico" />
</InlineUIContainer>
in creating rich text displays with
<InlineUIContainer>
<Button Padding="0,8,0,0">
<TextBlock ClipToBounds="False" FontSize="24" Text="👍👍🏼👍🏽👍🏾👍🏿" />
</Button>
</InlineUIContainer>
inline controls 📈
</SelectableTextBlock>




An interesting case where double clicking "inline" also selects the button, the copied text reads "inline".
Expected behavior
Expected behaviour would be the selection to correctly skip InlineUIContainer elements instead of treating them like one character
Avalonia version
11.0.10
OS
Windows
Additional context
The text returned by base.Inlines?.Text inside OnPointerPressed looks correct so it might be base.TextLayout.HitTestPoint that returns an incorrect offset.
Describe the bug
Using InlineUIContainer controller inside SelectableTextBlock breaks the selection (InlineUIContainer counts as 1 character)
To Reproduce
The example from the Docs suffice if we swap TextBlock with SelectableTextBlock:
An interesting case where double clicking "inline" also selects the button, the copied text reads "inline".
Expected behavior
Expected behaviour would be the selection to correctly skip InlineUIContainer elements instead of treating them like one character
Avalonia version
11.0.10
OS
Windows
Additional context
The text returned by base.Inlines?.Text inside OnPointerPressed looks correct so it might be base.TextLayout.HitTestPoint that returns an incorrect offset.