KeyPress Scope

[CraigBelser]

Problem Description
The current behavior of the key listener does not align with standard keypress event scoping expectations. Specifically:

1. When the behavior is attached to a control (e.g., an Entry), only that control should receive the keypress events.
2. Sibling controls or controls outside the visual scope should not receive these events.
3. Parent elements in the visual tree should receive the events only if the event is not marked as handled (e.Handled = true).
4. Keyboard events should bubble up the visual tree, following standard event routing patterns.

Expected Behavior
Keypress events should be scoped to the VisualElement the behavior is attached to, and optionally bubble up to its parent elements. The behavior should not act as a global key event listener where all controls receive all keypresses indiscriminately.

Core Requirements

1. Keypress events must be routed to the attached control and optionally bubble up.
2. The behavior must respect event handling (Handled = true) to prevent further propagation.
3. When multiple behaviors are present, each should receive only the events relevant to its scope.

Ask
Please scope the keystroke handling appropriately, especially in scenarios where multiple behaviors are used. The current implementation behaves like a global listener, which breaks encapsulation and expected UI behavior.

Reproduction
To reproduce the issue, open the KeyListener sample project and replace the contents of MainPage.xaml.cs with the following code:

using Plugin.Maui.KeyListener;
namespace Plugin.Maui.KeyListener.Sample;

public partial class MainPage : ContentPage
{
public MainPage()
{
InitializeComponent();
}

void ClearButton_Clicked(object sender, EventArgs e)
{
    OutputLabel1.Text = string.Empty;
    OutputLabel2.Text = string.Empty;
    EntryTester1.Text = string.Empty;
    EntryTester2.Text = string.Empty;
}

void OnKeyDown_Entry1(object sender, KeyPressedEventArgs e)
{
    string newValue = $"KeyPressed= {e.Keys}, Modifiers={e.Modifiers}";
    EntryTester1.Text = newValue;
    OutputLabel1.Text = newValue + Environment.NewLine + OutputLabel1.Text;
    e.Handled = true;
}

void OnKeyDown_Entry2(object sender, KeyPressedEventArgs e)
{
    string newValue = $"KeyPressed= {e.Keys}, Modifiers={e.Modifiers}";
    EntryTester2.Text = newValue;
    OutputLabel2.Text = newValue + Environment.NewLine + OutputLabel2.Text;
    e.Handled = true;
}

}

Replace MainPage.xaml with:

<ScrollView>
    <VerticalStackLayout Margin="20" Spacing="20">
        <Label Text="Press any key to see the event details" />
        <Button Clicked="ClearButton_Clicked" Text="Clear" />
        <Entry
            x:Name="EntryTester1"
            BackgroundColor="LightBlue"
            MinimumWidthRequest="400"
            Placeholder="Text Test 1"
            TextColor="Black">
            <Entry.Behaviors>
                <keyListener:KeyboardBehavior KeyDown="OnKeyDown_Entry1" />
            </Entry.Behaviors>
        </Entry>
        <Entry
            x:Name="EntryTester2"
            BackgroundColor="LightBlue"
            MinimumWidthRequest="400"
            Placeholder="Text Test 2"
            TextColor="Black">
            <Entry.Behaviors>
                <keyListener:KeyboardBehavior KeyDown="OnKeyDown_Entry2" />
            </Entry.Behaviors>
        </Entry>
        <Button Text="Does Nothing, is tab stop" />
        <Grid ColumnDefinitions="*,50,*" Grid.RowDefinitions="Auto,*">
            <Label
                Grid.Row="0"
                Grid.Column="0"
                FontAttributes="Bold"
                Text="First Entry Output" />
            <Label
                Grid.Row="0"
                Grid.Column="2"
                FontAttributes="Bold"
                Text="Second Entry Output" />
            <Label
                x:Name="OutputLabel1"
                Grid.Row="1"
                Grid.Column="0" />
            <Label
                x:Name="OutputLabel2"
                Grid.Row="1"
                Grid.Column="2" />
        </Grid>

    </VerticalStackLayout>
</ScrollView>

Run the app and focus on one Entry. Typing will trigger both KeyDown handlers, even though only one Entry has focus.

Running it and typing while focused on one entry control will call all of the listeners, not just the scoped entry control.

Here is a Recording of it (Note Testing was done on Windows).

KeyboardScopeIssue.mp4

[CraigBelser]

I would have checked in as a branch, but I have no write access.

[jeremy-visionaid]

@CraigBelser You can just create a pull request from a fork though?

[jeremy-visionaid]

For Windows, this is seems like a duplicate of #2. It's currently like that at the Page level for iOS/MacCatalyst too. I've put in a PR as a proof of concept for Android (#35) to match the current behavior.

[jeremy-visionaid]

FWIW, for Apple, perhaps the approach could be changed to use UIGestureRecognizer instead of UIViewController like currently. I don't mind investigating that part, but it might be good to get all the platforms ready together (and get the Android proof of concept merged first).

[jeremy-visionaid]

Maybe somebody else already tried the UIGestureRecognizer approach. I was able to register recognizers with the platform view OK, and get mouse/touch input (e.g. TouchesBegan), but I haven't been able to get PressesBegan to trigger for keyboard input. Maybe I did something wrong - I'm more of a Windows/Linux developer, but I'm guessing that's an Apple thing and it just doesn't work for keyboards. I'll try and verify in Swift later if I get the chance.

Anyway, if there's no general mechanism to intercept key events on a control without subclassing on Apple then it's going to be really difficult to scope key presses...

[jeremy-visionaid]

Though another possibility might be to still use the UIViewController, but to enumerate the responder chain from the focused control. Might test that idea out tomorrow.

[CraigBelser]

My thoughts on scope.

Scoped Behaviors

Definition:
A scoped behavior is attached to a specific UI element (like a TextBox, Button, or UserControl) and only responds to events when that element is in focus or active.

Key Characteristics:

1. Context-aware: The behavior only activates when its associated control has focus.
2. Isolated: Multiple instances of the behavior can exist independently on different controls.
3. Safe for multi-instance UIs: Ideal when you have multiple similar controls (e.g., multiple trade windows) and want each to respond only to its own input.

Example Use Case: You have two input fields, each with a behavior that listens for the Enter key to submit. Only the field with focus should respond when Enter is pressed.

[CraigBelser]

Run the sample of this fork. I think I got the window scope fix. (https://github.com/ImpySoft/Plugin.Maui.KeyListener/tree/ScopeTesting)

[jeremy-visionaid]

@CraigBelser Thanks for that, looks essentially the same as my commit in the Windows-specific issue: #2
jeremy-visionaid@6274b77

I revised the PR to connect to the XamlRoot.Content for now though, until we have solutions for all platforms: #32

I've got some other API-breaking fixes that should go in first: #39

Once that's done it would be good to address some of those other issues. I know there's some problems addressing connecting/disconnecting behaviours, esp. across multiple controls and pages, it's on my mind to get to those.

[jeremy-visionaid]

Example Use Case: You have two input fields, each with a behavior that listens for the Enter key to submit. Only the field with focus should respond when Enter is pressed.

AFAIK this won't work on either Android or MacCatalyst since the corresponding platform views for the Entry controls swallow all the key events.

[jeremy-visionaid]

Didn't have a lot of time to look into this on Friday, but I do have a partial proof of concept for Android (controls like Button and Entry are actually OK, but the layout views are problematic).

MacCatalyst is still a problem, since the trick of becoming first responder for Entry (UITextView) appears to work differently to iOS (e.g. PressesBegan triggers for the UIViewController's first responder on iOS, but not on MacCatalyst). I'm no Apple expert though, so hopefully one of the MAUI guys might be able to weigh in if there's something I'm missing.