Which platforms support WebPush?
Browser support by operating system
Note: invisible mode, private browsing mode, and visitor browser mode do not support network push.
Browser | Windows PC | macOS | Android | iOS (iPhone, iPad) |
---|---|---|---|---|
Chrome | Yes | Yes | Yes | No |
Firefox | Yes | Yes | Yes | No |
Safari | No | Yes | No | No |
Microsoft Edge | Yes | Yes | No | No |
Opera | Yes | Yes | Yes | No |
Note 1: Microsoft Edge (Updated in 2019), Opera, Samsung browser, Yandex and UC Browser are all Chromium-based browsers, which will be marked as Chrome in Engagelab.
Note 2: Internet Explorer no longer accept feature updates. Microsoft has turned its browser development to Edge platform.
Supported by browser version
Browser | Windows | MacOS | Android |
---|---|---|---|
Chrome | Chrome 42+ | Chrome 42+ | Chrome 105+ |
Firefox | Firefox v44+ | Firefox v44+ | Firefox v104+ |
Apple Safari | / | Safari V11.1+ | / |
Opera | Opera v29+ | Opera v29+ | Opera mobile v64+ |
Microsoft Edge | Edge v17+ | Edge v17+ | / |
If the browser is closed, can the user receive the notification?
- When you go through the engagelab channel, you must open the website to receive notifications.
- When you go through the system channel, you can receive notifications when you close the browser. Different platforms behave differently. For more information, see the following table:
Browser | Windows | MacOS |
---|---|---|
Chrome | yes, the browser process must be in the background | yes, the browser process must be in the background |
Firefox | yes, the browser process must be in the background | yes, the browser process must be in the background |
Safari | / | yes |
Opera | yes, the browser process must be in the background | yes, the browser process must be in the background |
Microsoft Edge | yes, the browser process must be in the background | yes, the browser process must be in the background |
On the Windows, all Windows are closed. If the browser is still running in the background, it can receive system notifications. If the browser process has been closed, it will not receive system notifications.
On the Mac OS X, even if all windows are closed, most browser processes will still run in the background, that is, they can receive system notifications. If the browser process is forced to exit, they will not receive system notifications. Safari can receive notifications without running, because they are sent directly to the operating system. Users need to register Safari notifications first, and then receive notifications even if Safari is completely disabled.
The notification is valid for 3 days and will be permanently lost after 3 days. For example, assume that the user should receive Firefox push notification but the Firefox is disabled. If the user opens the Firefox within 3 days, the user will receive only the last push notification that has not expired. If the user opens the Firefox after 3 days, the user will not receive the push notification sent three days ago.
Troubleshooting methods for failure to receive notifications
1. Check the permission on the notification bar of the webpage.
2. Check whether the browser application notification permission is enabled.
Windows notification settings:
- turn off focus assistance. For more information, see microsoft official documentation .
- Check Settings> Notifications and actions> turn on obtaining notifications from applications and other senders. Make sure that your site and browser are also enabled. For more information, see microsoft official documentation .
macOS notification settings:
- in System Preferences> Notifications> Chrome or the selected browser, make sure that allow notifications is turned on.
- In System Preferences> Notifications> Focus> Do Not Disturb and sleep, make sure this mode is not turned on or you are within the allowed notification time.
- macOS also has a temporary "do not disturb" notification setting in the upper-right corner menu> scroll up.
3. The browser manufacturer is unstable, so switching the Engagelab channel is preferred.
{
"from":"web_push",
"to":{
"registration_id":[
"xxx"
]
},
"body":{
"platform":"web",
"notification":{
"web":{
"title":"web_push",
"alert":"Hi,MTPush !",
"url":"http://www.google.com",
"extras":{
"web-key1":"web-value1"
}
}
},
"options":{
"time_to_live":30,
"third_party_channel":{
"w3push":{
"distribution":"mtpush"
}
}
},
"request_id":"12345678",
"custom_args":"business info"
}
}
Can't the safari browser pop up a notification?
Step 1: Check the Safari browser permissions, note whether the allow switch is enabled , the normal situation is shown in the figure:
step 2: click Check push service status and browser Notification permission, the normal situation is shown in the figure:
Step 3: Click Safari browser - preferences click website - click notification to check whether the Notification Center website is allowed, the normal situation is shown in the figure.
note:
- Click stop push, the Aurora push message will not be received, and the page needs to be refreshed.
- A domain name is configured with multiple html pages. Do not remove the website permissions of the notification center. After the deletion, the html pages will not receive notifications. (You need to find the main page and obtain the website Notification permission again)
why do different browsers have the same regid?
A: If an integrated domain name configured for the same application is userStr by the same user, the same rid will be generated, regardless of whether the same browser is used.
About User Unique Identifier Explanation
- During initialization, a unique string must be filled in to generate a unique UID. This UID is the identity recognition code for push notifications and is not related to the device.
- When a user uses the same
user_str
, they will be recognized as the same user. Subscribing on different browsers or devices will replace the subscription information with the latest one for message sending. For example, User A subscribes with the sameuser_str
on browsers a1, a2, and a3 in succession. In theory, only the last subscribed a3 can receive messages, preventing the same user from receiving multiple messages and excessive message sending. The backend always saves only the latest subscription information for the same UID. - Message subscriptions can be canceled, and the SDK provides a cancel subscription interface. This cancel subscription interface only cancels the binding relationship between UID and subscription information and does not modify the browser's notification permissions.
- In theory,
user_str
should correspond one-to-one with actual users. In some specific situations, users may be in visitor mode. Developers need to explicitly generate a uniqueuser_str
based on their actual situation. The SDK does not automatically perform default processing to avoid errors in the process when developers have not properly handled the relationship betweenuser_str
and actual users, resulting in statistical data not matching the expected situation. When users are in visitor mode, developers can refer to the following function to generate a uniqueuser_str
. This function uses the user's browser as the unique identity recognition code. Note that this processing method will cause the same user to generate a newuser_str
when changing browsers, devices, or clearing cache.
Sample function:function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();
このコードブロックは、フローティングウィンドウに表示されます