Tizen alerts, modal navigation and gesture infrastructure

[Redth]

Stacked on redth-tizen-core-vertical-slice. Implements the Controls platform layer for alerts, modal coordination, modal page navigation and gestures.

Built on the public extensibility contracts that shipped in .NET MAUI 11 — IAlertManager / IAlertManagerSubscription (#36633) and IGesturePlatformManager / IGesturePlatformManagerFactory (#36655) — plus a provisional alignment with the still-open modal seam (#37853). No DispatchProxy, no private reflection, no InternalsVisibleTo.

150 host-side tests, all green. Diff is 40 files, all within this slice.

Alerts and dialog coordination

TizenAlertManager implements IAlertManager; TizenAlertManagerSubscription implements IAlertManagerSubscription. Both port the NUI AlertRequestHelper. Registered scoped, because MAUI resolves IAlertManager from the per-window scope — that is what gives each window its own window-affine manager.

Why a full manager and not just a subscription. Native NUI popups must be dismissed explicitly. MAUI's built-in manager treats Unsubscribe as "drop the reference", which on Tizen leaves an orphaned modal popup on screen and the awaiting DisplayAlertAsync caller pending forever. TizenAlertRegistrationMode.SubscriptionOnly gives the built-in-manager path for hosts that prefer it. Both modes are tested.

Two deliberate deviations from the original NUI code, documented in place and pinned by tests:

• Nested Page.IsBusy scopes keep the busy indicator open until the reference count reaches zero. The original closed it on the second "busy" notification, so overlapping scopes dismissed it early.
• The dialog result is published after the modal placeholder is popped and the popup disposed, and unexpected failures fault the caller instead of being swallowed. Result and cancellation values are unchanged; this removes a re-entrancy window and a hang.

Modal page navigation — ⚠️ provisional

This was the one area that could not be built on the shipped .NET MAUI 11 surface. ModalNavigationManager.Tizen.cs upstream is an internal partial-class completion compiled into Microsoft.Maui.Controls, and the neutral Standard partial only updates logical state, so an out-of-tree backend gets no rendering and has no DI/factory/provider hook at all.

dotnet/maui#37853 adds that seam, following the shape already used by the alert and gesture seams. It is still open, so its interfaces are not in the 11.0.0-preview.7 package this repository builds against.

Core/Platform/Modal/ProvisionalModalNavigationContracts.cs carries copies with member shapes taken verbatim from the PR, so the implementation is written against the final contract today. Adopting the real interfaces is a namespace change on two types plus deleting that file — no logic moves.

The copies live in Microsoft.Maui.Platforms.Tizen, not Microsoft.Maui.Controls.Platform: re-declaring a MAUI type name in a MAUI namespace would collide (CS0433) for consumers that also reference MAUI's own build once the PR lands.

ProvisionalModalNavigationContractTests keeps the copies honest — it asserts each interface's member shape against the PR, asserts the namespace rule, and fails outright once Microsoft.Maui.Controls.Platform.IModalNavigationPlatform appears in the referenced assembly, with instructions to delete the provisional file. The copies cannot drift and cannot outlive their purpose.

TizenModalNavigationPlatform ports ModalNavigationManager.Tizen.cs onto the seam. SendDisappearing/SendAppearing and the manual _platformModalPages bookkeeping are deliberately absent: under the seam the framework owns the platform stack and raises the page lifecycle events, so keeping them would fire those events twice.

TizenModalPageRealizer replaces modal.ToPlatform(context), which is compiled per platform and has no Tizen build now that Tizen left the MAUI repo. It does the same work through public, platform-neutral handler APIs — which also makes page realization testable on the host.

Dialog coordination went neutral too: NuiModalHost is replaced by TizenModalHost driving the new ITizenNavigationStack. Placeholder balance — the failure mode that wedges every subsequent modal in the app — is now verified by host-side tests rather than only on device.

Details in docs/tizen-modal-navigation.md.

Gestures

TizenGesturePlatformManagerFactory implements IGesturePlatformManagerFactory and works with any IViewHandler via the standard PlatformView / ContainerView pair. The dependency on MAUI's Tizen-only IPlatformViewHandler shape is gone, and a test asserts the handler under test does not implement it.

Ported: GestureDetector, tap, pan, swipe, pinch, long press. Pointer is new — the original backend had no PointerGestureRecognizer support — derived from NUI touch and hover events. The Registrar assembly-scanning fallback is replaced by explicit DI seams.

⚠️ Public MAUI API gap

MAUI 11 exposes public gesture controller interfaces for pan, pinch and swipe only. TapGestureRecognizer.SendTapped, the LongPressGestureRecognizer send members and the entire PointerGestureRecognizer send surface are internal — verified by reflecting over the shipped assembly.

Detection is implemented in full; dispatch goes through one seam, ITizenGestureDispatcher, which raises what it can and reports the rest as unsupported without throwing — a view with a TapGestureRecognizer behaves as if it had no gesture rather than crashing. Tests assert those events do not fire, so they fail loudly when upstream opens the API.

Reported rather than worked around. Full detail and the suggested upstream shape in docs/tizen-gesture-support-matrix.md.

Second finding: dotnet/maui's LongPressGestureHandler.cs calls Tizen.NUI.LongPressGestureDetector.SetMinimumHoldingTime, which does not exist in TizenFX (checked against Samsung.Tizen.Ref API13 and API15). That source has not compiled since Tizen left the MAUI build. MinimumPressDuration is not honourable on Tizen and the call is not carried forward — do not restore it during a future upstream sync.

Testing

150 host-side tests covering DI registration and lifetimes, alert manager/subscription lifecycle including repeated subscribe-unsubscribe, window affinity, result and cancellation mapping for all three dialog types, modal push/pop ordering and animation flags, batch-pop suppression, back-button routing, dialog placeholder balance including fault and buried-placeholder paths, detector attach/detach and enable/transparent transitions, and gesture translation. Dispatch tests use real MAUI recognizers, not doubles.

The logic sits behind Tizen-owned contracts with NUI isolated under Core/Platform/Nui, so the test project source-includes the neutral half rather than referencing a neutral build of the product. No neutral product assembly is produced, so the single-TFM rule in Directory.Build.props is preserved and NoProjectFallsBackToANeutralTargetFramework still passes.

eng/verify-nui-sources.sh type-checks the NUI half against TizenFX reference assemblies without the Samsung workload. It has caught two real problems: the SetMinimumHoldingTime call above, and a back-button implementation that reached for SetBackButtonPressedHandler — a MAUI Core Tizen extension, not a NUI or Tizen.UIExtensions API.

Boundaries and dependencies on core types

None blocking; all degrade gracefully:

• TizenNuiHostingExtensions.AttachTizenWindow(mauiContext, window, navigationStack, backButton?) — one call from the Tizen window handler wires window-affine alert routing, dialog coordination and modal navigation.
• Back button is deliberately not implemented here. Upstream the registry lives in Microsoft.Maui.Platform.WindowExtensions and is consumed by MauiApplication, both Core-layer concerns. Duplicating it would create a second, competing source of truth for back-button routing, so it is an optional argument instead. Without it, back presses fall through to the platform default.
• NuiAlertDialogFactory carries a private keyboard mapping duplicating Microsoft.Maui.Platform.KeyboardExtensions.ToPlatform. Swap to the Core one once Maui.Tizen.Core exposes it.

Device tests for the NUI adapters remain the one gap, blocked on the Samsung workload.

Drive-by fix

The workload gate in eng/build-workload-free.sh matched any workload id containing "tizen", so a machine with MAUI's own maui-tizen workload was reported as having the Samsung platform SDK. It does not — such a machine still fails NETSDK1139. Left as-is this would have promoted the Tizen lane to required and broken CI. Detection now mirrors the manifest probe in Directory.Build.props.

Not included

BlazorWebView — owned by another session.

[Redth]

CI is green on this branch.

Repository CI only triggers on PRs targeting main, so a stacked PR gets no automatic checks. Dispatched manually instead: run 33005740158 — all three jobs pass.

✓ Build and test (no Tizen workload)      31s
✓ Verify imported history                  7s
✓ Tizen workload availability (gate)      12s

  PASS repository invariant tests
  PASS controls platform tests
  PASS All workload-free checks passed

The controls platform tests line is the 101 new tests added here. Worth noting that the workload gate job correctly reports the Samsung SDK as unavailable now — before the fix in this PR it would have matched MAUI's own maui-tizen workload and claimed the Tizen lane was ready.

Something for the foundation to consider separately: extending the pull_request trigger beyond main would give stacked PRs automatic checks.

[Redth]

Rebased onto the core vertical slice and retargeted; CI green.

Base: now redth-tizen-core-vertical-slice · Head: 0f8671c · CI: run 33007265034

✓ Build and test (no Tizen workload)      38s
✓ Verify imported history                  6s
✓ Tizen workload availability (gate)      14s

  PASS repository invariant tests
  PASS backend slice tests
  PASS controls platform tests
  PASS All workload-free checks passed

Merged rather than rebased, deliberately. fcf3cca branches from foundation 79aa0f3, but this branch was on f8316cb. Rebasing would have dropped three foundation commits the core slice does not have yet — including 6ace22b, which pinned global.json to a concrete SDK version to fix a setup-dotnet failure. Merging keeps both. Both conflicts (Maui.Tizen.slnx, eng/build-workload-free.sh) were purely additive and resolved as unions, so the workload-free lane now runs all three test projects.

The PR diff against the new base is exactly 40 files, all within this slice — no foundation or core-slice content leaks in.

Test count is 150, up from 101, with modal navigation added. Worth flagging one thing the CI-semantics lane caught locally before it reached CI: a method-group-to-object conversion (CS8974) that only fails under TreatWarningsAsErrors. eng/build-workload-free.sh setting ContinuousIntegrationBuild=true by default is doing real work.

[Redth]

Merged core 4eb9163; PR is MERGEABLE / CLEAN with fresh checks.

Head: 0b4d186 · CI: run 33012615133 — all 3 jobs pass, and this one was triggered by pull_request rather than manual dispatch, so stacked PRs get real checks now.

✓ Build and test (no Tizen workload)      39s
✓ Tizen workload availability (gate)      13s
✓ Verify imported history                  4s

  PASS unit tests
  PASS backend slice tests
  PASS controls platform tests
  PASS All workload-free checks passed

Conflict resolution: both conflicts were in files core had reworked substantially, so I took core's version wholesale and re-applied only this branch's two additions — Maui.Tizen.Controls.UnitTests in the solution test folder and in the lane's project list and test block. The diff on eng/build-workload-free.sh against core is now purely additive (7 added lines, nothing removed).

Nothing from this branch was preserved by preference. In particular my grep-based workload probe from 885dd6a is gone, replaced by core's ReportTizenWorkload MSBuild target — which is the better fix, since it asks the same code path Directory.Build.props uses instead of reimplementing the check in shell. Good to see the finding survive as a regression fixture (maui-tizen alone is NOT Samsung's workload) rather than as my patch.

The controls platform tests now also sit inside core's BUILD_OK guard, so a build failure reports one clear error instead of cascading --no-build noise.

Diff against the new base is still exactly 40 files, all within this slice. Test count unchanged at 150. eng/verify-nui-sources.sh still passes on the merged tree.

[Redth]

Gesture dispatch gap has largely closed. Rebased on core 2610231 (MAUI 26426.4); PR is MERGEABLE / CLEAN.

Remote head: 8c18234 · CI: run 33013760085 — all 3 jobs pass, pull_request triggered · Tests: 158 (was 150)

Updated support matrix

Measured by reflecting over the shipped assemblies at each stamp, not by reading source:

	26418.3	26426.4
TapGestureRecognizer	internal	SendTapped public
PointerGestureRecognizer	internal	all 5 send members public
DragGestureRecognizer / DropGestureRecognizer	partly internal	all send members public
LongPressGestureRecognizer	internal	still internal

Recognizer	Detection	Dispatch	End to end
Pan / Pinch / Swipe	✅	✅ controllers	✅
Tap	✅	✅ SendTapped	✅
Pointer	✅	✅ 5 send members	✅
Long press	✅	❌ internal	⚠️
Drag / Drop	❌ no NUI equivalent	✅ (now public)	❌

The one remaining gap — exactly two members

LongPressGestureRecognizer.SendLongPressed(View, Func<IElement?, Point?>)
LongPressGestureRecognizer.SendLongPressing(View, GestureStatus, Func<IElement?, Point?>)

Absent from BindingFlags.Public, present under NonPublic; no ILongPressGestureController either. Making these public — exactly as #37420 did for tap and pointer — is sufficient; no new interface needed.

LongPressSendMembersAreStillInternalUpstream asserts this by reflection, so the matrix's central claim can't rot and fails the moment upstream opens the API. No duplicate upstream work opened, per instruction.

Drag/drop changed reason, not status. Dispatch is now public; they remain unsupported purely because NUI has no view-level drag/drop mapping onto per-view recognizer semantics. The matrix says so explicitly.

Position resolution

The new members take Func<IElement?, Point?> so MAUI can request a position relative to an arbitrary element. Tizen detectors report a view-local position, returned for the view itself and the null request. For any other element the resolver returns null — MAUI's own encoding of "cannot be determined" — because translating between two elements needs both on-screen origins, a native call the Tizen platform layer doesn't expose here. A plausible-looking wrong coordinate would be worse. PlatformPointerEventArgs/ButtonsMask are left at their optional defaults since NUI reports neither for touch/hover.

Also in this push

• Retired eng/verify-nui-sources.sh in favour of tests/Maui.Tizen.Controls.RefPackCompile, a sibling of the Core lane using the pinned Samsung.Tizen.Ref.API15 via PackageDownload. Drops a network dependency and a second ref-pack version. Verified it still catches what the script caught: reintroducing the SetMinimumHoldingTime call fails with CS1061 on API15, removing it passes.
• Zero foundation-owned deltas. I'd bumped the package pin ahead of foundation to unblock this work; foundation then landed the identical bump, so I took theirs verbatim for both Directory.Packages.props and eng/baselines.json. Both now match core byte for byte.

Diff is 40 files, all within this slice. Modal #37853 remains provisional with its expiry guard intact.

Dispatcher tests use real recognizers — verified load-bearing by stubbing out the SendTapped call and watching three fail.

[Redth]

All review findings closed. Rebased on core 4e256f1; MERGEABLE / CLEAN.

Head: c4bc396 · CI: run 33026278181 — 3/3 pass, pull_request · Tests: 196 (was 158) · Diff: 41 files, all in-slice

Findings closed

#	Finding	Resolution
1	GetPosition(null) returned local, not screen	TizenGesturePosition carries both spaces; resolves null→screen, same view→local, other→null
2	Identity scaler wrong on TV/wearable	AddTizenPixelScaler wired to DeviceInfo.ScalingFactor, read lazily
3	Unsubscribe cancelled in-flight dialogs	Detach-only; dismissal moved to Dispose at window-scope teardown
4	Eager window snapshot dropped alerts	Window resolved per request; unattached window services rather than discards
5	No button-mask filtering	Native button propagated and filtered against recognizer.Buttons
6	Stack push/pop not awaited	Both awaited; faults propagate, placeholder always unwinds
7	Cross-window handler reuse	Handlers bound to another MauiContext disconnected and rebuilt from target factory
8	Animation/stack metadata lost	ShownBehindPage saved and restored instead of forced false

Every fix verified load-bearing by reverting it and confirming the new tests fail — 9 failures across findings 1–7, 2 more for finding 8, no overlap. Tests assert behaviour, not implementation shape.

Two API constraints found by the API15 lane, not at runtime

• TapGestureRecognizer.SendTapped takes no button argument — it derives TappedEventArgs.Buttons from its own property — so the mask is enforced by filtering before dispatch.
• Tizen.NUI.Hover has no GetMouseButton. A hover is pointer movement with nothing pressed, so hover transitions report no button. Touch's MouseButton.Invalid and anything unclassified map to Primary, so a stray value can never fabricate a right-click.

Provisional seams deliberately retained

Both re-verified this turn against the resolved assembly at the pinned 26426.4, not against docs:

• LongPressGestureRecognizer.SendLongPressed/SendLongPressing — still absent from BindingFlags.Public, present under NonPublic.
• Add public modal navigation extensibility seam for external platform backends dotnet/maui#37853 still OPEN, so the modal contracts stay provisional.

Per instruction these are adopted only once available. Both have self-announcing guards that fail the build the moment upstream lands, so neither can outlive its purpose.

Note on a red lane I hit locally

Tizen.UIExtensions.NUI 0.9.2 briefly failed to restore with NU1100 — on pristine core too, and at 3c18089 which CI had already proven green. That ruled out a code regression: it was a stale negative NuGet HTTP-cache entry. dotnet nuget locals http-cache --clear fixed it. Flagging in case it surfaces on another machine; nothing to change in the repo.

Requesting final review.

[Redth]

Long-press state machine specified. Rebased on core dbcf82e; MERGEABLE / CLEAN.

Head: 69ffc44 · CI: run 33034912965 3/3 pass · Tests: 208 (was 196) · Diff: 41 files, all in-slice

Long press — mapping landed, adoption still waiting

dotnet/maui#37861 is OPEN, so it is absent from the pinned 26426.4 package and is not adopted. What is landed is the translation adoption will need, specified and tested now:

Native Tizen	GestureStatus	Events
Started	Started	LongPressing
Continuing	Running	LongPressing
Finished	Completed	LongPressed first, then LongPressing
Cancelled	Canceled	LongPressing only — never LongPressed, never the command

The in-box Tizen handler is deliberately not the model. Verified against dotnet/maui net11.0: LongPressGestureHandler.cs has no Continuing branch at all, so a Tizen long press never reports Running and an app tracking the gesture sees Started jump straight to Completed. GesturePlatformManager.iOS.cs maps UIGestureRecognizerState.Changed → Running, and that is what this backend follows.

My handler had inherited that gap — it dropped Continuing. Fixed, plus ToLongPressStatus/CompletesLongPress encode the table above. Reintroducing the gap fails 4 tests across both the mapping and the handler's ordering, so it cannot come back silently during adoption.

CompletesLongPress is separate on purpose: a canceled press reports a status change but is not a press, so raising LongPressed or running the Command there would fire the app's handler for a gesture the user aborted.

New behavioural coverage: full ordered sequence incl. two Running updates, cancel path asserting Finished never appears, no-meaning states ignored, and per-state mapping theories. API15 compile lane passes.

⚠️ Pre-existing flaky test in core — not from this PR

CI first went red on Maui.Tizen.Core.UnitTests → DispatcherTests.ConcurrentDelayedDispatchesEachFireExactlyOnce. Evidence it is core-owned and flaky, not caused by this branch:

1. My diff touches zero files under Maui.Tizen.Core — verified.
2. Core's own CI at dbcf82e — the exact commit merged here — fails on the identical test with the identical 1 failed / 279 passed signature.
3. Core's recent history alternates pass/fail across commits, the signature of flakiness.
4. Rerunning my job with no code change turned it green.

Root cause looks like wall-clock sensitivity: the test schedules 8 delayed dispatches at 5–12 ms and drains for 600 ms, asserting all 8 fired. On a loaded agent that window is not reliably sufficient — items 2–7 reported 0. Worth making the drain deadline-based rather than a fixed budget. Flagging rather than fixing, since it is outside this PR's scope.

Ready for final review.