Page MenuHomePhabricator

Add a confirmation button to "Mark all pages as visited" on the Watchlist, and update via ajax
Closed, ResolvedPublic

Description

Inspired by https://en.wikipedia.org/wiki/User:NQ/WatchlistResetConfirm.js which adds a confirmation button, and then updates the watchlist using ajax instead of requiring a page reload.

So we should add a OO.ui.confirm dialog when the button is pressed, then submit an ajax request to the MW API, and finally update the CSS classes to mark all the pages as visited. This will all be done in JavaScript.

Event Timeline

I would like to learn how this is done anyways, so I'll just keep up with this. :)

Change 326233 had a related patch set uploaded (by Sn1per):
Move Special:Watchlist auto-reload check from PHP to JS

https://gerrit.wikimedia.org/r/326233

Change 326242 had a related patch set uploaded (by Sn1per):
Mark pages on watchlist as visited using JS without reload

https://gerrit.wikimedia.org/r/326242

Change 326233 merged by jenkins-bot:
Move Special:Watchlist auto-reload check from PHP to JS

https://gerrit.wikimedia.org/r/326233

Change 326242 merged by jenkins-bot:
Mark pages on watchlist as visited using JS without reload

https://gerrit.wikimedia.org/r/326242

Legoktm added a project: User-notice.

How can I opt out of this? It's really annoying. Please provide an opt-out option in preferences.

@BethNaught: As far as I know you cannot, but as the watchlist does not get reloaded the whole process is way faster than before.

Adding

$(function() {
    $watchlistReset = $('#mw-watchlist-resetbutton');
    $watchlistReset.submit( function ( event ) {
        $watchlistReset.off( 'submit' ).submit();
    });
});

to common.js should restore original functionality (although the confirm dialog does pop up, the page immediately reloads).

Needing a extra click is not good :/
I used to click "Mark all pages visited", and at the time the watchlist page was loading I changed to another tab in my browser. Now I need to confirm the action, or nothing happens to the watchlist. Maybe I just have to get used to this new system.

Adding

$(function() {
    $watchlistReset = $('#mw-watchlist-resetbutton');
    $watchlistReset.submit( function ( event ) {
        $watchlistReset.off( 'submit' ).submit();
    });
});

to common.js should restore original functionality (although the confirm dialog does pop up, the page immediately reloads).

Thank you. I put it in my global JS and it's working. Interestingly the dialog does not pop up for me on my tablet.

Since the original form-submission-based reset didn't require a confirmation, how about removing the dialog confirmation and immediately resetting the watchlist via JS? It wouldn't require a reload but wouldn't add another extra click.

Since the original form-submission-based reset didn't require a confirmation, how about removing the dialog confirmation and immediately resetting the watchlist via JS? It wouldn't require a reload but wouldn't add another extra click.

Or just adding a preference opt out/in option would work (the people who want the prompt would complain too much if it was just removed outright).

Change 327684 had a related patch set uploaded (by Sn1per):
Don't show dialog to confirm whether to reset watchlist

https://gerrit.wikimedia.org/r/327684

You can press "enter" to confirm the dialog, which seems not too inconvenient to me, compared to having an action that is impossible to undo. Andre is right that the whole button is faster now, but it'll seem slower because of the confirmation step.

Actually it’s not faster, because the site has to be reloaded manually afterwards to show new entries. So it still takes the time to reload (like before) plus the new waiting for the dialog to apear (up to six seconds for me) and the time to mark everything watched.

Those new entries might even have been marked as read without beeing shown. Previously they were marked as read, but at least shown at the same time.

Also I can’t even use my Watchlist now, because the button always gets the disabled attribute set. It does still mark everything as watched after removing the attribute manually though.

I note that the task description lacks a use case or expected benefit for this change. Was the goal to further T16123: [DO NOT USE] Make MediaWiki more AJAXy (tracking)?