extension
extension copied to clipboard
leather-wallet
Refactor: Manifest Version 3
Try out this version of the Hiro Wallet - download extension builds.
Investigatory PR looking into move to MV3
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Updated |
|---|---|---|---|
| stacks-wallet-web | ✅ Ready (Inspect) | Visit Preview | Sep 13, 2022 at 0:04AM (UTC) |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
@kyranjamie @markmhx I tested this build today. I didn't run into any problems with software or hardware wallet. The only thing I ran into was this in the test-app, but I vaguely remember this being an issue we fixed on dev so maybe the branch just needs to be rebased?
Unchecked runtime.lastError: The message port closed before a response was received. error on /fund page
Thanks! Can I start QA'ing despite that fund page error? Or best to wait until resolved?
@markmhx it's good to be reviewed. I'm feeling good about it now, and wonder if we could line it up for release next Monday.
When I have the wallet open in the browser and login, it still looks locked when looking at the extension:
Looking at this further it looks like it shows both logged in at first and then when you do not use the extension window but browse accounts using the wallet as a page in the browser instead... it will lock the other screen at some point in time. In the video I am clicking some things but it doesn't look like that matters. It just locks after some time (<2 min.). Is that a new feature?
https://user-images.githubusercontent.com/33360391/206406543-1fa4b064-047d-4782-83e5-43edab01ee65.mp4
To @314159265359879's comment, not entirely sure how/if we can handle this. Unlike MV2, the ServiceWorker will eventually unload and go inactive. Per the docs there's no event fired when this happens. We can consider some alternatives, but not sure on the severity of this problem
To @314159265359879's comment, not entirely sure how/if we can handle this. Unlike MV2, the ServiceWorker will eventually unload and go inactive. Per the docs there's no event fired when this happens. We can consider some alternatives, but not sure on the severity of this problem
I am sure users can work around this and I can even see this as a security feature for the wallet because this way the wallet never remains logged in for long.
I am a bit worried about the duration with less then 2 minutes to automatically lock I think it may happen to often, and at times the user doesn't actually want it. Perhaps ideally the user can pick their own auto lock time, 10 minutes, 15 minutes, never? Something to add to the "expert mode" list of options for power users perhaps? If at all possible.
I think the failing Playwright test can be fixed by updating the deps to latest version,
yarn upgrade --latest --exact --pattern playwright
I'm also finding that the wallet suddenly locks after short periods of time and seemingly randomly.
It happened a couple times after I'd refreshed the full-screen wallet a couple of times, and another when I was in full-screen then opened up the popup view. All within a few minutes after having unlocked the wallet.
Once it happens, both subsequent full-screen and popup views result in the locked screen consistently.
The severity of this seems quite high to me. We don't want the wallet locking on users randomly often.
I'm looking into how constant polling of the wallet affects service worker lifetime, as well as better detection of locked state (so we can redirect users to sign back in). Not sure how effectively this will work, see 1c94d07. The current Xverse implementation faces the same issues, as it follows a very similar key persistence mechanism.
If polling does little, as far as I understand right now, there are two options:
- Deal with shorter session times. We can better direct users to re-sign in. It's arguable we shouldn't leave sessions unlocked for too long anyway.
- Reconsider key persistence model. This is where I sell this idea again.. If we ask for the key only when it's needed, e.g. when a user wants to sign a tx, they will be able to see their wallet from their cached address, with no need to enter their password.
I've tested the latest build with polling changes and unfortunately it's still locking me out quite frequently.
@kyranjamie anything in particular worth QA'ing with this build given the relevant MV3 changes, aside from seeing whether the wallet locks too frequently?
@markmhx Not really, just general interactions with the wallet. These changes touch the whole product, so anything not already covered by tests.
This build seems to have lost the option to open in a new tab via right-clicking the chrome icon (before/after):
Also when I install, it doesn't pop open a new tab by automatically to start onboarding which it should.
Tests found in https://github.com/hirosystems/wallet/tree/65729dd37cf3898b123ba7544835c2f13fe2dc6d/tests/specs
It seems this build has lost the ability to save state e.g. during the send flow:
https://github.com/hirosystems/wallet/assets/28991/dc540d59-eb2e-47bc-99e4-ccf116605c10
I'll continue to use this build as my main one for testing, though in general it's looking good aside from the two issues above (lost ability to open into its own tab and no state preservation)
As far as the Open in new tab option not working goes. I'm really not sure what to do about this. This happens because Chrome runs multiple service workers, for some unknown reason. I've seen this happen more in development than production builds, where files are often modified, but it can still happen.
This behaviour is widely reported in https://bugs.chromium.org/p/chromium/issues/detail?id=1316588 and other Chromium issues. There are workarounds, I've tried, such as reloading the extension when it detects many workers, but this has bad UX implications.
The only options I can see for this issue is to 1) live with it and hope for the best, 2) wait. I'm just not hopeful for any quick fixes seeing as this issue is > 1 year old
It'd be great we can schedule such that we have like 1 or 2 days dev use before pulling the trigger. I don't think it needs anymore QA though.
@kyranjamie were you able to restore the state preservation as reported lost here? https://github.com/hirosystems/wallet/pull/2651#issuecomment-1572608234
I'm finding while QA'ing @alter-eggo's increase fee PR (based on this one) that the send form isn't preserving state still / anymore: https://github.com/hirosystems/wallet/pull/3963