Page MenuHomePhabricator

Update Echo Notifications in real time without page reloads
Open, HighPublic

Assigned To
Authored By
Nov 8 2011, 9:09 PM
Referenced Files
F31621297: image.png
Feb 18 2020, 3:48 PM
"Love" token, awarded by Liuxinyu970226."Love" token, awarded by Kaartic."Love" token, awarded by matej_suchanek."Love" token, awarded by Framawiki.


Classic 'new message' notifications about your talk page or LQT only show up when refreshing a page.

Polling the web API every couple minutes could be nice, especially if things like RecentChanges turn into more interactive pages that will be long-running.

Alternatively, a non-polling implementation (real-time) could use something like Server-Sent Events (browser support), WebSockets (browser support) with COMET fallback, T113125: Investigate using service workers to provide real-time Echo notifications in the browser (push notifications), or another option. There are libraries that handle some of the browser compatibility issues with these.



Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:07 AM
bzimport added a project: Notifications.
bzimport set Reference to bz32284.
bzimport added a subscriber: Unknown Object (MLST).

Brion: Is this ticket Echo territory nowadays? Should this be moved, or can this be considered closed?

Sounds like Echo territory for implementation -- has this been implemented in Echo, or is it still something that needs doing?

Not sure if that's implemented already, but if it was it would be Echo territory. Hence moving there. Might require fixing bug 32283 first...

See also bug 59879 (probably a duplicate?), particularly comment1 by legoktm

This is inconsistent with other sites where notification are shown in real-time, or at least while the user is on the page rather than leaving or explicitly reloading the page.

  • Bug 59879 has been marked as a duplicate of this bug. ***

I put together a POC at I8f7bc77d05762fd12927437f6450ae3f97eb84af.

It simply polls the API every 60 seconds to check for new notifications (it kinda but not really works).

That said, I don't think polling is a good idea. We should instead have some kind of websockets service pushing notifications to the user/browser. This might line up well with [[mw:Requests for comment/Publishing the RecentChanges feed]].

Kunal, sounds like a reasonable stopgap measure fix, as you said there are better ways to do it, How would you feel about increasing the polling frequency but tying it to an activity timer, associated with page scrolling or mouse movement, e.g. we poll at a higher frequency while we know the user is interacting with the page, and stop polling or poll much more infrequently when no activity is detected. Quora uses a similar approach.

Another metric of, is the user looking at the page could be a mixture of Page Visibility API and window focus and blur for older browsers compatibility.

For T75209, we need a more frequent update than "every 2 minutes".

Polling the API (whether every 2 minutes or every 1 minute or every second) is not truly real-time, IMHO (and also not performant).

Any objection to changing this task to be about true real-time (i.e. Server-Sent Events, WebSockets, COMET fallback and such)?

Sounds good unless it permanently blocks this task ;)

sent while mobile

Polling is not really real-time, as I said earlier. However, I think polling at a reasonable interval (not too much load on the server) is an appropriate interim solution for this. Detecting whether the user is really looking at the page (with page visibility API and such) as suggested by @Jaredzimmerman-WMF) could help with this.

I do think some kind of server push is better medium-term.

@Mattflaschen whats the highest polling frequency you'd be comfortable with, Ideally we'd be be talking about something in the single digit seconds when the window is in focus, and 30-90 when its out of focus?

@Mattflaschen whats the highest polling frequency you'd be comfortable with, Ideally we'd be be talking about something in the single digit seconds when the window is in focus, and 30-90 when its out of focus?

I'm not really sure. But my gut tells me that if you want to measure it in seconds (especially single-digit seconds, which I think would be a problem especially on higher-latency connections, and likely for the server), we're better off implementing server push.

If PHP is not suitable, it could perhaps be implemented as a service (similar to Parsoid, Citoid, Mathoid, Offline content generator).

JTannerWMF added a subscriber: JTannerWMF.

This is a powerful long-standing feature idea, but the team will not have time to work on it in the near future.

kostajh added subscribers: Shivanshbindal9, kostajh.

Assigning to @Shivanshbindal9 as this is in progress (see T219222).

Unassigned @Shivanshbindal9 (thanks again for all your work on this!). The functionality has been built, it needs to be tested, deployed to some wikis, and reviewed for performance. Some possible next steps here:

  1. enable on mediawiki/testwiki
  2. collect feedback
  3. performance review
  4. enable on more wikis...

Shouldn't we revisit it? We need approval to make the test happening.

@Trizek-WMF thanks, yes. I'm going to move it to Needs Discussion so it gets some visibility.