-
Notifications
You must be signed in to change notification settings - Fork 114
Ensure that notifications on legacy http integrations navigate to the origin #1349
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
base: player-model-main
Are you sure you want to change the base?
Conversation
Code already handles each property separately so there's no reason to force passing the whole object.
There was an issue with legacy HTTP integrations where the defaultNotificationUrl was never saved in the DB. To account for this, we try to get the default URL from the app config on notification click and save it to the DB for the future use. Choosing between notification received and clicked to add this logic, decided on notification clicked to avoid doing extra api call when the user may never click the notification.
02fee96 to
976d696
Compare
jkasten2
left a comment
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.
Logic looks good to me, just one comment on types.
src/libraries/WorkerMessenger.ts
Outdated
| } | ||
|
|
||
| onWorkerMessageReceivedFromPage(event: ServiceWorkerMessageEvent) { | ||
| onWorkerMessageReceivedFromPage(event: any) { |
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.
Instead of any I believe we can switch to ExtendableMessageEvent instead.
src/libraries/WorkerMessenger.ts
Outdated
| otherwise, the listener callback is executed. | ||
| */ | ||
| onPageMessageReceivedFromServiceWorker(event: ServiceWorkerMessageEvent) { | ||
| onPageMessageReceivedFromServiceWorker(event: any) { |
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.
Instead of any I believe we can switch to ExtendableMessageEvent instead.
22b3ee1 to
94caa07
Compare
Ensure that notifications on legacy http integrations navigate to the origin
Details
There was an issue with legacy HTTP integrations where the defaultNotificationUrl was never saved in the DB. As the result if a notification was sent without explicit launch url, the service worker logic would default to the worker's scope which is in the os.tc domain. This in turn would redirect users to OneSignal dashboard rather than to the customer's site.
To account for missing default notification url, we try to get the default URL from the app config on notification click and save it to the DB for the future use. Choosing between notification received and clicked to add this logic, decided on notification clicked to avoid doing extra api call when the user may never click the notification.
Verified in Chrome, Firefox and Safari that when clicking on a notification it redirects to the origin instead of the os.tc domain.
Note: will only merge it after Thanksgiving
Systems Affected
Validation
Tests
There seem to be no tests for the service worker flows so didn't add any new ones 🤔 Did an extensive manual test in Chrome, Safari and Firefox.
Info
Checklist
Programming Checklist
Interfaces:
Functions:
Typescript:
Other:
elem of arraysyntax. PreferforEachor usemapcontextif possible. Instead, we can pass it to function/constructor so that we don't callOneSignal.contextScreenshots
Info
http.notification.click.fix.mov
Checklist
Related Tickets
https://app.asana.com/1/780103692902078/project/1211950939908862/task/1210115044974433?focus=true
This change is