angus wrote:

So, if someone writes you a message telling you to watch my edits because I've
been spamming, I can just delete that message and you'll never know... hmm...

taw wrote:

(In reply to comment #1)

So, if someone writes you a message telling you to watch my edits because I've
been spamming, I can just delete that message and you'll never know... hmm...

In this solution, the only case when someone won't see a message is if it has
been reverted and not reverted back later, that is - if no change is present on
recipient's talk page.

If you revert valid messages, someone will unrevert your revert (... and block
you), and the intended recipient will see the message.

Whatever happens to a talk page, its owner should be notified with a message.
Stopping notification on revert is open to other kind of abuses.

taw wrote:

The only abuse I see is the spam. It's happening right now, it's already a
serious problem (a few hundred users spammed on pl.wp, by just a single troll
without any help from spambots), and will only become more serious when more
spammers learn about this bug. E.g. what could we do in the current setup if
some spammer bot-posted herbal viagra ads on 1000 user talk pages ?
We're providing better spam seen:spam sent ratio than almost any other kind of spam.

So could you elaborate what kind of abuses are we stopping by notifying about
reverted messaged ?
I fail to see even a purely theoretical potential of abuse, and it's certainly
not happening now, unlike the spam.

We can leave an option for paranoid users to notify in spite of the revert, but
I'm sure hardly anyone would bother.

taw wrote:

(About WONTFIX) Why do we want to keep this bug again ?
It is a bug, it has been abused in the past, and fixing it doesn't seem to be
that hard.

The main issue is that you don't know whether a revert *should* clear
the flag or not. In this sequence for instance you would not want it to
clear:

1. User:Alice posts -> sets new message flag
2. User:Bob vandalizes
3. User:Cory reverts to User:Alice's post

ayg wrote:

Well, that's not a question of whether to WONTFIX. If this is implemented at
all, it should certainly be optional per-user. As for whether it should be
(sooner or later), I think Tomasz makes a pretty good point, although I've been
interested the one or two times someone's spam to my talk page has been reverted.

I think something like this would never ever be "optional per-user".
Rather, it would have to be implemented such that it works correctly.

taw wrote:

How about an implementation where in addition to new message flag we keep
revision id
of the last version of talk page visited.
If on page request new message flag is true, we check if content of the last
seen revision is identical
to the current revision. If so, we clear new message flag.

So:
(newtalk=false, last_seen_rev_id=1, cur_rev_id=1)

1. User:Alice posts -> sets new message flag

(newtalk=true, last_seen_rev_id=1, cur_rev_id=2)

2. User:Bob vandalizes

(newtalk=true, last_seen_rev_id=1, cur_rev_id=3)

3. User:Cory reverts to User:Alice's post

(newtalk=true, last_seen_rev_id=1, cur_rev_id=4)

4. User opens some random page.

(contents of rev 1 == contents of rev 4 -> silently clear newtalk flag)

Or we could drop newtalk, as last_seen_rev_id contains all the relevant information
and newtalk is simply an optimization here.

robchur wrote:

Checking the contents of two revisions on each page view like that is too expensive.

taw wrote:

The check would only be done if newtalk was set.

It should be pretty easy to make sure it's checked no more than once per user
talk page edit.
Or we could move the check to user talk page save =>
if contents of last_seen_rev_id equal contents of the new revision, clear
newtalk flag.

robchur wrote:

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

The check would only have to be done on set, presumably, not on every page read.
A revision number is one possibility; another might be to keep a hash of the
previous version?

If I recall correctly, throttles can be set to control how fast someone can post messages to multiple users' talk pages. It seems like throttling, combined with the various automated tools (e.g. Cryptoderk's) for keeping an eye on Recent Changes, should be enough to keep spammers in check. On a wiki with 1,000 active contributors, presumably there are people watching Recent Changes frequently enough to catch spammers before they can hit too many pages.

Even if we make it so that the reverted talk page doesn't set the new messages flag, won't the changes still show up on the recipient's (and possibly other users') watchlist? So their attention will still be drawn to it.

Closed as LATER. There is no meta data on edits being a revert.

Reopening -- rev_sha1 field is being added in 1.19 and would be usable to look this up.

Also switching notification & messaging systems will eventually render this obsolete, but if we do it first, hey neat!

Aside from rev_sha1, I think rev_text_id instead of rev_id could've been used already. A revert re-uses the same text id, right ? Limiting it to only cases like revert where the contents don't just happen to be the same but are brought back to an earlier state.

Probably won't be fixed before new notification & messaging system.

Moving to Echo.

Probably invalid now that all this stuff is handled by Echo.

Echo is not part of MW, so reopening.

Tagging Editing-team as this may be of interested to them as part of the Discussion Tools being worked on.

In a nut shell: MediaWiki tracks the revision number of the talk page when you last opened it. If it has changed, then the orange bar "You have new talk page messages" is displayed to the user.

The problem: If someone leaves a message on your talk page, but then changes their mind (self-revert) or if somone reverts it as spam, then the contents are identical to what you've last seen, there is nothing new.

This could possibly be solved either by clearing the "new talk" flag for the target user during the revert, or by tracking the "new talk" flag based on the content ID rather than the revision number.

Change 761305 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/core@master] Suppress user talk page notification for reverted edits

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

Got another one of these today, rather confusing experience, especially because these result in typically two separate notification emails. The first one I tend be able to spot as likely vandalism from new or unnamed accounts, but the second is often a more prominent name that could quite plausibly send me a message:

... except of course they didn't. They were just reverting the vandalism. There is not one byte added, only removed.

https://meta.wikimedia.org/w/index.php?title=User_talk%3AKrinkle&diff=28762129&oldid=28762088

Change #761305 abandoned by Hashar:

[mediawiki/core@master] Suppress user talk page notification for reverted edits

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

Change #761305 restored by Thcipriani:

[mediawiki/core@master] Suppress user talk page notification for reverted edits

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