Resolves T4139. This implements desktop notifications for Conpherence.
- Maniphest Tasks
- T4139: Add support for desktop notifications
Chrome only allows the page to request permission for desktop notifications when initiated by a user action (such as a click). Hence this has to live here (or on some other button).
How do I actually get these to work? I can get the "allow" prompt, but neither Chrome nor Safari seem to actually show any kind of notifications. Am I expected to need to do something else?
Once you click Allow, get someone to send a message in a thread, while that tab is not in focus.
It doesn't send you desktop notifications about a thread if you currently have that browser tab in focus, since you're already focused on that.
(+@chad as an FYI)
This demo works for me in Firefox and Chrome, so I think it's not an issue on my system:
I can dig into and see what's going on. The permission request works but the actual notifications don't show up for me right now.
In general, I think we have a fair amount of work to do before this is a meaningful entry in the chat space. In particular:
- We don't show connection status right now, but should. Particularly, if a thread isn't going to automatically update anymore, the fact that there is a connection issue should be shown in the UI. I imagine this being a "connecting / live / reconnecting / IT DUN BROKE" kind of thing that's usually out of the way but called out better when in an error state.
- We don't reconnect after a failure. I think if you close your laptop and open it up again later, everything will mysteriously no longer update. This is made worse because it's not shown in the UI. We should detect connection failures and reconnect (probably with random waits and backoff).
- We still don't walk administrators through setup very well. A lot of users trying to configure this stuff run into trouble. We can, e.g., raise the Error 2048 security error in more useful detail, and make the connection status clickable and such. We've gotten way better here in the last round of updates, but still aren't in a great place.
- There are still a lot of ways to wedge the Flash client by having a stray browser window open in some other browser. I think these are mostly connection issues, but I think we should be namespacing the local connections with the client version and probably user PHID to mitigate this. This primarily impacts developers, but it's desirable to make this stuff easier to develop.
- We should play sounds when messages are received.
- We should probably update page titles with (1) and such.
- When we play a sound or show a desktop notification, the user should only receive one copy, even if they have multiple tabs open. We can do this by making the Flash master responsible.
- Sounds and notifications probably need to be customizable, both as a preference and per-thread. That would give us a better place to prompt for permission.
- A bunch of the Conpherence JS is really sketchy right now and needs an iteration.
- Some of the defaults and design decisions could probably use a second look: we have more experience with the application now, and things like defaulting to sending an email for every message may no longer make much sense.
- Before we put too much more work into things, I'd like to have a clearer picture of where we're taking Conpherence with respect to public threads, rooms, projects and objects.
- We should fully hand over the E monogram to Calendar and give Conpherence Z or some other unused monogram.
I'd ideally like to do at least some of this work before pursuing the most user-visible UI features, like notifications. The cat's already sort of out of the bag since threads update, but exposing this stuff in the UI without having the infrastructure to support it is inviting a lot of people to show up in IRC asking questions for which the answer is "you have to wait for us to fix things so you can reasonably use them".
(In terms of actual implementation difficulty, I think this list is a lot smaller than it looks: only the Conpherence JS stuff has any legacy/migration issues, and the Aphlict development environment is relatively reasonable after this last iteration on it.)
If either of you have the ambition/time to work on any of this, I can break it up a little better and file some tasks.
On desktop notifications specifically:
- I think there should be a new preference in Settings > Conpherence Preferences > Desktop Notifications which controls default behavior. This can also have a "test" button, have room to show things like "doesn't work in your browser", "you'll get prompted if you enable", etc.
- This is off by default, at least for now. When the user enables it, we prompt them to grant permissions.
- This setting can be adjusted per-thread in (Some Thread) > Settings > (New desktop setting), like email notifications.
- How does/should this tie into desktop notifications for Phabricator notifications? Maybe there's a separate setting for that, and we just put the "learn about / set up / test" control on both panels?
If there any means to gate this as 'experimental' in Conpherence Preferences? I would like to see these live on secure if we're going to commit to addressing some of Evan's UX concerns.
Some related tickets:
- T5281: Aphlict master doesn't handle connection failures
- T5365: Aphlict client should reconnect after a failure
- T5366: Provide tools to assist administrators in setting up Aphlict
- T5367: Play a sound when a notification is received
- T5368: Update page title to display notification count
- T5344: Multiplex AJAX calls from Aphlict clients through the JX.Leader