Textprocessing issue after upgade to Avalonia 0.10.13 and FluentAvalonia v1.3

[timunie]

Describe the bug After upgrading to the latest versions, I cannot enter any Text inside ContentControl

Screenshots

This is taken from Avalonia DevTools. DialogHost marks the event as handled and eats my KeyEvents I need.

Desktop/Platform (please complete the following information):

• OS: [e.g. Windows 10
• FluentAvalonia Version [1.3.0]
• Avalonia Version [e.g. 0.10.13]

Additional context A simple repro is here: https://github.com/timunie/Tims.Avalonia.Samples/tree/FluentAvaloniaTextProcessingIssue/src/FluentAvaloniaDialogTextBoxIssue

happy coding Tim

[amwx]

Well that's not good... I made a change to DialogHost as part of the TaskDialog implementation to handle all input events in a hosted dialog so that events in the dialog don't propagate to the window, and is similar to if it was placed in its own window - but clearly this isn't the way to do it.

It seems looking at dev tools that the key event has to propagate all the way back to the Window in order to fire a TextInput event, and because I block it, the TextInput event is never fired resulting in the TextBox not responding.

If you'd like to PR this fix, just remove these lines in DialogHost.cs https://github.com/amwx/FluentAvalonia/blob/6e80b566ac59080c539b3976fd82d6cbcff92aa0/FluentAvalonia/UI/Controls/Internal/DialogHost.cs#L98-L106

Otherwise I'll get to it this weekend.

[timunie]

@amwx ,

Thank you for the very fast feedback. Well, I can create a PR for this, but I guess if this solves some other issues for you we should think about a different solution.

• Check which key was pressed and only mark the event as handled, if it is not a text input event
• Handle TextInput on our own
• ... You may have an even better idea

Happy coding Tim

[amwx]

It's not really an issue yet, but I realized that if a dialog is hosted in the OverlayLayer, events still propagate up to the MainWindow, meaning if you had a Hotkey (or anything similar) on the MainWindow (or top level view), it would still fire if the Dialog is open - and the dialog really should be treated as its own input root.

One option would be to get the OverlayLayer separated into its own tree, which is what UWP does. This would have to be done upstream in Avalonia though, and probably isn't an easy change. Another is to try and make DialogHost its own input root, but I'm not sure how hard that would be to do.

[amwx]

Closing for now as this isn't high priority. If/when this gets a solution, we'll deal with that then