Sort of. There's nothing stopping you from using script inside a Service Worker to send those notifications. Calling them push notification is troublesome as the Web Push API and Notification API are actually two entirely separate things.
Yikes, that really seems like abuse of HTTP/2 semantics to me. My understanding has always been that server push in HTTP/2 is only intended to prime the client cache for requests you know they're about to (or likely to) make. [1]
> Pushed responses are always associated with an explicit request from the client.
I'd rather see additional frame types defined that allow for bidirectional communication (i.e. websockets 2.0) than overriding and conflating the PUSH_PROMISE frame type.
I've built a plug & play app for Web Push Notifications. It comes with an analytics dashboard and an interface for users to manage their subscription. If anyone is interested to try it, you can see the demo at https://www.pushroll.com
Any reason why you couldn't instead have an optional drop-in Shim that allows developers to use the current/modern HTML5 Notifications API syntax, where the shim simply adds supports to older/other browsers? I hate introducing additional APIs if it's not necessary. In the future when the browsers you care about support the Notifications API it's easiest to simply remove the shim.
Quick apology for confusing the terms "push notification" and "desktop notification". I forgot "push" usually refers to sites that use service workers to send notifications to the desktop regardless of whether the browser window is open. This library requires the window remain open for the notification to be shown.
In the web app I work on, we have a toast component that we use to show the user status messages. It's usually used for showing error messages. I've been aware of desktop notifications being around or a couple years now, but I haven't used em.
What guidelines or general rule of thumb do you use when deciding if something is worth a notification?
I too had this issue. I appears that notifications don't show in full screen mode. When I returned Chrome to a windowed app on my Mac the notifications appeared.
I think I ran into the issue before as well.. however, I think that's an issue with how Chrome handles its notifications. I don't think there's anything in the library that could cause this behavior. A known issue is that the library is currently broken in Safari. I will investigate why when I have some free time.
Does mobile have a comparable feature? Native Push Notifications are an entirely different beast; afaik, there is no way to have browser type notifications like this.
Chrome on Android does support push notifications from the browser. Facebook makes use of this and you can actually get push notifications from Facebook without using their app. Facebook requests in the Chrome browser to use notifications and then you can receive them without even having the browser app open.
For push notifications, yes, but these are "browser / desktop" notifications, which only show up while the application is running. It's possible this works on mobile with the app running in the background, but I haven't seen it before.
I just tested on Chrome 50.0.2661.102 (64-bit) on OSX 10.11.4 and it seems to work. What OS are you running? Did it ask you permission to show notifications? Are there any errors in the developer console?
Why would it require HTTPS? This is a javascript library that allows you to hook into a native browser function (showing desktop notifications). There are no web services involved.
Why does this require HTTPS? How do I work around this during development?
Service workers require secure origins to ensure that the service worker script is from the intended origin and hasn’t come about from a man-in-the-middle attack. Currently, that means using HTTPS on live sites, though localhost will work during development.
To answer the "how do I work around this during development": non-HTTPS is permitted on localhost (this is at least the case in Chrome). The spec also hints at this (https://w3c.github.io/push-api/#security-and-privacy-conside...). But, as has already been mentioned, this is about desktop notifications and not web push.
So, I think there is some misunderstanding here. What you've linked here are Push notifications, which yes, go through GCM and do require web service calls. This JS library is doing Desktop notifications, which afaik, are an entirely different thing, and are strictly limited to "within the context of the active page."
Presumably grandparent post was paranoid that http websites have some lower status in terms of being able to send notifications. Not a likely scenario, but not an entirely unreasonable question.
The browser push APIs do require HTTPS, since browsers refuse to install service workers otherwise (which is required for them to function...). That said, the demo is hosted over plain HTTP, and seems to work for me (Chrome 50, Linux).
