Page MenuHomePhabricator

Obtain wl_notificationtimestamp on page view
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):
When viewing any page talk pages, have access to the timestamp of when the user last viewed the page wl_notificationtimestamp. Most logical place is probably mw.user?

Use case(s):
Userscript that marks new content since your last visit, userscript that tells you when you last visited the page.

Benefits:
There's a catch-22 to making an API call for wl_notificationtimestamp. When the user visits a page, wl_notificationtimestamp gets cleared. So the request needs to be made before the user visits the page. Lacking a crystal ball, I can't do that. The current alternative is to track it myself, which requires either using localStorage (which doesn't share across devices/browsers) or writing to a preference every single pageview which is painful, wasteful and a potential source of race conditions (if the user quickly opens multiple pages in tabs conflicts become extremely difficult to avoid)

Event Timeline

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

This information is already stored somewhere, when you go to a history page you see "updated since your last visit".

https://www.mediawiki.org/wiki/Manual:$wgShowUpdatedMarker

If watchlisted page was changed after it was visited

Use case:
Userscript that marks new content since your last visit, userscript that tells you when you last visited the page.

Is this a request from users on a WMF wiki, or for a third-party MediaWiki site?

What is the broader use case? Why does a person want the site to tell them when they were last there?

The current alternative is to track it myself, which requires either using localStorage (which doesn't share across devices) or writing to a preference every single pageview which is painful, wasteful and a potential source of race conditions […]

I'm not sure how this relates to ResourceLoader, which is the bundling and delivery system for CSS and JavaScript code. Something like this would be expensive to run and operate at Wikimedia Foundation scale, not to mention the privacy and performance implications of doing so.

I would suggest indeed to use localStorage and to limit the scope to specific pages, under specific circumstances, and for a limited period of time. E.g. if the tool you're working on is to create a new category and make it easy to put articles in it, you could have the category creation wizard "start" the tracking and then for the next 1 hour when viewing pages and on Special:Search, etc, offer a quick way to add it to the category you created and possibly on the category page offer a way when you go back there to select recently viewed pages during this session.

For WMF wikis or MediaWiki core defaults, I'm reasonably certain this isn't going to happen as-written due to scaling requirements. However I find quite often that problems can be solved in other ways as well once they are seen separately from a particular technical solution, and then more viable solutions can start to take form. So understanding the higher-level objective here might help.

For a third-party wiki, if you do need exactly this, I'd recommend setting up a separate web app in which you expose a read-write API that authenticates with the MediaWiki site, and then pings it on every page view and stores the current rev ID or timestamp together with the page_id (wgArticleId). The same API can then also return the previously stored information. Of course, without limitations or abuse control, this will eventually run out of space or come under attack, so solutions for that will need to be put in place as well depending on how public the wiki is.

"What is the broader use case? Why does a person want the site to tell them when they were last there?"

Among other things, my script can highlight new comments since your last visit in discussions.

Something like this would be expensive to run and operate at Wikimedia Foundation scale, not to mention the privacy and performance implications of doing so.

You already query the value for history pages, but providing wl_notificationtimestamp on the page itself has severe performance/privacy implications?

However I find quite often that problems can be solved in other ways as well once they are seen separately from a particular technical solution

My script now regularly downloads a big chunk of watchlist data and caches that in localStorage. It's imperfect: if the user visits talk page A on their phone and then starts a session on their laptop by visiting talk page A (as opposed to starting a session by visiting the main page, watchlist or any other non-talk page), the phone visit won't be taken into account. And the watchlist query can miss pages.

This is a particular piece of information that by its very nature can't be obtained with a simply API call.

AlexisJazz renamed this task from Obtain timestamp of when the user last viewed the page to Obtain wl_notificationtimestamp on page view.Sep 21 2022, 2:13 PM
AlexisJazz updated the task description. (Show Details)