Last modified: 2014-11-04 22:52:26 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 9213 - New-messages bar not coming up and/or getting stuck up for IP addresses
New-messages bar not coming up and/or getting stuck up for IP addresses
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.11.x
All All
: High major with 20 votes (vote)
: ---
Assigned To: Brion Vibber
http://en.wikipedia.org/w/index.php?t...
:
: 9623 10370 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-07 16:07 UTC by ais523
Modified: 2014-11-04 22:52 UTC (History)
16 users (show)

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


Attachments

Description ais523 2007-03-07 16:07:00 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.
Comment 1 wikibug 2007-03-30 03:58:11 UTC
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
Comment 2 Aaron Schulz 2007-04-05 04:14:54 UTC
Please give a list of instructions to repeat this problem.
Comment 3 wikibug 2007-04-05 06:34:29 UTC
(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.
Comment 4 Rob Church 2007-04-05 16:46:53 UTC
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.
Comment 5 wikibug 2007-04-05 23:26:15 UTC
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.
Comment 6 wikibug 2007-04-09 04:13:43 UTC
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
Comment 7 Yonatan Horan 2007-04-09 07:51:12 UTC
No, it doesn't. For me the message bar always shows up even if I've read the
message.
Comment 8 Brion Vibber 2007-04-09 14:30:53 UTC
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 ;)
Comment 9 Brion Vibber 2007-04-09 20:08:15 UTC
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...
Comment 10 wikibug 2007-04-12 00:18:51 UTC
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.
Comment 11 Rob Church 2007-04-12 08:45:18 UTC
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.
Comment 12 Raimond Spekking 2007-04-19 05:37:48 UTC
*** Bug 9623 has been marked as a duplicate of this bug. ***
Comment 13 wikibug 2007-05-04 23:39:52 UTC
A discussion about this bug is going on at
http://en.wikipedia.org/wiki/Wikipedia_talk:Administrator_intervention_against_vandalism#Bug_ID_9213
Comment 14 wikibug 2007-05-19 07:46:07 UTC
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
Comment 15 slakr 2007-06-07 14:21:50 UTC
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
Comment 16 ais523 2007-06-07 14:26:32 UTC
(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.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-07 23:57:51 UTC
(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.
Comment 18 slakr 2007-06-08 00:15:36 UTC
(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
Comment 19 Rob Church 2007-06-10 00:17:14 UTC
(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.
Comment 20 Brion Vibber 2007-06-26 15:11:02 UTC
*** Bug 10370 has been marked as a duplicate of this bug. ***
Comment 21 Antonio Vernon 2007-07-03 17:15:24 UTC
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.
Comment 22 Roan Kattouw 2007-07-03 18:51:22 UTC
(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?
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-03 22:26:06 UTC
(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?
Comment 24 wikibug 2007-07-28 05:35:10 UTC
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?
Comment 25 wikihdt83 2007-08-10 21:55:50 UTC
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...
Comment 26 Brion Vibber 2007-08-11 13:39:39 UTC
It's on my list.
Comment 27 Gurch 2007-10-02 23:05:41 UTC
Still on your list?
Comment 28 Casey Brown 2007-10-02 23:07:37 UTC
(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)
Comment 29 Tim Starling 2007-10-03 08:49:00 UTC
Hopefully fixed in r26357.
Comment 30 Andrew Garrett 2007-10-08 09:22:48 UTC
Assuming Tim forgot to RESOLVE this. Feel free to reopen, if I've made a mistake.
Comment 31 Rotem Liss 2007-10-26 09:28:26 UTC
The problem doesn't seem to appear now in Wikipedia.
Comment 32 wikihdt83 2007-10-27 06:32:37 UTC
Does the new messages operate on the browser cookies? For some reason they do not show up if the cookies are disabled.
Comment 33 Brion Vibber 2007-11-30 21:39:02 UTC
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.
Comment 34 slakr 2007-11-30 21:52:52 UTC
(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.
Comment 35 slakr 2008-05-12 18:46:54 UTC
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

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


Navigation
Links