If you are using Chrome or Firefox on iOS, it should still work.
In his tests, it didnt. I don’t own an iOS-Device, so I cant test it on my own.
Are you sure? I was under the impression that other browsers were like “wrappers” with the same webkit and nitro under the hood. This has changed?
Got to the bottom of this by finding an old iPad to test on, and I can confirm the bug. It’s fixed in the latest.
Thanks for reporting!
Thanks for fixing! I’ll add a german translation for the new features tomorrow
Oops you’re right. I just remembered the plugin does not support iOS devices.
I have a question regarding the
Your site must use HTTPS part…
I’m running Discourse behind NGINX reverse proxy. Till the proxy, there is https enabled, but then all of the traffic goes to :80 port of the container.
In order for this plugin to work, should I have the traffic go to the https port of the container or not?
Right now, the plugin isn’t working and I’m trying to identify the issue
Thank you for your time!
As long as the site is loaded over HTTPS, it should work. Whether the traffic from your proxy to the container is over https or not does not matter AFAIK.
A few new features from the past week:
When enabled, this adds a banner for push notifications. It has been refined to fit in to the look and feel of other notification banners such that it does not steal too much real estate while still being an important element on the page:
The icon sets are now unified to match the notification icons from the notification dropdown:
You now have the ability to customize the small “badge” icon shown in the corners of the notifications using the
push notifications icon url setting. This is best customized with 96x96 monochrome images with transparency.
The notification will display as follows:
That’s all for now!
New notification permissions request bar?
Can you add a hook into the existing notifications permission request instead? Personally, when I see a bar like this I instinctively “bounce” and try to tell the website “no”.
I had a pretty striking double-take when I saw that it was Meta with that annoying bar!
Just refreshed after accepting the permission popup that appeared without clicking on the banner, and it’s still there:
I have that, but I think that is for Desktop notifications, that I do have enabled.
I’m not sure if it might be related, but earlier I allowed Push notifications and soon after my browser (Vivaldi) became unresponsive. It could be because I was running a resource heavy query locally, but maybe not?
Most sites are using a “pre-permission” banner, trying to be less intrusive. The default Chrome UI for example on mobile is a blocking popup .
Of course we still care and don’t want to annoy our users. Do you think we need to tweak any banner criteria?
Good catch, I think we need to check for
Notification.permission != 'granted in
Ideally, the push notifications plugin would be able to hook into this code here: So that when someone clicks “Accept” they get automatically signed up for push notifications. The only time the plugin should be adding its own banner is when
Notification.permission === 'granted' but
!pushNotificationSubscribed - i.e. someone accepted desktop notifications before the plugin was installed.
Really? You must be in a different experiment cohort, I get a scroll-dismissable bottom-of-the-screen “popup” tray. (It goes away when I scroll down & comes back when I scroll up, in sync with the URL bar hiding/appearing.)
You do bring up a few good points of feedback:
- I should not display the banner when the user has accepted permissions.
- I need to find a way to better integrate the two notification systems - push notifications and desktop notifications.
re: notification permission prompts, I also see the super annoying popup:
Worse, I need to allow or block now - I cannot dismiss or defer it by clicking outside of it, either. If it prompts without me doing anything, I’m inclined to deny the things. I could have sworn I had a version before where I had the tray like you mentioned, but this is what I see now.
This is why I think the banner is a good compromise. Until we can be sure that all browsers have some slick out-of-the-way signal to inform the user the website wants to send notifications, this is the best option for those who want to prompt.
In that case, the wording could definitely be improved.
Ah, nice - I am 100% down for rewording the banner. I like the way that shows context as to why the software wants your permissions
I think we should go with “replied” instead of “mentioned” which is more frequent and easier to understand.
And that wording suggests a different time to ask for permissions - right after you post something and the question hasn’t been answered yet.
Instead of asking as soon as you log in, by asking right after you’ve made a post1, the value proposition is extremely obvious and people can give Informed Consent to receive notifications.
1: Except for the @/discobot intro PM, that should be excluded from the permission prompt banner.