Last modified: 2010-05-15 15:29:26 UTC
My watchlist seems to be dropping articles I haven't unwatched, and picking up
ones I haven't watched, on both en and wikibooks. The articles in question are
ones that I have looked at, though.
My watchlist is definitely dropping articles that i have not unwatched. No one
else has noticed this? I just added Wikibooks:How to Play the Violin to my books
list, and read it, pressed edit without pressing submit and went to the
nonexistent discussion page. After some of these actions, but not all, and quite
randomly it seems, I go back to my watchlist and it is not on it anymore. I have
"watch all pages that I edit" selected in my preferences.
I took these steps on wikibooks:
1. go to violin article
2. press watch
3. go to watchlist - it's on my watchlist
4. go to violin through watchlist
5. leave it open for a bit
6. click on discussion
7. click on watchlist
The first time I did it, it was no longer on my watchlist. Every time since, it
is still there. Is this maybe related to having more than one wiki page open in
tabs? I am in Firefox 0.9.3 and I am always opening articles in different tabs
and editing them at the same time, etc. Something to do with cookies? Editing a
different article in another browser instance? I can't isolate the problem but
it's definitely happening.
And today two articles were on my wikipedia watchlist, en:Rose Island and
en:Republic of Minerva which I DID read yesterday, but did not edit and did not
push watch. These are some definite examples of a nebulous thing I have been
noticing for a long time, but couldn't prove was happening. This is not my
As people don't believe me, here is an example.
(I'm using Firefox 0.9.3.)
Watch my test articles: User:Omegatron/sandbox/watch1
User:Omegatron/sandbox/watch2. (Or any articles, I presume.) Open watchlist.
Test articles are on it. Middle click on article 1 and 2 "hist" links to open
history for each in a new tab. Keep an eye on the unwatch tab at the top.
Anything I do after this has variable results.
Click any of the "cur" links in 1. Click any of the "cur" links in 2. Edit 2.
Unwatch tab *sometimes* turns into watch tab. If it doesn't work try editing 1.
It almost always works to one or the other. If it doesn't try doing it again
from the beginning.
Hmm. I am trying to reproduce it and it still isn't exactly reproducible.
However, if I follow these steps and then go back and forth between the pages,
editing or pushing history, one of them will become unwatched. This must have to
do with cached pages or cookies or multiple tabs or something. VERY nebulous.
i tested in internet explorer and it doesn't seem to happen.
I was told to test with a different account. I did.
(http://en.wikipedia.org/wiki/User:Omegatron_test_account) The procedure I
described above did not directly cause any articles to drop off, as they do with
my normal accounts (on WP, Meta, and Wbooks), but one of the test articles
(watch1) did drop off twice while I was creating one of the others (watch3 and
watch4) for unknown, but probably related reasons.
Oh. It just did it with the test account, too, with default account settings.
just isn't as easy to recreate, but it does happen.
I was then able to make it happen more than once with
(http://en.wikipedia.org/wiki/User:Omegatron_test_account_2) with completely
new, default settings, though it is also more rare on that account (in other
words, I had to open histories and click curs and edit tabs several times before
one became unwatched.) It might have to do with loading two pages at once?
This is definitely happening on en:. There are three related issues:
* articles removed from the watchlist are not always removed
* [[Special:Watchlist]] often displays the previous list after removing articles
* watchlists sometimes stop updating; see bug 951
This may be an issue with the intermittent backlogs on the database slaves.
Certainly that's known to sometimes affect the results shown on Special:Watchlist.
This is a known, ongoing which has been separately reported a number of times
(for example bug 951).
This bug report also mentions an effect on the 'watch'/'unwatch' tab on page
views, however. I'm not certain whether this is something that would be expected
to be affected by lag on the slave servers or not, as generally current page views
should be coming from the master server if I understand correctly.
Since it's an intermittent problem and symptoms are not clearly separated from the
known lag issue, it's difficult to tell for certain if there is something more that
needs to be investigated and fixed.
> This may be an issue with the intermittent backlogs on the database slaves.
> Certainly that's known to sometimes affect the results shown on
> This is a known, ongoing which has been separately reported a number of times
> (for example bug 951).
> lag on the slave servers
would this cause a temporary change in watchlists until the lag clears or a
permanent one? this bug refers to a permanent change. articles being removed
or added to watchlists and staying that way for good...
Omegatron, does this still happen to you?
Are you using a prefetching HTTP proxy (a "web accelerator" or such)? Such a thing could be
hitting the watch and unwatch links in the background.
(In reply to comment #8)
> Omegatron, does this still happen to you?
> Are you using a prefetching HTTP proxy (a "web accelerator" or such)? Such a
thing could be
> hitting the watch and unwatch links in the background.
I haven't noticed it in a while. No web accelerators. Just opening multiple
articles in tabs in firefox. But it doesn't seem to be happening lately. Then
again, I have >1000 on my watchlist now. :-) I can try with a fresh account or
I can confirm this in 1.5beta1. I've clicked on multiple articles in my
watchlist, edited those articles and saved them, and they disappear from my
watchlist. If I click "edit watchlist", they're still there, and on the article
page, it says "unwatch" at the top, but if I try clicking unwatch, then watch
again, it still doesn't show up in my watchlist. This has never happened to me
before this version.
This could allow vandals to remain unnoticed. Consider it high priority.
Set version and URL from original reports. The 1.5 changes and the fix for bug
2647 may supersede this bug.
Does this still happen?
(Comment 10 doesn't sound like what's reported above.)
I closed this bug per comment #12; the lack of further activity suggests the problem disappeared. If not, please reopen.