Last modified: 2014-11-04 22:52:26 UTC
Other relevant URLs: <http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_% 28technical%29&oldid=104535783#user_not_getting_orange_bar_for_new_messages>, <http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical% 29&oldid=102932147#Strange_problem_with_new_messages>, <http://en.wikipedia.org/wiki/Wikipedia:Help_desk/Archives/2007_February_28#IP_address>. Several times recently, users have reported problems with the new-messages bar when logged out; the bar seems to get 'stuck' in either a state where it always shows, or a state where it never shows. I'm not quite sure how to reproduce the bug, but one method worked for me recently: go to Special:Mypage when logged out to discover what MediaWiki is receiving your IP as, log in, edit your IP's User Talk page, log out again, and visit the Main Page. Doing this doesn't cause the new-messages bar to come up (at least, not when I tested it a few days ago on a wiki running MediaWiki 1.10-svn), but it ought to.
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.
(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.
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.
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.
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
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...
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.
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. ***
A discussion about this bug is going on at http://en.wikipedia.org/wiki/Wikipedia_talk:Administrator_intervention_against_vandalism#Bug_ID_9213
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
(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.
(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
(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. ***
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?
(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?
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?
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.
Still on your list?
(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.
The problem doesn't seem to appear now in Wikipedia.
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
