urbit
progress bar never progresses when reticketing L2 planet w/ metamask
Describe the bug: This is on mainnet.
I have an L2 planet stored on a Trezor accessed via Metamask and went to transfer it to a master ticket. I signed the transactions to do so just fine, but then this progress bar pops up:
I waited for ~10 minutes and it never progressed. I ultimately went back to the home screen and saw that the transactions were in fact pending, so it looks like it went through fine. Maybe if I waited until the roller submitted the transaction is would have progressed, but if that's the case then the copy is wrong and it should say something about the transfer taking up to a day (assuming we switch to daily submission instead of hourly), not 5 minutes, and having a progress bar is then a bit silly.
To reproduce: Steps to reproduce the behavior:
- Log in to an L2 point with Metamask.
- Transfer to master ticket.
- Sign the transactions.
- Wait.
Expected behavior: There should probably be some message about waiting for the roller, and a suggestion to return to the home screen rather than making the user feel like they need to wait with the page open with nothing happening.
Ethereum network: Mainnet
Login method (please complete the following information): Metamask via Trezor
OK I confirmed that it did indeed transfer to a master ticket, so its only a UX issue.
I also saw this issue this morning. Something to add here is that the state on Bridge remains the same (i.e. it doesn't retrieve the newest keys and proxy addresses) which is fine, but might lead to confusion to some users ("I just changed my keys, but they are same!"), so the best scenario would be to notify the users that they need to log out, since their keys are no longer valid.
Good catch, and thank you for the suggestion @yosoyubik. Seems acceptable to me. @tomholford let's hold on this for the moment but might be good to get to before launch.
I also saw this issue this morning. Something to add here is that the state on Bridge remains the same (i.e. it doesn't retrieve the newest keys and proxy addresses) which is fine, but might lead to confusion to some users ("I just changed my keys, but they are same!"), so the best scenario would be to notify the users that they need to log out, since their keys are no longer valid.
I'd say we force a logout and dump anything in local storage.
local storage
Some context: bridge has always tried very hard to not use localstorage because it is fragile and potentially confusing, which aren't properties we want. All our features are/should be designed and implemented in such a way that logging in again with the same details allows bridge to recover and/or deduce what's going on.
This is easier for the L2 case, since we have ready access to pending transactions. For this issue, if we see pending transactions that would invalidate our current login method, we should indeed warn the user about this, prompting them to re-log with the new keys.
