[OS X] Notifications are not cleared / removed when emails are viewed / read

[simonsickle-old]

In OS X, notifications are sent to the user's notification center. Most applications like the stock mail app will clear notifications from here once an email is read. This is not the case, however. Even after you read a message, you will find the notification center extremely cluttered.

To replicate this on OS X, simply send a few emails over and view the notification center.

• Are there any related issues? Try searching for both open and closed issues here: https://github.com/nylas/N1/issues?q=is%3Aissue. Keep in mind that email features are often described differently on different platforms. (Conversations == threads, shortcuts == hotkeys, etc.)
  Not that I saw
• What operating system are you using? Mac OS X
• What version of N1 are you using?
  version 0.4.5-b0ec335 (0.4.5-b0ec335)

Bug?

• Do you have any third-party plugins installed?
  No
• Is the issue related to a specific email provider (Gmail, Exchange, etc.)?
  No
• Is the issue reproducible with a particular attachment, message, signature, etc?
  Try to provide an example as a file attachment or a screenshot.
  No

[mbilker]

Is this possible with N1 from the Javascript side? Does a native module for OS X Notification management need to be made?

[courajs]

This has a pretty simple solution from the javascript side.
N1 is using native notifications via Electron's implementation of the HTML5 Notifications API.
This means new Notification() returns an object with a close() method.
So, we just keep a list of the notifications we send, and close them when a message is read. (Closing an already closed notification has no effect)

The only flaw I see with this is that these Notification objects have no close or dismiss event you can listen for. This means we will be stuck with the objects if the user dismisses the notification and never reads the email. Seems like an acceptably small memory leak to me though. We can always just give the list a max length, or give notifications a max age.

There is an alternative - service workers get a different API. They receive a close event, and they're also able to get a list of open notifications (meaning we never need to store a list in the first place). It doesn't appeal to me to pull in a service worker just for this though. The concept of a service worker just doesn't really mesh with the idea of a persistently-open desktop app. I also don't know how difficult it would be to pull a service worker into the existing build and test process.