Page MenuHomePhabricator

Synchronise state of notifications between tabs
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):

It would be great to have the notification status (number and icon status) synchronized.

One way to do a lightweight version would be to synchronize using localStorage events. That would work at least within a single project. That could also be done with no changes on the API/server side. So should be a fairly easy change :).

You could pull state from server, but that would be heavy when working with many tabs. You would still have to do some optimisation to only pull state for current tab and still sync the state via other means then network. You could use workers I guess, not sure how it would work with many tabs though.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

  1. Someone responds to a topic I subscribe.
  2. I open many tabs e.g. to review changes in observed articles.
  3. All of the tabs get notifications.
  4. I read the notification on one of the tabs. Mark it as read.
  5. I go back to reviews, closing each tab one by one.
  6. Each of the tabs still has an unread notification.

Unread notifications are just distracting. I never know if I already read them or if the state is broken.
Sometimes I even re-open or reload all tabs to get the status cleared.

Benefits (why should this be implemented?):

Everybody that opens many tabs. I know users that literally have 100s of tabs open and work on them.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I made a quick prototype to better show how you could do this.

You can test this with any html like this:

	<div style="position:absolute; left:.5em; top:.5em; width:83px;" id="storage_test">S <span></span></div>
	<script src="test_ls.js"></script>

Open e.g. 3 windows and emit change in devtools console like so:

emitNotification(3)

You will notice that will change all tabs and windows immediately.

So in a normal situation you could just run emitNotification when user click on one of the notification icons. Or to be more exact after you get data from the server.

obraz.png (144×487 px, 7 KB)

Tgr subscribed.

See T113125: Investigate using service workers to provide real-time Echo notifications in the browser (push notifications). I'm not sure a sync-between-tabs-only version is worth the effort and maintenance burden.

Hm... I see this is long time in the works. Looks interesting. Not sure if you want Push Notifications to replacement for current notifications (and not sure if that would be even possible).

If I'm reading the RFC (T249065) correctly this will be a new kind of notifications, right? Seems like it is more about re-engagement and news. And I think Push Notifications are more acceptable for things like that. For things you can miss (PN can easily get lost or users will not subscribe).

So, I think having state-synchronisation mechanism is still worth some time. I think it would actually be rather easy to develop and test. Will not require any new infrastructure or anything like that. Could probably even be made as a user-script. But I doubt it would be stable as a user-script (unless there are some good hooks for notification buttons).

Looks interesting. Not sure if you want Push Notifications to replacement for current notifications (and not sure if that would be even possible).

I think you are thinking about the Web Notifications API, which is different from the Push API. The Push API just lets the server push events the browser, and lets a web worker react to that in an arbitrary way (e.g. by updating the webpage).

If I'm reading the RFC (T249065) correctly this will be a new kind of notifications, right?

That RFC is about running our own push notifications servers, which was needed by the mobile apps. It's not related to the web push task. In theory web push could use that server, but browsers provide their own push infrastructure so it's not necessary. (Maybe it's easier though, I don't know.)
In any case, the RFC is not about a new kind of notification but about a new mechanism for getting the existing notifications to clients (the "Push" column in MediaWiki's notification preferences menu). Before, mobile apps had to poll the Echo API to get new notifications, which is bad for battery etc. Now, they are waken when there is a new Echo event. Whether that event is surfaced to the user via the OS-builtin notification popup is something the app (or web worker) can decide. The WIP patch does that, a fully polished version would probably give the user control over it though.

So, I think having state-synchronisation mechanism is still worth some time.

It could be complimentary (the WIP patch doesn't include it, but we would probably want to sync webpage state if we have push notifications) but I'm not sure a localStorage-based mechanism could be reused for push updates, as localStorage is not available to web workers.
I guess the code is simple enough that it might be worth adding it just for the time being, though.

It could be complimentary (the WIP patch doesn't include it, but we would probably want to sync webpage state if we have push notifications) but I'm not sure a localStorage-based mechanism could be reused for push updates, as localStorage is not available to web workers.

Yes, LS is not available in worker context. So if the update loop would be inside of a worker then BroadcastChannel would be more appropriate. Does pretty much the same thing, just maybe a bit more complicated to setup (especially if you don't have workers yet). Also have worse browser compat. Not sure if Wikipedia still gets a lot of Chrome on Windows XP users ;) (I know such users are still active in Poland so I imagine there should be some users like that if you care).
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API#browser_compatibility

We generally aim for full support for current and previous browser versions and graceful degradation for everything else (doc).

It seems like we are not (or not correctly) tracking OS version since 2018; back then XP in total was at 1%. So I wouldn't worry about it.

It turned out be much easier to do and more stable with the Broadcast Channel after all. Available as gadget for now at least:
https://meta.wikimedia.org/wiki/User:Nux/notificationsSync.js

Installation:

  1. https://meta.wikimedia.org/wiki/Special:MyPage/global.js
  2. Insert and save:
mw.loader.load( 'https://meta.wikimedia.org/w/index.php?action=raw&ctype=text/javascript&smaxage=21600&maxage=86121&title=User:Nux/notificationsSync.js' );