-
Notifications
You must be signed in to change notification settings - Fork 395
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
Do notify: Set up base NotificationService #3666
Conversation
6cc2dfa
to
9923b6a
Compare
0bec674
to
74f4de6
Compare
9923b6a
to
af6d8e6
Compare
74f4de6
to
39f07d2
Compare
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.
Couple of notes from me:
- These aren't push notifications (or just push notifications), they're notifications in general, so let's use that term throughout. This is why the original method on the notification service was
notify
rather thanpushNotification
, as an example. - Let's decouple the idea of having permission to notify (as defined by manifest v2) from the user having opted in to notifications. Originally this distinction was entirely contained in the
PreferencesService
. We should not remove the notification permission at the Chrome level once it's been granted, as we don't want to ever present a scenario where the user has to see a browser modal again (we don't control anything about these modals, and in particular we have no ability to give the user more information about why they're granting the permission, so we only present them when we have no other option). - We have both lint failures and unsigned commits here, so let's fix that. We also need to flip out of draft.
Of note, I can't approve (or request changes!) on the PR as I opened it haha. So once we're good here I'll ask @jagodarybacka to merge.
I think if we fix the above we'll probably be good to go.
4c4a57a
to
56ee86d
Compare
When setting this to true, the preferences service verifies that the underlying browser permission exists, and refuses to update the setting to true if it does not. This ensures that downstream consumers of the property won't expect to interact with objects that they don't have permissions for.
Missing are updates to test mocks and harnesses at the moment.
This lets us request the permission later on when we need it instead of insta-disabling the extension on upgrade (!!).
This shows the notification request over the Subscape loading page, which may not be the final form of the request.
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.
A couple of suggestions and questions below.
Could you update the PR description with testing steps? I know we don't have an option to show any notification yet so I wonder what state should I consider as working correctly
😊
}) | ||
|
||
return permissionRequest.then(async (granted) => { | ||
await this.db.setShouldShowNotifications(granted) |
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.
User can reject notifications from function setShouldShowNotifications
right? So at this point notification permission may not be granted at the browser level but the wallet will think it was granted 🤔 I think we should emit setNotificationsPermission
with a result of setShouldShowNotifications
instead
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.
It's why we use Promise here: the wallet waits to resolve the promise (true/false) and only then grants him permission, take a look at uiSliceEmitter.on("shouldShowNotifications", ...) in main.ts
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.
User can reject notifications from function setShouldShowNotifications right?
To get more specific here: the above permissionRequest
can fail from the user, in which case granted
here is false
. this.db.setShouldShowNotifications
does not trigger a request, however.
I've updated today's description in this PR. |
background/main.ts
Outdated
|
||
port.onDisconnect.addListener(() => { | ||
const networkNameAtClose = | ||
this.store.getState().ui.selectedAccount.network.name | ||
const networkNameAtClose = ui.selectedAccount.network.name |
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.
is this actually correct? I think UI state will be frozen to the one that we had when this.store.getState()
was called - is this expected behaviour? (actually, I'm not sure because I haven't checked if getState
gives us a copy of the state object or a state object that gets updated 😅)
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.
We generally should not expect that getState
is updated.
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.
For a change like this to an existing behavior, let's make sure we have a commit with a commit message that explains the motivation for the change. A lot of the stuff in main
that interacts with redux is very fiddly because it's syncing the lifecycle of the wallet popup with the background script.
This change looks like it can break the desired behavior, which is to check whether the network name changed during the lifetime of the popover. I don't see a clear reason for changing the existing code, and unfortunately the commit message has no details here, so it's hard to know if it's safe without doing a full debugger round.
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.
I have configured Prettier
on file saving, so it was changed automatically. It doesn't change logic, so keep it as it is.
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 prettier settings we have here by default should not do it 🤔 and I'm pretty sure the logic was changed as we noticed above, right?
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.
omg:)) yees, mea culpa! I didn't notice my change here before! :)
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.
All righty let's ship this one. @jagodarybacka I think you have to do the honors 😅
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.
✅
## What's Changed * Check connecting to dapp on different network after disconnecting by @michalinacienciala in #3654 * v0.51.0 by @Shadowfiend in #3652 * Fix typos by @xiaolou86 in #3668 * Alchemic Logs: Small improvements for eth_getLogs by @Shadowfiend in #3664 * Fix getting currently connected dapp info by @jagodarybacka in #3671 * Add static subcape link to the wallet by @jagodarybacka in #3670 * Fix e2e tests by @michalinacienciala in #3651 * Add Alchemy endpoint for Arbitrum Sepolia by @jagodarybacka in #3665 * Do notify: Set up base NotificationService by @Shadowfiend in #3666 ## New Contributors * @xiaolou86 made their first contribution in #3668 **Full Changelog**: v0.51.0...v0.52.0 Latest build: [extension-builds-3678](https://github.com/tahowallet/extension/suites/18415208655/artifacts/1067210815) (as of Wed, 22 Nov 2023 14:53:11 GMT).
This PR adds notification-related preference, service, optional manifest permission,
and code to request the permission on Subscape banner click.
More to come!
UPDATE: 11/20/23
PR is rebased with the main branch. Force push was required because of unverified commits.
To open a dialog window with a request notification you need to click the link hidden in the Subscape bubble.
The first push notification will be added in #3667
Latest build: extension-builds-3666 (as of Wed, 22 Nov 2023 13:59:40 GMT).