Attempt Web3 Unlock OnClick #683
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tification when unlock fails.
dternyak
changed the title
wbobeirne
approved these changes
Jan 1, 2018
There was a problem hiding this comment.
This is great. Would be nice if after the 250ms, it canceled the unlock, but I understand that would be a huge amount of work. I think this fine as-is.
As discussed, at some point we'll probably want to look at supporting multiple web3 addresses, which may change how this works, but for now it's fine.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
MEW + MetaMask is now single click in the happy path (🎉 to the UX) with no degradation to UX on the sad path.
Happy
Sad
What could be better
250ms is chosen as the magical number to give time for web3 decryption. This works well enough on my machine, but time to unlock may (likely slightly) vary for others. If the unlock time exceeds 250ms, the secondary unlock screen will be shown and then disappear without user action as soon as the wallet is unlocked. I've found 250ms to work well on my testing, but open to feedback on how to increase robustness (hopefully without the corresponding increase in complexity). This can be solved concretely by using sagas and dispatching state updates based on the web3 unlock response, and I may end up implementing that if this doesn't sit right after a night of sleep 😁)
(Minor) Notifications are currently broken (recently updated in Fix UI Access by Software modal MyEtherWallet/MyEtherWallet#645), so the current build would have an unclose-able error notification until notifications are fixed.