-
Notifications
You must be signed in to change notification settings - Fork 195
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
feat: unchain unlock call from enable screen #3143
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.
tACK
Tested and worked like intended. 👍 There is still a bug when you manually lock the extension after you enabled it on this website before, which leads to an erroneous state in the extension (you need to manually reload it afterwards in order to use it again). This bug was already in there for years though, so I don't think we need to fix that in this PR. tACK |
if ( | ||
isUnlocked && |
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.
don't we still need the unlock check? because if your new check fails for whatever reason then it's not unlocked and this action should not run.
…ghtning-browser-extension into unchain-unlock-enable
return custom error message object when error is not instance of Error
Describe the changes you have made in this PR
unchain unlock screen from enable screen
Link this PR to an issue [optional]
fixes triggering of enable screen for nostr when extension is locked, even if the provider was persisted before.
this also reduces the side effect of user needed to set permission again because of retriggering of enable screens
Type of change
(Remove other not matching type)
feat
: New feature (non-breaking change which adds functionality)Checklist