ContextMenu opened from DataGrid.CellPointerPressed doesn’t appear if right-click happens too quickly after left-click

[BillGatesGames]

Hi! I’m using Avalonia DataGrid and I want to show a context menu on right-click.
I’m handling CellPointerPressed (or DataGridCellPointerPressedEventArgs) and creating/opening a ContextMenu programmatically.

What I do:

• On right mouse button press, I resolve the item (row/cell DataContext).
• I create a new ContextMenu in code (based on the clicked item).
• I call ContextMenu.Open(control) (sometimes via Dispatcher.UIThread.Post).
• I also close any previously opened menu before opening a new one.

Problem:
The context menu only appears if the user waits a small moment after a left-click (selecting a row) before doing the right-click (opening the context menu).

If the user left-clicks a row and then right-clicks very quickly:

• the handler runs,
• Open(...) is called,
• but the context menu does not become visible.

So it looks like the open call “succeeds”, but the menu is not shown unless there is a small pause between the clicks.

Question:
What could cause this timing-dependent behavior?
Could it be related to pointer event handling, focus/selection updates inside DataGrid, or event routing/capture? Any recommended pattern for reliably opening a context menu in this scenario?

[timunie]

You may want to try Dispatcher.UiThread.Post in order to delay the show a bit.

[BillGatesGames]

I tried it. The behavior doesn't change.

[lextm]

"If the user left-clicks a row and then right-clicks very quickly" can be an unnecessary sequence. To open the context menu, the user can directly right click to trigger without a left click in advance.

[BillGatesGames]

In this case, the context menu opens immediately. But I'd still like to understand why this menu behaves differently in my case.

[lextm]

@BillGatesGames Based on my experience porting ILSpy WPF, this DataGrid control isn’t in good shape at all. You'd better switch to a fork that really aims to resolve the issues (100+).

Our fork only aims to bridge the gaps ILSpy depends on, so issues like the one you reported aren’t our priority.