Correctly handle not showing notifications in a service-worker friendly way

[taoeffect]

Problem

#2394 handles not displaying notifications to the user when the user is already looking at the chat by checking the current route.

This doesn't work in the context of the service-worker, which is where gi.actions will live once #2357 is merged.

Another consideration is whether the user has been idle. Even if the user is looking at the chat screen, we may still want to play a sound if they've been idle for a sufficient period of time. We currently use idleVue to check this, but this logic isn't used in #2394.

Solution

Handle all of this in a service-worker friendly way.

[corrideat]

This doesn't work in the context of the service-worker, which is where gi.actions will live once #2357 is merged.

To expand on this: it doesn't work in the SW because the SW doesn't have access to the router. The SW might (I haven't checked), however, have access to the raw URLs for each client.

Handle all of this in a service-worker friendly way.

There are two ways I can think of this may be handled. Either way, since there can be several active tabs or windows open at once (e.g., two foreground windows), this probably needs to be an array in the SW.

If the SW can see its clients URLs

The SW can check each active tab URL and omit notifications. The downside of this is that we might need to hardcode the URL components, although a shared import between the UI and the SW could help.

Event-based approach

The tab could send an event to the SW telling it its active and which events to skip. If done this way, it should probably also include some kind of ping mechanism (or the SW listening to removed clients) to handle tabs that crash.