Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cardano UI simplification for flows initiated by Suite #4256 #4284

Merged
merged 9 commits into from
Oct 30, 2024

Conversation

obrusvit
Copy link
Contributor

@obrusvit obrusvit commented Oct 25, 2024

This PR aims to simplify Cardano flows initiated by Trezor Suite. Namely:

  • send transaction with no additional features - this should behave roughly like sending Bitcoin, i.e. confirming address i, recipient i and Summary at the end. No "Choose level of details" screen.
  • staking transaction with no additional features - this should behave almost exactly the same except without the initial screen asking a user to "Choose level of details"

This is achieved by:

  • modifying the ORDINARY_SIGNER to categorize the transaction further
  • based on the category, modify the layouts shown

TODO:

  • I need to verify that the categorization of a transaction to either SIMPLE_SEND, SIMPLE_STAKE_DELEGATE, SIMPLE_STAKE_WITHDRAW or NOT_SUITE_TX is generally valid
    • testing with Suite, I hopefully got it right
  • fix discrepancies for total_amount calculation for the summary - e.g. change output should not be added to the final amount?
  • fix Recipient i showing
  • tests - I don't think new tests are needed (there are many for ADA) but:
    • checking the existing UI diff - especially cardano/sign_tx.json with "simple transaction" in the name are affected
      • there seems to be like 3 cases where a slightly more complicated transaction triggers should_show_more = True, shouldn't be a big deal.
    • enable other UI tests with "Show more details" for mercury
  • mercury summary layout has a wrong button text and title

@obrusvit obrusvit self-assigned this Oct 25, 2024
@obrusvit obrusvit requested review from mmilata and removed request for prusnak October 25, 2024 10:58
@obrusvit obrusvit added altcoin Any non-Bitcoin coins core Trezor Core firmware. Runs on Trezor Model T and T2B1. labels Oct 25, 2024
Copy link

github-actions bot commented Oct 25, 2024

core UI changes device test click test persistence test
T2T1 Model T test(screens) main(screens) test(screens) main(screens) test(screens) main(screens)
T3B1 Safe 3 test(screens) main(screens) test(screens) main(screens) 2724
T3T1 Safe 5 test(screens) main(screens) test(screens) main(screens) test(screens) main(screens)
All main(screens)

Copy link
Member

@mmilata mmilata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking like a massive UI improvement!

There's a Safe 3 testcase where hold-to-confirm is introduced as a second-to-last action which probably isn't right:
Screenshot 2024-10-28 at 22-19-55 T3B1_en-device_tests-cardano-test_sign_tx py test_cardano_sign_tx_failed sample_stake_pool_registration_certifi-3f8170f6

Then again, T3T1 also has some weirdness which is not new?:
Screenshot 2024-10-28 at 22-21-52 T3T1_en-device_tests-cardano-test_sign_tx py test_cardano_sign_tx_show_details plutus_transaction_with_reference_input

pub enum ConfirmWithInfo {
Main,
Menu,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering what's the main difference from other two-screen flows we already have 🤔 Menu items?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flow has different option in the menu "Show all" and it returns INFO on click of that button. It seemed the best way for now is to just create a new flow.
I'm thinking about a more universal constructor of these SwipeFlows which would be supplied with menu options and what they do... No clear idea at the moment.

To answer the top comment:

There's a Safe 3 testcase where hold-to-confirm is introduced as a second-to-last action which probably isn't right:
Then again, T3T1 also has some weirdness which is not new?

These screens show the derivation paths and they are shown after the transaction is signed and only if should_show_more is true, i.e. when the user opted for "Show all". IIUC, Cardano TX is not initiated with derivation paths of the inputs, they are optionally provided by the host afterwards. The UX is quite strange ("Hold to confirm", then simple "Confirm") but I didn't want to change the flows not coming from Suite.
I was also perplexed at first.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking about a more universal constructor of these SwipeFlows which would be supplied with menu options and what they do

I think main problem is making the parameters of this constructor available to the logic in handle_swipe/handle_event, which is currently not possible without abusing RwLock/AtomicU.*

core/src/apps/cardano/sign_tx/signer.py Outdated Show resolved Hide resolved
@obrusvit
Copy link
Contributor Author

Tested with Suite and found out that the categorization must allow witness_request_count higher than 1 as this is equal to the number of inputs which can be higher even for simple transaction. The logic is similar to bitcoin -> more inputs might be needed in order to to make the TX.

fixed here: 8b5e087

Copy link
Member

@mmilata mmilata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • clippy is failing
  • needs regenerated fixtures incl. translations

otherwise LGTM

@obrusvit obrusvit force-pushed the obrusvit/cardano-trezor-suite-flows branch from dc3e71a to a4d1846 Compare October 29, 2024 21:46
@obrusvit
Copy link
Contributor Author

  • ignoring changelog for python job failing as I only corrected a param
  • lots of UI diff generated for T3B1 also for non-Cardano stuff because of adding a previously missing option to cancel confirm_properties
    image

- remove the choise of detail level ("Show simple" vs "Show all") when
signing simple transactions - these are the transactions typically
enabled by TrezorSuite.
This prompt was unintuitive as the menu button served as the "show more"
button. This commit implements a small SwipeFlow which hides the option
to the context menu.
- change the button text based on `hold`
- make it abortable
@obrusvit obrusvit force-pushed the obrusvit/cardano-trezor-suite-flows branch from a4d1846 to 1b3f4c1 Compare October 29, 2024 23:54
@obrusvit obrusvit added the translations Put this label on a PR to run tests in all languages label Oct 29, 2024
Also show Recipient {i} for simple tx
Rationale: the removed test cases are considered "simple" as of the
recent changes and they do not prompt a user for "level of details".
@obrusvit obrusvit force-pushed the obrusvit/cardano-trezor-suite-flows branch from 1b3f4c1 to a390f0c Compare October 30, 2024 00:53
Copy link

legacy UI changes device test(screens) main(screens)

@obrusvit obrusvit merged commit 2e0e8eb into main Oct 30, 2024
135 of 138 checks passed
@obrusvit obrusvit deleted the obrusvit/cardano-trezor-suite-flows branch October 30, 2024 08:15
@bosomt
Copy link

bosomt commented Nov 1, 2024

QA OK

checked on TS5 device

Info:

  • Suite version: web 24.11.0 (ff5fe34e9ecaee40808f50c235c08cf8e588b0c8)
  • Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
  • OS: MacIntel
  • Screen: 5120x1440
  • Device: Trezor T3T1 2.8.4 regular (revision 31d228a)
  • Transport: WebUsbTransport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
altcoin Any non-Bitcoin coins core Trezor Core firmware. Runs on Trezor Model T and T2B1. translations Put this label on a PR to run tests in all languages
Projects
Status: Approved
Development

Successfully merging this pull request may close these issues.

3 participants