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
[DDW-926] Improve error handling for incorrect passphrase / incorrect hardware wallet device #2860
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marcin-mazurek I left a few comments/explanations. Please take a look!
@@ -49,6 +49,12 @@ const messages = defineMessages({ | |||
defaultMessage: '!!!Exporting the public key failed', | |||
description: '"Exporting public key failed" device state', | |||
}, | |||
unrecognized_wallet: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be camel case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, I followed the existing pattern where we map the HwDeviceStatus enum values directly to translations. The enum uses snake_case therefore we have this mapping which doesn't follow JavaScript naming conventions. Would you like me to refactor this? I would have to introduce an additional map to map statuses to translation keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using lodash's camelCase for mapping enum values to translations? This way we could kill two birds with one stone. (btw it is a funny sentence)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would work, however I'm afraid that it will make it harder to refactor and track which translations are actually in use. Currently you can just find translations by a string, with camelCase function it's not going to be that easy anymore.
@alexander-rukin I've uploaded the latest screenshots. The issue is no longer visible: |
@tomislavhoracek please re-review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marcin-mazurek AMAZING!!! 💯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
path: devicePath, | ||
}, | ||
}); | ||
deviceFeatures = await TrezorConnect.getFeatures(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marcin-mazurek. I can confirm that the error handling is working for Trezor now 👍. However there is one scenario where the new correct error message is not shown When a wallet is setup with a passphrase and when user is prompted for the passphrase and enters an empty(blank) passphrase the old message "Disconnect and reconnect your hardware wallet to restart the process" appears. Any other incorrect passphrase that isnt blank triggers the correct message Screenshot |
…r validation issue" This reverts commit 4952375.
@gabriela-ponce You actually came across two issues. First issue (DDW-970) is related to incorrect logic in address verification, which @szymonmaslowski is addressing in this PR: #2906. Second issue is with Daedalus losing track of Ledger USB path - anytime you see the "Cannot open device with path..." error, that isn't an issue with logic for a particular action - it's an issue related to Ledger connectivity implementation and unfortunately may happen at various points while interacting with Ledger wallet. Currently @renanvalentin is heavily changing the way we handle Ledger USB paths in this PR: #2900. Hopefully when his piece of work is finalized and merged, we should no longer experience those path issues. For now, when you get an issue like this one: https://drive.google.com/file/d/1a48WtwdQaX71QDfuZ13wY73QB0jJ8ucy/view (or like the ones reported by @ManusMcCole here - #2860 (comment)) - the only workaround is to unplug the device and plug it again, then retry. @ManusMcCole could you please re-test Trezor scenarios again? I've extended the error handling further to account for cases you've found, but this increases the risk and it would be good to do a full hardware wallet regression test before we ship this. |
…rrent wallet ID does not match device wallet ID
03c32cd
to
68fa148
Compare
Hi @marcin-mazurek. I have completed another round of testing.Tested on build 21375 on Mac OS. I found one scenario where a correct passphrase was not accepted Pair a wallet with a passphrase. Initiate transaction. Insert Incorrect passphrase. Correct message "We do not recognise this wallet on your device" pops up.Press Back.Press Send again.Insert Correct passphrase this time and it still is accepted as false and the "We do not recognise this wallet on your device" pops up again For a passphrase protected wallet for some reason getting the passphrase wrong one time causes even the correct passphrase to fail in subsequent attempts Wallet with a blank passphrase accepts correct passphrase after an incorrect one has been entered previously |
…itch hidden wallets
@ManusMcCole this is ready for another round of review. I've added several more test cases to the PR description and executed them and they all seem to pass. Please re-check. |
Hi Marcin. Here is the newest testing report for build 21659 Intel MacOS Testnet.Mostly all of the scenarios worked except when device is connected and unlocked after Send transaction has been initiated There seems to be an issue for Ledger X for hidden pincode wallets when the device is only connected after Send is already selected for a transaction. Initiate a transaction then connect and unlock device. Even with a correct hidden pin entered a Transaction Confirmation failed error appears. Screenshot For normal pincode wallets same scenario on Ledger X instead of the above error the device is not recognised after unlock(with correct or hidden pin entered) and continues to say "Connect the Ledger X device". Screenshot My Ledger S device is currently not operational so this issue may also appear there too I was not currently able to test |
Hey @ManusMcCole, please have a look at the latest build which includes #2900 which brought significant improvements for Ledger. In the latest build I'm not able to reproduce scenarios you've posted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @marcin-mazurek. Looks good 👍
Can't believe it 😱 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @marcin-mazurek !!! you can now rest in peace 😂
This PR improves error handling in scenarios when user provides an incorrect passphrase (different than the one provided while pairing the wallet) or uses an incorrect wallet (in case the user has multiple wallets from the same manufacturer).
Screenshots
Before
After
Testing Checklist
Testing scenarios:
No passphrase provided while pairing, non-empty passphrase provided on making transaction
Then try the same once again, without restarting Daedalus.
Non-empty passphrase provided while pairing, no passphrase provided on making transaction
Then try the same once again, without restarting Daedalus.
Passphrase provided while pairing, different passphrase provided on making transaction
Then try the same once again, without restarting Daedalus.
Ledger wallet paired using standard PIN, transaction made with hidden PIN
Ledger wallet paired using hidden PIN, transaction made with standard PIN
Ledger S paired but Ledger X used for transaction
Ledger X paired but Ledger S used for transaction
Pairing two Trezor wallets one by one and making transactions
Hints: always test on clean state folder, also try to do some transactions after pairing, before making the transaction which should produce the new error.
Review Checklist
Basics
input-output-hk/daedalus-dev
andinput-output-hk/daedalus-qa
assigned as PR reviewersrun Chromatic
label to PR to trigger the run)release-vNext
,feature
/bug
/chore
,WIP
)yarn manage:translations
produces no changes)yarn storybook
)yarn.lock
file is updatedCode Quality
Testing
After Review