[jvsena42]

Twin: synonymdev/bitkit-ios#1020

This PR lets a sideways swipe over the USDT receive QR change tabs, as it does on the other receive tabs. Before, swiping out of USDT did nothing, and the drag ended as a tap on the QR, which copied the address.

Description

• UsdtDepositReceiveScreen: on the address page, the content uses the existing swipeToChangeTab modifier (the one All Activity uses). With USDT selected, ReceiveQrScreen replaces the tab pager with this screen, so nothing handled a horizontal drag. The QR's clickableAlpha then treated the swipe as a tap and copied the address with the "Invoice copied to clipboard" tooltip.
• A swipe right selects the tab before USDT (Spending). A swipe left does nothing, since USDT is the last tab. In both cases the drag is consumed after touch slop, so it no longer copies. A plain tap on the QR still copies.
• The network, amount and fee pages are unchanged; the swipe applies only to the address page.

Merged origin/master (review round 1) instead of rebasing, to keep the base of the stacked #1593: master renamed clearAmountError() to clearError() in the wrapped block. Wraparound and swiping on every tab are in #1593 (#1590).

Out of Scope

• iOS: its QR copies only on onTapGesture, so a swipe should not copy there. Swiping out of USDT on iOS is checked separately.

Design

Receive USDT › HW QR on the Refactor v63 page. No visual change; the layout matches the frame.

Preview

Gate_Throwaway emulator, dev wallet with USDT enabled, adb shell input swipe across the QR.

Before: swipe right, still on USDT and the address copied	After: USDT before the swipe	After: swipe right selects Spending	After: swipe left stays on USDT, no copy	Figma

Recordings

Before: two right swipes over the USDT QR; the tab never changes, and the address is copied.

before.mp4

After: one right swipe over the USDT QR selects Spending, with no copy tooltip.

after.mp4

QA Notes

Journeys

• new usdt-receive-swipe-tabs.xml: swiping right over the USDT QR selects Spending without copying; swiping left stays on USDT without copying; a tap still copies. The return from Spending swipes across its QR or setup view in 600 ms (review round 1)

Manual Tests

N/A

Automated Checks

• ran just compile, just test and just lint on this branch merged with the other 3.1.0 batch branches: all passed, and detekt reports no findings in the changed file

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge, with the previous test-step issue fixed.

Summary

Adds sideways swipes to the USDT receive address page without changing the network, amount, or fee pages.

• Swiping on the USDT address page changes receive tabs.

_{Reviews (2) · Last reviewed commit: "test: swipe back from spending setup in ..." · Reviewed by Greptile}

[github-actions]

Regtest APK

Built from 23f0662 (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[talosmachina]

No findings. Wraps the USDT address page in the existing swipeToChangeTab modifier, so a sideways swipe over the QR changes tabs instead of ending as a tap that copies the address. Reviewed f64fef9, full tier. Reasoned from the code and CI; the branch was not built here.

What I checked, and 5 candidates I ruled out

Read in full: UsdtDepositReceiveScreen.kt, UsdtReceiveContent.kt, SwipeToChangeTabModifier.kt, the USDT branch and visibleTabs of ReceiveQrScreen.kt
Call sites traced: swipeToChangeTab (All Activity, USDT receive), selectReceiveTab
CI: build, build-local, lint, detekt and six e2e shards green; send and onchain_boost_receive_widgets were still running

Ruled out

• Swipe right lands on the wrong tab: visibleTabs always appends USDT last (ReceiveQrScreen.kt:148-159), so tabIndex - 1 is Spending and a left swipe is a no-op.
• tabIndex of -1: this screen renders only while selectedTab == ReceiveTab.USDT, which is in visibleTabs.
• Stale tab count in pointerInput(currentTabIndex): any change to the list while on USDT (a hardware tab appears) also moves USDT's index, so the key changes and the detector restarts.
• Swipe on the amount or network pages: the modifier is applied only when page == ReceivePage.ADDRESS, so the amount input keeps its own gestures.
• Layout: the new Column takes weight(1f) in the parent scope and UsdtReceiveContent's weight(1f) box now resolves against it, so the QR still fills the remaining height.

Merge confidence: 4/5, no automated test drives the swipe (the journey covers it by hand) and two e2e shards were still running.

[ovitrif]

@jvsena42 a follow-up on this PR: I'd like the Receive tabs to swipe on every tab and wrap around (swipe back on the first tab goes to the last, swipe forward on the last goes to the first), and a sideways swipe must never dismiss the Receive sheet. Tracked in #1590 and synonymdev/bitkit-ios#1024.

The dismissal repro: on USDT, swipe sideways and release above the sheet; Receive closes. On Spending the same swipe doesn't, since the pager consumes the drag. Consuming the drag after touch slop here may already fix it.

Would you fold this into your PRs, or should I open a follow-up stacked on your branches?

[ovitrif]

@jvsena42 I've opened the wraparound as a follow-up stacked on this branch: #1593, so this PR stays as it is. When this one merges, it retargets to master.

On the dismissal repro: with synthetic swipes, a sideways swipe released above the sheet does not close Receive on this branch, on master or on a v3.0.0 build. The only sideways swipe that closed it starts at the screen edge, which is Android's system back gesture and does that on every tab.

Also, at 21:06 CEST I pushed two of my commits to this branch by mistake and restored it to f64fef9 within a few minutes; nothing of yours changed.

[jvsena42]

@ovitrif thanks, wraparound in #1593 works for me.

• Dismissal: no change here, in line with your re-check. The swipe uses detectHorizontalDragGestures, which takes the drag only after horizontal touch slop, so a vertical drag still reaches the sheet. The iOS twin did have a related problem: a swipe down on the USDT page no longer closed Receive. That is fixed in fix: swipe between receive tabs from the usdt qr bitkit-ios#1020 (047370c1).
• Your restore: the branch was at f64fef9 when I fetched, matching yours.
• Conflict with master: merged origin/master into this branch (23f0662) instead of rebasing, so the commits under fix: wrap receive tab swipes around #1593 stay the same. The only overlap was deposits.clearAmountError(), renamed to clearError() on master; I kept the swipe wrapper with the new name. just compile, just test, just lint and the androidTest compile pass on the merged head.

[greptile-apps]

Greptile encountered an error while reviewing this PR. Please reach out to support@greptile.com for assistance and include this reference: 9635eeac-a3a8-4914-99c7-8b7d91092e02.

[pwltr]

Reviewed 23f0662, including the merge from master and the clearError() conflict resolution. No additional findings from my source review.

I previously ran all seven steps of receive/usdt-receive-swipe-tabs.xml on f64fef9: tab selection, slow swiping back to USDT, no accidental copying during swipes, and tap-to-copy all passed. The swipe implementation and journey are unchanged in this head.

[ovitrif]

utAck

[ovitrif]

Merged, as it was approved and green.