RadTabView WinUI: selected tab content is visible but native hit-test position remains on previous tab after repeated switching
Product: Telerik UI for .NET MAUI
Version: 15.0.0
Platform: Windows / WinUI
Target framework: net10.0-windows10.0.19041.0
Control: RadTabView
Description
We are experiencing a reproducible issue with RadTabView on Windows/WinUI where the selected tab content becomes visually out of sync with the native hit-test/layout position.
After switching between two tab contents several times, the newly selected tab appears on screen and is reported as selected/enabled, but pointer input is still received by the previously selected tab content.
This makes the visible tab appear disabled or noninteractive even though its controls and ancestors are enabled.
Minimal reproduction sequence
Using two tab contents, for example:
- Open the first tab, Line Items.
- Click an editable cell such as Item Code.
- Switch to the second tab, Expenses.
- Click an editable cell such as Expense Code.
- Return to Line Items and click Item Code again.
- Switch back to Expenses.
- Click the visible Expense content.
Expected result
The newly selected Expenses tab should be positioned in the active viewport and receive pointer input.
Actual result
On the failing second activation of Expenses:
RadTabView reports Expenses as selected.- Expenses content is visibly rendered.
- Expenses and its managed/native ancestors are enabled.
- There is no application busy state.
- There is no pending editor, navigation, or lookup operation.
However, diagnostic inspection of the native layout shows that:
- the Expenses native content remains approximately one viewport width (~1180 px) to the right of the active viewport;
- the previous Line Items content remains positioned at the active viewport;
- clicking the visually displayed Expenses content produces a pointer event in the Line Items grid instead;
- Expenses therefore never receives the pointer and never begins editing.
In other words, the visual selection and native hit-test/layout position diverge.
Additional observations
- The problem is reproducible without saving data or executing business operations.
- It does not depend on data loading, database activity, or application validation.
- At the failure point our application reports
IsBusy=False. - The destination content and ancestors report enabled/hit-testable state.
- No pending focus restoration, navigation, or lookup operation exists.
- Resizing the application window has restored correct pointer targeting in at least one reproduction.
- Alt+Tab sometimes changes the behavior but is not a reliable recovery.
- We tried native and managed layout-refresh approaches. They were not reliable; one native refresh caused pointer targeting to move to a different column, so both experiments were removed.
- The issue appears to be related to the WinUI/native
RadTabView content strip not synchronizing its layout/hit-test position with the selected tab.
Diagnostic state comparison
| State | Current content | Result |
|---|
| A | Line Items – Item Code | Correct content receives input |
| B | Expenses – Expense Code | Correct content receives input |
| C | Line Items – Item Code again | Correct content receives input |
| D | Expenses selected again | Expenses visible, but pointer is received by Line Items |
At state D:
- selected tab = Expenses
- application busy state = false
- Expenses enabled = true
- native ancestors enabled = true
- no pending navigation
- no pending lookup restore
- no pending editor transition
- native Expenses content position ≈ +1 viewport width
- native Line Items content remains at viewport position
Question
Could you please confirm whether this is a known RadTabView issue on Windows/WinUI, particularly involving repeated selection causing the native content strip or hit-test geometry to become out of sync with the selected item?
If this is known, please advise:
- whether a fix is available in a newer Telerik build;
- whether there is a recommended workaround;
- whether forcing a particular RadTabView/native layout API after selection is supported;
- whether inactive tab content is expected to remain in the WinUI visual tree and participate in hit testing.
We can provide a small standalone reproduction project and diagnostic logs if required.
Thank you.