New-messages bar not coming up and/or getting stuck up for IP addresses
Closed, ResolvedPublic

Description

Author: ais523

Description:
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.


Version: 1.11.x
Severity: major
URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=113329299#IPs_and_the_new-message_bar

bzimport set Reference to bz9213.
bzimport created this task.Via LegacyMar 7 2007, 4:07 PM
bzimport added a comment.Via ConduitMar 30 2007, 3:58 AM
aaron added a comment.Via ConduitApr 5 2007, 4:14 AM

Please give a list of instructions to repeat this problem.

bzimport added a comment.Via ConduitApr 5 2007, 6:34 AM

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.

bzimport added a comment.Via ConduitApr 5 2007, 4:46 PM

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.

bzimport added a comment.Via ConduitApr 5 2007, 11:26 PM

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.

bzimport added a comment.Via ConduitApr 9 2007, 4:13 AM

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

bzimport added a comment.Via ConduitApr 9 2007, 7:51 AM

yonatanh wrote:

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

brion added a comment.Via ConduitApr 9 2007, 2:30 PM

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 ;)

brion added a comment.Via ConduitApr 9 2007, 8:08 PM

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...

bzimport added a comment.Via ConduitApr 12 2007, 12:18 AM

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.

bzimport added a comment.Via ConduitApr 12 2007, 8:45 AM

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.

Raymond added a comment.Via ConduitApr 19 2007, 5:37 AM
  • Bug 9623 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 19 2007, 7:46 AM

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

Slakr added a comment.Via ConduitJun 7 2007, 2:21 PM

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

bzimport added a comment.Via ConduitJun 7 2007, 2:26 PM

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.

bzimport added a comment.Via ConduitJun 7 2007, 11:57 PM

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.

Slakr added a comment.Via ConduitJun 8 2007, 12:15 AM

(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

bzimport added a comment.Via ConduitJun 10 2007, 12:17 AM

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.

brion added a comment.Via ConduitJun 26 2007, 3:11 PM
  • Bug 10370 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJul 3 2007, 5:15 PM

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.

Catrope added a comment.Via ConduitJul 3 2007, 6:51 PM

(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?

bzimport added a comment.Via ConduitJul 3 2007, 10:26 PM

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.
  1. 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?

bzimport added a comment.Via ConduitJul 28 2007, 5:35 AM

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?

bzimport added a comment.Via ConduitAug 10 2007, 9:55 PM

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...

brion added a comment.Via ConduitAug 11 2007, 1:39 PM

It's on my list.

bzimport added a comment.Via ConduitOct 2 2007, 11:05 PM

matthew.britton wrote:

Still on your list?

bzimport added a comment.Via ConduitOct 2 2007, 11:07 PM

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)

tstarling added a comment.Via ConduitOct 3 2007, 8:49 AM

Hopefully fixed in r26357.

werdna added a comment.Via ConduitOct 8 2007, 9:22 AM

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

bzimport added a comment.Via ConduitOct 26 2007, 9:28 AM

rotemliss wrote:

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

bzimport added a comment.Via ConduitOct 27 2007, 6:32 AM

wikihdt83 wrote:

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

brion added a comment.Via ConduitNov 30 2007, 9:39 PM

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.

Slakr added a comment.Via ConduitNov 30 2007, 9:52 PM

(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.

Slakr added a comment.Via ConduitMay 12 2008, 6:46 PM

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

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.