Do you mean the user can by pass or change the ListView navigation behavior if he want?

Yes, l think event should always have first priority since user can put anything in there.

For ListView the code for collection navigator is in:

protected override bool OnKeyDown (Key a)

This means that even keybindings don't get priority over navigation, the ordering is controlled in base class so cannot be simply fixed for ListView alone:

// This is where navigation happens
if (RaiseKeyDown (key) || key.Handled)
{
    return true;
}

// This is where keybindings happen
if (InvokeCommands (key) is true || key.Handled)
{
    return true;
}

View.Keyboard.cs

This means that even this test fails:

[Fact]
public void ListViewCollectionNavigatorMatcher_KeybindingsOverrideNavigator ()
{
    ObservableCollection<string> source = new () { "apricot", "arm", "bat", "batman", "bates hotel", "candle" };
    ListView lv = new ListView { Source = new ListWrapper<string> (source) };

    lv.KeyBindings.Add (Key.B,Command.Down);

    Assert.Equal (-1, lv.SelectedItem);

    // Keys should be consumed to move down the navigation i.e. to apricot
    Assert.True (lv.NewKeyDownEvent (Key.B));
    Assert.Equal (0, lv.SelectedItem);

    // There is no keybinding for Key.C so it hits collection navigator i.e. we jump to candle
    Assert.True (lv.NewKeyDownEvent (Key.C));
    Assert.Equal (5, lv.SelectedItem);
}

For ListView the code for collection navigator is in:

protected override bool OnKeyDown (Key a)
This means that even keybindings don't get priority over navigation, the ordering is controlled in base class so cannot be simply fixed for ListView alone:

// This is where navigation happens
if (RaiseKeyDown (key) || key.Handled)
{
return true;
}

// This is where keybindings happen
if (InvokeCommands (key) is true || key.Handled)
{
return true;
}
View.Keyboard.cs

This means that even this test fails:

[Fact]
public void ListViewCollectionNavigatorMatcher_KeybindingsOverrideNavigator ()
{
ObservableCollection source = new () { "apricot", "arm", "bat", "batman", "bates hotel", "candle" };
ListView lv = new ListView { Source = new ListWrapper (source) };

lv.KeyBindings.Add (Key.B,Command.Down);

Assert.Equal (-1, lv.SelectedItem);

// Keys should be consumed to move down the navigation i.e. to apricot
Assert.True (lv.NewKeyDownEvent (Key.B));
Assert.Equal (0, lv.SelectedItem);

// There is no keybinding for Key.C so it hits collection navigator i.e. we jump to candle
Assert.True (lv.NewKeyDownEvent (Key.C));
Assert.Equal (5, lv.SelectedItem);

}

Two things:

1. In tests, avoid calling NewKeyDown on views. Instead use Application.RaiseKeyDownEvent. This ensures key bindings are sent to the right view.

2. I think the problem is that the way PopupAutocomplete is implemented is fundamentally broken. It injects itself into the LV's subview heirachy as a subview. Then it uses custom drawing to draw outside of the LVs Viewport (which is supposed to be verboten in v2). And it has custom nav logic that DUPLICATES a ListView's functionality.

Instead, based on the new Popover design, it needs to be refactored.

The thing that shows the list of suggestions should just be a ListView, Registered with Application.Popover and shown via Application.Popover.Show when appropriate.

I believe this will fix this issue.

That said, I do have this TODO in my latest MenuBar PR:

I think this is unrelated to popups, at least as far as the test above. It is about KeystrokeNavigator having precedence over both Keybindings and user KeyDown event handlers...

KeystrokeNavigator is the thing that moves selection when you press key i.e. to the next object that begins with that letter

See here: #4027 (comment)

The fix does not belong to this Issue.