[adirh3]

What does the pull request do?

Make TextLine.GetTextBounds return an empty bounds collection for zero-length requests, protecting every consumer of the API.

What is the current behavior?

HitTestTextRange(1, 0) on "abc", and HitTestTextRange(3, 0) on "a\r\nb\r\n", throw ArgumentOutOfRangeException with ParamName="textLength" instead of returning empty geometry.

Reported exception

An anonymized report from an application using Avalonia 12.1.2 on Windows x64 and .NET 11.0.0-rc.1.26425.128:

System.ArgumentOutOfRangeException: textLength ('0') must be a non-zero value. (Parameter 'textLength')
Actual value was 0.
   at Avalonia.Media.TextFormatting.TextLineImpl.GetTextBounds(Int32 firstTextSourceIndex, Int32 textLength)
   at Avalonia.Media.TextFormatting.TextLayout.HitTestTextRange(Int32 start, Int32 length)
   at Avalonia.Controls.SelectableTextBlock.RenderTextLayout(DrawingContext context, Point origin)
   at Avalonia.Controls.TextBlock.RenderCore(DrawingContext context)
   at Avalonia.Rendering.Composition.CompositingRenderer.UpdateCore()
   at Avalonia.Rendering.Composition.Compositor.CommitCore()
   at Avalonia.Media.MediaContext.CommitCompositorsWithThrottling()
   at Avalonia.Media.MediaContext.RenderCore()
   at Avalonia.Media.MediaContext.Render()
   at Avalonia.Threading.DispatcherOperation.InvokeCore()

This report motivated the investigation; the tests establish the direct empty-range API defect, not the reporter's original rendering sequence.

How was the solution implemented?

Return an empty bounds collection in TextLineImpl.GetTextBounds for a zero-length request, as requested in review, and document that result on TextLine. Remove the TextLayout-specific guards. Negative-length handling is unchanged.

Tests

Direct TextLine tests cover eight zero-length cases at caret and CRLF boundaries, plus three nonempty geometry/run-bound checks. The existing TextLayout empty-range, completed-line, and negative-length regressions remain. Each test-only commit precedes its implementation commit.

The new direct TextLine regressions produce eight ArgumentOutOfRangeException failures before the lower-API fix, even with the earlier layout-only guards. After the fix, the committed TextLine and TextLayout suites pass 168 tests, with one existing profiling-only skip.

The confirmed reproducer is the direct zero-length public API call. Three ordinary CRLF SelectableTextBlock selection-rendering probes also passed with the original throwing implementation. The original reporter's text/selection/input sequence remains unknown; this PR does not claim to reproduce that exact UI trigger.

Breaking changes

No signature changes. Zero-length bounds queries now return an empty collection instead of throwing.

AI-assisted contribution. The submitting author will handle review feedback.

[github-actions]

NuGet packages

The packages for this pull request have been published (workflow run):

• Version: 12.2.999-cibuild0100165-alpha
• Feed URL: https://nuget-feed-all.avaloniaui.net/v3/index.json

[Gillibald]

I think we should change GetTextBounds to return an empty rect for an empty range instead of throwing. That also fixes the issue but for all consumers of that API. How is this issue triggered in a real world application?

[adirh3]

Moved the fix to TextLineImpl.GetTextBounds, returning an empty bounds collection for zero-length requests, and removed the TextLayout guards. The TextLine/TextLayout suites pass 168 tests with one existing skip. The real-app report came through SelectableTextBlock rendering, but the reporter's exact text and selection sequence is unknown. Ordinary CRLF rendering probes didn't reproduce it; the confirmed reproducer is the zero-length public API call.

[Gillibald]

LGTM