-
Notifications
You must be signed in to change notification settings - Fork 886
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
On click action, the browser focuses on the tab with same host, but doesn't open the new URL [messaging] #3922
Comments
Same problem here |
Same, would love this fix or a way to force the new url or force open a new tab. |
Same problem here. Any news on that? :D |
If you will look little bit lower, you will see a line that creates and then sends a message to focused client
So you can listen for this message in your application and then open link, stored in click_action, or maybe from your data, sent with notification navigator.serviceWorker.onmessage = event => {
if (event.data.messageType === 'notification-clicked') {
window.location.href = event.data.notification.click_action;
}
}; |
The solution of @ArStah works like a charm. In my usecase (a chat app), this was very imporant, as the notifications should open the correct chat (URL), even if the PWA was still active in memory |
This is still the case and adding a |
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
Steps to reproduce:
When clicking on a message with
payload.fcmOptions.link
orpayload.notification.click_action
, the browser tries to find a tab with the same host as the URL in message. If this tab doesn't exist, the browser opens a new one with the the message's URL; otherwise, it just focuses on the found tab, but doesn't open the new URL.Therefore, if there is a inactive tab on https://example.com/good-bye, clicking on a message with
payload.fcmOptions.link: 'https://example.com/cart'
will focus on tab https://example.com/good-bye, instead of opening https://example.com/cart.Relevant Code:
I think this issue was caused by a modification in the method
SwController.getWindowClient
by pull request #2772.The controller tries to find a client based on a URL. If it succeeds, the service worker focuses on this tab. If it fails, the service worker opens a new tab.
Before the commit 18fb16b, no clients would be returned if there was no tab with the same URL:
firebase-js-sdk/packages/messaging/src/controllers/sw-controller.ts
Lines 280 to 285 in 5a60243
After the merge, a tab with the same
location.host
than message's URL is being reused, ignoring the passed URL:firebase-js-sdk/packages/messaging/src/controllers/sw-controller.ts
Lines 280 to 285 in 18fb16b
In the scenario prior 18fb16b (@firebase/messaging <= 0.6.13), the service worker would open the message's URL in a new tab.
In the scenario after 18fb16b (@firebase/messaging > 0.6.13), the service worker only focuses on any tab with same
host
, ignoring the message's URL.The text was updated successfully, but these errors were encountered: