wikibug wrote:

This bug is still happening and has not been fixed. Per
http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_user_warnings#Do_Warnings_show_up_on_anonymous_IPs.3F

Please give a list of instructions to repeat this problem.

wikibug wrote:

(In reply to comment #2)

Please give a list of instructions to repeat this problem.

What happens:

(1)Anonymous IP starts vandalizing pages on Wikipedia
(2)Registered User reverts vandalism and posts a warning or message on the anon
IP's talk page
(3)One of two problems may occur once a message is posted on anon IP talk page:
(a)The bright orange "You have new messages" bar does *not* pop up so the anon
IP. does not receive message
*or*
(b)The "You have new messages" bar does pop up but it *stays stuck* on the top
of the page even after you read the message as anon IP. Clearing
the cache does not seem to remove the bar nor does browsing to another page.

robchur wrote:

We could be getting stale entries stuck in the Squid caches for anonymous users,
although in theory, "you have new messages"-headed pages aren't supposed to be
cached by Squid in the first place.

wikibug wrote:

For me, the problem is that the "You have new messages" never shows up no matter
how many messages are placed in my IP talk page.

wikibug wrote:

Apparently it happens to '''all''' IP addresses. Which raises a question, if the
IPs are not getting the warning messages than whats the use of posting such
messages in the talk page?

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Orange_warning_bar_not_showing_up_on_IP_talk_page.3F

yonatanh wrote:

No, it doesn't. For me the message bar always shows up even if I've read the
message.

I wasn't seeing the messages bar on Friday on en.wikipedia.org when I tested this,
but I do see it now (until I cleared it by viewing the message).

There may be an intermittent issue... _possibly_ related to lag during database
updates?
Or possibly something else ;)

Peeking at the code, I might also suspect the memcached bit.

Anon newtalk info is cached separately in memcached, and I'm not sure if it's
updating the cache properly.

User::setNewtalk() may not be properly updating things if the cached value is
wrong...
User::getNewtalk() caches info that's taken from a slave...

wikibug wrote:

The message I left on my IP address a week ago suddenly shows up now. I have
browsed Wikipedia every day logged out for the past week and the message I left
now shows up. Why does a message left in the IP talk page take a *week* to show
up? This needs to be fixed as soon as possible.

robchur wrote:

Further comments on this bug should be restricted to those providing information
about the problem (not individual case studies) and/or technical solutions, such
as a patch.

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

wikibug wrote:

A discussion about this bug is going on at
http://en.wikipedia.org/wiki/Wikipedia_talk:Administrator_intervention_against_vandalism#Bug_ID_9213

wikibug wrote:

A group of Wikipedians have created a page that is saying how "frustrated" they are with this issue. See here

http://en.wikipedia.org/wiki/Category:Wikipedians_who_are_terribly_frustrated_about_Bug_ID_9213

Is it possible that this is not really an issue of server-side, but of client-side? That is, in any page the user visits that he's already visited, his browser by default caches unless the page is forced to expire (which isn't done on articles, for example). This might be why boxes get "stuck" or "never show." They're there-- the user has simply cached the page and the browser/proxy hasn't checked back in because it thinks nothing's changed on the page. It's half right, because the page itself hasn't changed-- only the junk that's added to the template on-the-fly to make the "you have messages" box.

If this is the case, then there are a couple of solutions available:

1. Expire all pages. Not feasible for large-scale sites.
2. Make an AJAX check to see if there is usertalk, and expire the AJAX requests as they're sent. You'd probably notice the new bandwidth consumption on large-scale sites, but it shouldn't be too bad if all you're transferring is a bool (on top of the headers, of course).
3. Something I overlooked server-side that makes this easier? I'm a little sleepless at the moment :P

Cheers.
-Kurt

ais523 wrote:

(In reply to comment #15)

Is it possible that this is not really an issue of server-side, but of
client-side? That is, in any page the user visits that he's already visited,
his browser by default caches unless the page is forced to expire (which isn't
done on articles, for example).

'Fraid not; I made sure to press Ctrl-F5 to bypass my browser cache when verifying this bug on test.wikipedia.org, and on [[w:en:Wikipedia:Help Desk]] there are reports from anons about this bug still persisting, even on the Help Desk itself, which they've presumably never visited before they come to post their complaint. All that can be done then is to say "that's a known bug 9213, nobody seems to know what's causing it at the moment"; but it's pretty clear that something server-side is going on.

ayg wrote:

(In reply to comment #15)

Is it possible that this is not really an issue of server-side, but of
client-side? That is, in any page the user visits that he's already visited,
his browser by default caches unless the page is forced to expire (which isn't
done on articles, for example).

A simple check of the HTTP headers would have verified that MediaWiki sends Cache-Control: private, s-maxage=0, max-age=0, must-revalidate. An HTTP 1.1 client will send a request with If-Modified-Since if it has a cached copy, and receive a 304 if the cache remains valid.

(In reply to comment #17)

(In reply to comment #15)

Is it possible that this is not really an issue of server-side, but of
client-side? That is, in any page the user visits that he's already visited,
his browser by default caches unless the page is forced to expire (which isn't
done on articles, for example).

A simple check of the HTTP headers would have verified that MediaWiki sends
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate. An HTTP 1.1
client will send a request with If-Modified-Since if it has a cached copy, and
receive a 304 if the cache remains valid.

Exactly. Therein lies the problem-- the article the user is visiting hasn't actually changed, so the check-back will reflect that instead of accounting for the new talk and sending the appropriate header. That is, the page itself hsan't changed, as the cached version reflects the prior state of the page when it was first requested by the client. However, the "last modified time" of _that specific page_ doesn't necessarily change when newtalk is received or viewed, except on always changing pages/articles.

This might be something to consider. Either that, or I'm totally on crack. :P

robchur wrote:

(In reply to comment #9)

Peeking at the code, I might also suspect the memcached bit.

Take a look at http://svn.wikimedia.org/svnroot/mediawiki/branches/robchurch/newtalk; I've rewritten a lot of the code to make it more robust. If deemed appropriate, we can switch over to pulling "newtalk" status from the master.

On reviewing the appropriate code, I'm now a bit less inclined to suspect shared caches as the problem.

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

amvernon wrote:

Starting this morning when I logged onto WP about 2 hours ago I have been getting the new message bar even after checking last change.

(In reply to comment #21)

Starting this morning when I logged onto WP about 2 hours ago I have been
getting the new message bar even after checking last change.

Have you tried clearing your cache (hard refreshing with Shift+F5)? Does this also occur when editing or moving a page?

ayg wrote:

(In reply to comment #22)

Have you tried clearing your cache (hard refreshing with Shift+F5)?

1. Shift-F5 doesn't hard-refresh in any browser I know of. It's Ctrl-F5 in IE and Firefox, and just F5 in Opera. You're probably confusing it with Shift-Reload, i.e., clicking the "Reload" or "Refresh" button while holding down Shift.

2. That only clears client cache, which is totally irrelevant to a piece of HTML being stuck on the page.

The latter question is of interest, though: does it occur when editing a page, for instance?

wikibug wrote:

This bug is related happens on version 1.10 and up of MediaWiki. This bug was reported around the start of 2007 and that was when Wikipedia was upgraded to use version 1.10 of MediaWiki. I tested it out on version 1.93 and the messages bar works correctly while on 1.10, it does not work properly. Is it possible to revert back to version 1.9.3 to temporary fix this bug?

wikihdt83 wrote:

Have the devs been working on this? This bug still has not been resolved even though its been 5 months since its initial reporting over here. Can a dev post an update on the situation? Most users on Wikipedia still do not know of this bug...

It's on my list.

matthew.britton wrote:

Still on your list?

bugs wrote:

(In reply to comment #27)

Still on your list?

Do you know how long Brion's list *is*?! :-P (still a valid question, but it's a *huge* list :-P)

Hopefully fixed in r26357.

Assuming Tim forgot to RESOLVE this. Feel free to reopen, if I've made a mistake.

rotemliss wrote:

The problem doesn't seem to appear now in Wikipedia.

wikihdt83 wrote:

Does the new messages operate on the browser cookies? For some reason they do not show up if the cookies are disabled.

Page views are aggressively cached for anonymous users, so everyone without a cookie set will potentially get the same cached page view. (Particularly where we're using HTTP proxy caches as on Wikipedia.)

As a result, new messages notification is only shown if a session cookie is present, indicating that a private session is in progress and pages won't be shared. This generally means that you've either hit an 'edit' link or the login button at some point in your browsing session.

(In reply to comment #33)

Page views are aggressively cached for anonymous users, so everyone without a
cookie set will potentially get the same cached page view. (Particularly where
we're using HTTP proxy caches as on Wikipedia.)

As a result, new messages notification is only shown if a session cookie is
present, indicating that a private session is in progress and pages won't be
shared. This generally means that you've either hit an 'edit' link or the login
button at some point in your browsing session.

Hmm... if that's the case, the only easy way around it would be a once-per-pageload ajax using a tiny iframe that echoes either 0 or 1. On the upside, this could be on a totally different domain altogether, which will completely eliminate the overhead of the cookie headers, cache hit/miss headers, and other redundant stuff being sent on each request. On the downside, there are load considerations, which is directly related to the peak requests/second on the site.

It also occurs to me that, depending on one's permissions on any given encyclopedia and/or the scripts a person is using and/or a person's settings, the "minor edit" box will be ticked automatically, and, depending on one's user group permissions (nominornewtalk in specific), the box would simply not appear due to that being a feature-- not a bug. Anyyyyway, just thought I'd chime on on that. :P