Last modified: 2014-04-29 19:39:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2939 - "You've got new message" is displayed even after a revert
"You've got new message" is displayed even after a revert
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: 9157 (view as bug list)
Depends on: 21860
  Show dependency treegraph
Reported: 2005-07-22 23:58 UTC by Tomasz Wegrzanowski
Modified: 2014-04-29 19:39 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Tomasz Wegrzanowski 2005-07-22 23:58:01 UTC
There's a pretty serious spam problem at now.

One (banned) problem user pastes links to his flames on talkpages of many users.
The spam is of course quickly reverted, however the spammed users still see
"You've got a new message".
So they naturally check their talkpages, and not seeing anything new, they go to
history to check what's going on.

That way, a lot of users loss time, and a major portion of the spam gets
through, in spite of reverting, as it's seen via history links.

There are 2 solution that I think are easy to implement:
* Remember which edit was last seen by the user (obviously done now in some
form, for newtalk flagging to work). And when the newtalk flag is positive and
the "You've got a new message" is about to be displayed, check once more - if
the current version is exactly the same as the last seen version (= spam was
reverted), clear the flag and don't report the new message.
* Option of nuking edits, instead of just reverting them. Add a sysop option to
throw the edit directly to the archive for deleted edits, and pretend it never
happened. Whether it's easy to implement or not depends on database schema. It
would be very easy if we just considered the version with the most recent date
that has not been deleted to be the current version. In 1.4 we didn't. I'm not
sure about 1.5. Anyway, I think the first solution is the preferred one.
Comment 1 Carlos 2005-07-24 17:41:08 UTC
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...
Comment 2 Tomasz Wegrzanowski 2005-07-24 18:02:46 UTC
(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.
Comment 3 Antoine "hashar" Musso (WMF) 2005-08-13 08:30:58 UTC
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.
Comment 4 Tomasz Wegrzanowski 2005-08-14 21:21:38 UTC
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.
Comment 5 Tomasz Wegrzanowski 2006-07-05 23:44:40 UTC
(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.
Comment 6 Brion Vibber 2006-07-05 23:54:41 UTC
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 

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

Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-05 23:59:37 UTC
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.
Comment 8 Brion Vibber 2006-07-06 00:00:39 UTC
I think something like this would never ever be "optional per-user".
Rather, it would have to be implemented such that it works correctly.
Comment 9 Tomasz Wegrzanowski 2006-07-06 00:12:42 UTC
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.

(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.
Comment 10 Rob Church 2006-07-06 00:17:56 UTC
Checking the contents of two revisions on each page view like that is too expensive.
Comment 11 Tomasz Wegrzanowski 2006-07-06 00:27:00 UTC
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.
Comment 12 Rob Church 2007-03-03 16:48:26 UTC
*** Bug 9157 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2007-03-06 19:14:37 UTC
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?
Comment 14 Nathan Larson 2008-11-02 02:41:15 UTC
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.
Comment 15 Siebrand Mazeland 2009-02-02 12:02:24 UTC
Closed as LATER. There is no meta data on edits being a revert.
Comment 16 Brion Vibber 2011-11-29 21:21:19 UTC
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!
Comment 17 Krinkle 2011-12-30 20:42:41 UTC
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.
Comment 18 matanya 2012-08-06 11:11:56 UTC
Probably won't be fixed before new notification & messaging system.
Comment 19 Dan Garry 2014-04-29 15:03:15 UTC
Moving to Echo.
Comment 20 Dan Garry 2014-04-29 15:03:45 UTC
Probably invalid now that all this stuff is handled by Echo.
Comment 21 Max Semenik 2014-04-29 16:23:30 UTC
Echo is not part of MW, so reopening.

Note You need to log in before you can comment on or make changes to this bug.