[Bug]: Contact USDT confirmation swipe overlaps Android system navigation #1523

Activity

1. piotr-iohk

   added the

   Bug

   issue type on Oct 16, 2026
2. ovitrif

   added this to the 3.0.5 milestone on Oct 16, 2026
3. piotr-iohk commented on Oct 16, 2026

   

   piotr-iohk

   on Oct 16, 2026

   CollaboratorAuthor

   More actions

   Additional affected flow reported during RC2 testing: the payment-request payment confirmation sheet also shows swipe-to-pay underneath Samsung's three-button navigation bar. This is a reporter observation; there is no new screenshot for that occurrence. The original contact-USDT screenshot above remains the visual evidence. The asset used in the newly reported payment-request occurrence was not separately recorded.

   I traced the payment-request and subscription paths at the shipped RC2 revision 19449fb0d729f51b9875eee2f66acfc0671e11da:

   • USDT payment requests share the confirmed source cause. Incoming requests enter the contact-payment flow through finishIncomingPaymentRequestPreparation. reviewPaykitAmount routes USDT to SendRoute.UsdtReview, whose destination renders PaykitUsdtReview. Its container uses sheetHeight().background(...) without navigationBarsPadding(), including when isPaymentRequest is true.
   • Subscription USDT payments are exposed through the same shared route. The send state identifies recurring requests from their billing period, while the USDT review routing is shared. This is a source-level finding, not a device reproduction of a subscription overlap.
   • The dedicated subscription subscribe/cancel/delete swipe sheets are different. SubscriptionReview applies navigation-bar padding at line 800; SubscriptionCancel does so at line 991. They do not share this missing-inset cause.
   • BTC/Lightning request confirmation is also different: SendConfirmScreen already applies navigationBarsPadding(). Do not generalize this root cause to every request asset; if the new observation was BTC/Lightning, that specific path still needs runtime investigation.

   Please include direct contact USDT, one-time request payments using USDT, and recurring/subscription payments using USDT in the fix/retest scope. Verify three-button and gesture navigation without double-padding the already protected BTC/Lightning and dedicated subscription sheets. No new builds or payments were performed for this follow-up.
4. piotr-iohk commented on Oct 16, 2026

   

   piotr-iohk

   on Oct 16, 2026

   CollaboratorAuthor

   More actions

   Historical overlap report: Android #1404 — Paykit payment-request sheet clips and does not open automatically. It included a cramped/partially covered swipe control on the same Samsung S22, so it is relevant prior evidence.

   History assessment: a later USDT-path layout defect, not evidence that the #1405 fix was reverted.

   • [Bug]: Paykit payment-request sheet clips and does not open automatically (canary #3) #1404 was closed on 2026-10-01 with “Fixed by fix: present requests and keep controls visible #1405.” PR #1405 moved scrolling into the middle content area and kept the amount and payment controls outside it in SendConfirmScreen. See fix commit f36e353f.
   • That fix commit is an ancestor of RC2 19449fb0d729f51b9875eee2f66acfc0671e11da. The BTC/Lightning confirmation also retains its existing navigationBarsPadding(); fix: present requests and keep controls visible #1405 did not remove it.
   • The separate PaykitUsdtReview was introduced afterward in fdd47c68 — add USDT wallet and Paykit payments. Its initial container already omitted navigation-bar padding (sheetHeight().gradientBackground().padding(...)). The RC2 container still omits it, after subsequent visual updates.

   Therefore the confirmed USDT overlap is best classified as a new path missing the earlier layout protection, rather than the original BTC/Lightning fix being undone. This does not prove that every original #1404 layout case was validated on every device. No historical device retest was performed here.

   For the newly reported payment-request occurrence, the payment asset was not recorded. If it was USDT, it follows the shared defective path described above. If it was BTC/Lightning, investigate that separately as a possible remaining/regressed #1404 case; the missing-USDT-inset explanation would not cover it. Subscription USDT payment remains source-confirmed exposure, not a runtime reproduction.
5. piotr-iohk commented on Oct 16, 2026

   

   piotr-iohk

   on Oct 16, 2026

   Last edited by piotr-iohk

   CollaboratorAuthor

   More actions

   Another affected flow: Cross-network deposits in received USDT activity details

   On the same Samsung Galaxy S22 (Android 16, RC2 3.0.0 build 193), open a received USDT transaction and show its details. The bottom Cross-network deposits button (Wpłaty z innych sieci in Polish) sits behind Android's three-button system navigation. The screenshot shows iOS on the left and Android on the right; Recents/Home/Back overlap the Android button.

   

   Confirmed source cause at RC2 19449fb0d729f51b9875eee2f66acfc0671e11da:

   • UsdtActivityDetail uses a full-size root Column with no navigation-bar inset.
   • Its fixed bottom action container uses only Modifier.padding(16.dp). The UsdtDepositHistory button is rendered inside it when details are shown for an eligible incoming transfer. Fixed padding does not reserve the system navigation-bar area.
   • The wallet transaction-detail route renders this component directly, without supplying the missing bottom inset. PaykitUsdtReview also reuses this detail component.

   This is the same missing-system-inset class, but a separate container from the swipe confirmation in PaykitUsdtReview. A fix only on the swipe screen will not cover this activity-details footer.

   Add received-USDT activity details → Cross-network deposits to this issue's fix and verification scope, alongside contact/request/subscription USDT confirmation. Reserve bottom system-navigation space at the appropriate detail container; verify both three-button and gesture navigation without double-padding other hosts. No new transfer is required to reproduce: use an existing received transaction. Screenshot is reporter evidence; source path inspected, no new device run performed by the agent.
6. ovitrif

   assigned

   ben-kaufman

   on Oct 18, 2026
7. jvsena42

   marked fix: usdt payment review sheet ignores bottom navigation bar inset #1571 as a duplicate of this issue on Oct 19, 2026
8. ovitrif commented on Oct 20, 2026

   

   ovitrif

   on Oct 20, 2026

   Last edited by ovitrif

   Collaborator

   More actions

   @ben-kaufman the same navigation-bar overlap shows on the "USDT Sent" success sheet on Bitkit Android 3.0.1 (195): its Details and Close buttons sit under the gesture bar. #1564 fixes the Swipe To Pay bar on the USDT payment review, but doesn't touch the success sheet (it looks like UsdtSendContent.kt), and #1572 only covers the Forgot PIN and subscription-unavailable sheets. Could #1564 cover the success sheet too?

   USDT Sent success sheet, Details and Close under the gesture bar: