-
Notifications
You must be signed in to change notification settings - Fork 166
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
fix: clear account state when changing network #367
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.
The reason I couldn't see this bug is because in my tests I never tried to copy the seed at account creation, I only did it using the "See recovery phrase" menu.
Rather than having yet another if (isSubstrate)
I would actually advise to remove the if
here and handle Ethereum accounts just like Substrate accounts. In the near future both will have derivation paths. If things are set correctly, the derivation path and password will be set to empty string for Ethereum so that you don't have to change anything else. No need to empty anything with the networkChooser
either. I think it's better to isolate each component and the Network chooser should not have to deal with side effect happening elsewhere.
src/screens/AccountBackup.js
Outdated
@@ -28,6 +28,7 @@ import Button from '../components/Button'; | |||
import TouchableItem from '../components/TouchableItem'; | |||
import DerivationPasswordVerify from '../components/DerivationPasswordVerify'; | |||
import AccountsStore from '../stores/AccountsStore'; | |||
import {NETWORK_LIST, NetworkProtocols} from "../constants"; |
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.
single quote
src/screens/AccountNetworkChooser.js
Outdated
@@ -24,6 +24,7 @@ import fonts from "../fonts"; | |||
import TouchableItem from '../components/TouchableItem'; | |||
import { NETWORK_LIST } from '../constants'; | |||
import AccountsStore from '../stores/AccountsStore'; | |||
import { empty } from "../util/account"; |
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.
single quote
@Tbaut sorry but I'm quite confused by what you mean above, It seems this PR is just making the clippy copy the appropriate seed for the network that is chosen, and that's it.
how? seed is separate from seedPhrase and derivationPath so they have to be treated separately.
FWICT that was the source of the bug being fixed here, where long pressing the seed for Ethereum would copy an empty string.
this seems to have been the other bug, where the wrong seed for the wrong network would be copied...
? what is this referring to? sorry if my quetsions don't make sense, but like i said, i'm quite confused here |
This PR does solve the problem, I just think there's a better way to do so.
Sure I agree.
This is a side effect that doesn't happen with my suggestion.
I don't see why we would need to totally empty an account if we change the network. This logic should not need to be there as it's a fix for something else. If we want to reuse this component for e.g #158 this logic would be in the way. Happy to do a PR to show you what I mean. I just think there's a more elegant way to fix this bug. |
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.
Ok giving up on my "better solution". I still believe in it but there were other things breaking. So this solution is cool.
Thanks for the Q&A session, which make things clear.
If that is happened (and also Another question, after I check the difference of:
The only difference is whether |
The idea is that the password should remain secret, so we give a way to test it, without ever revealing it. A malicious actor with the seed phrase can't get access to the fund (most malware would probably stop here), they would need not only derivation path but also the password on top of that.
This is one of the things that broke with my suggestion, because |
close #363 .
Fixed behaviour here: