Caret blink: RunAsync on an Infinite animation returns a faulted Task per instance ("Looping animations must not use the Run method")

[ronnycohen]

Description

RichTextBox starts its caret blink in the constructor path (InitializeAdornerElements → InitializeBlinkAnimation) with:

• an Animation whose IterationCount = IterationCount.Infinite, and
• blinkAnimation.RunAsync(_CaretRect); — fire-and-forget, the returned Task is neither awaited nor stored.

Avalonia refuses infinite animations on the Run/RunAsync path: instead of throwing, it returns a faulted task — Task.FromException(new InvalidOperationException("Looping animations must not use the Run method.")).

Consequences

1. The caret never actually blinks (the animation never starts).
2. Every new RichTextBox() produces a faulted, unobserved Task that later surfaces as TaskScheduler.UnobservedTaskException on the finalizer thread — with an empty stack trace (the exception is never thrown), which makes it very hard for consumers to trace back to this control.
3. Consumers cannot observe or prevent it: the field is private and the task is discarded inside the constructor.

In our app (digital signage kiosk that periodically rebuilds screens containing several RichTextBox-based widgets) this generated ~940 telemetry events over 2 weeks across 4 devices before we could locate the source.

Repro

TaskScheduler.UnobservedTaskException += (s, e) => Console.WriteLine(e.Exception);
var rtb = new AvRichTextBox.RichTextBox();  // creates the faulted task
rtb = null;
GC.Collect(); GC.WaitForPendingFinalizers();
// -> AggregateException(InvalidOperationException("Looping animations must not use the Run method."))

Package: Simplecto.Avalonia.RichTextBox 1.9.3 (latest) · Avalonia 12.x (the RunAsync behavior is the same on 11.x). Still present on current main.

Suggested fix

Any of:

• drive the blink through the styling/Apply path (which supports IterationCount.Infinite), or
• run a finite animation restarted on completion, or
• keep RunAsync but with a finite iteration count and observe the returned task.

Ideally only start blinking when the control actually has focus / the caret is visible — that would also avoid the cost for read-only usages.

Workaround (downstream)

We filter this exact message in our global UnobservedTaskException handler, which silences the noise but obviously doesn't restore the blink.

Thanks for the control — happy to test a fix.

[cuikp]

Apologies for being unavailable.
I've added styling and removed the RunAsync(), with blinking being set by:
_CaretRect.Classes.Add("blinking");
and
_CaretRect.Classes.Remove("blinking");

Hopefully that solves the issues you've encountered.

In addition, Opacity is now forced on KeyDown (caret should not blink when continuous key press makes caret move), and blinking restored on KeyUp.

[ronnycohen]

Thanks for the fix — driving the blink from a style class is the right call, and it removes the problem at its source rather than papering over it.

For context on why this mattered on our side: we run AvRichTextBox in a digital-signage kiosk that rebuilds its UI continuously. Because the faulted RunAsync Task was neither awaited nor stored, every caret construction produced an UnobservedTaskException on the finalizer thread — about 940 events in two weeks in our crash reporter, including bursts of 12+ within 600 ms, all reported at fatal level. The caret is not even visible in our use case, so this was pure noise drowning real signals.

One small review note on dcdccd89: _CaretRect.Styles.Add(...) lives in InitializeBlinkAnimation() while Classes.Add("blinking") is in InitializeAdornerElements(). If either path ever runs twice on the same control instance, the style gets registered twice. Single-init is fine, but it may be worth guarding.

Lastly — is a NuGet release planned that includes this commit? We currently vendor the 1.9.3 source with a local workaround, and we'd like to drop that and go back to the package as soon as a release carries the fix.

[cuikp]

Thanks very much for the feedback.

Yesterday I uploaded styling-blink as NuGet ver. 1.9.4.

And yes, the initial Classes.Add is better placed in InitializeBlinkAnimation(), so will probably provide that small tweak as ver. 1.9.5 today.