Skip to content
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

Open notification UI when eth_requestAccounts waits for unlock #8508

Merged
merged 3 commits into from
May 5, 2020

Conversation

rekmarks
Copy link
Member

@rekmarks rekmarks commented May 4, 2020

Summary

This is a suggested feature.

Callers of AppStateController.getUnlockPromise can now cause the notification UI to open via a boolean parameter.

Justification

Currently, if the user lands a dapp that has permissions when the extension is locked, the dapp can't tell whether the user is already connected. Therefore, the dapp is likely to display a "Connect" button. This is what we do in our test dapp.

If the user clicks a "Connect" button in the above case, the extension browser action icon will get a badge, but the UI won't automatically open. This is in distinction to clicking a "Connect" button in a dapp that does not have permissions, which will cause the UI to open.

With this PR, the UI will open when the user clicks "Connect", regardless of whether the dapp has permissions or not. If the dapp has permissions, the UI will immediately close upon unlocking.

I believe that this is probably better than the UI not opening at all; it certainly feels more responsive to me.

@rekmarks rekmarks requested a review from a team as a code owner May 4, 2020 15:49
@rekmarks rekmarks changed the title Open notification UI on unlock request via eth_requestAccounts Open notification UI when eth_requestAccounts waits for unlock May 4, 2020
@metamaskbot
Copy link
Collaborator

Builds ready [15ccf9e]
Page Load Metrics (652 ± 36 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint308842157
domContentLoaded3888136507536
load3908156527536
domInteractive3888136507536

@rekmarks rekmarks added this to the v8.0.0 milestone May 4, 2020
* @returns {Promise<void>} A promise that resolves when the extension is
* unlocked, or immediately if the extension is already unlocked.
*/
getUnlockPromise () {
getUnlockPromise (showUnlockRequest) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: maybe this could be renamed to shouldShowUnlockRequest? Since the function is also called showUnlockRequest, I thought this was the function on my first read through until reading that JSDoc comment more closely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, alternatively, you could remove this parameter. It looks like it's always set to true in practice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I renamed it. It is always set to true in practice, but in case we ever want to use it for something else, it ought to save someone else time in the future, at virtually no cost today.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm having trouble thinking of a situation where we'd want it to be false though. In general, keeping a parameter in "just in case" seems like an odd choice, but 🤷‍♂️

@metamaskbot
Copy link
Collaborator

Builds ready [6733155]
Page Load Metrics (682 ± 18 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint32503642
domContentLoaded6337946803818
load6357966823818
domInteractive6337946803818

@rekmarks rekmarks requested a review from Gudahtt May 4, 2020 21:28
Copy link
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@rekmarks rekmarks merged commit 79d9209 into develop May 5, 2020
@rekmarks rekmarks deleted the open-on-wait-for-unlock branch May 5, 2020 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants