Last modified: 2012-05-03 02:42:38 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 34469 - (un)watch button broken
(un)watch button broken
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
All All
: Normal major (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
Depends on: 34409
Blocks: 31217
  Show dependency treegraph
Reported: 2012-02-17 12:02 UTC by Nemo
Modified: 2012-05-03 02:42 UTC (History)
7 users (show)

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


Description Nemo 2012-02-17 12:02:43 UTC
People have reported not being able to pages to their watchlist here on meta. I've confirmed that it's also happening on, so it's probably a 1.19 issue. Steps to reproduce: go to a page you don't yet follow, and try to watch it. The reverse (trying to unfollow a watched page) doesn't work either. guillom 11:55, 17 February 2012 (UTC)
Error is "An error occurred while changing your watchlist settings for" [...].

[[Special:EditWatchlist/raw]] works.

Seems to be an error with token, the button gives a link like and if you remove the trailing slash it works

In this case, see also bug 24339.
Comment 1 Nemo 2012-02-17 12:11:37 UTC
On further testing, sometimes I'm not provided a token at all in the link, while the slash doesn't seem to matter.
Comment 2 Sam Reed (reedy) 2012-02-17 13:59:11 UTC
I suspect Timo is to blame...
Comment 3 Sam Reed (reedy) 2012-02-17 14:36:37 UTC
%2B%5C is +\ like the api uses
Comment 4 Rob Lanphier 2012-02-17 17:47:59 UTC
Yup, we should hold off on any more deployments until we get this fixed.
Comment 5 Aaron Schulz 2012-02-17 21:52:02 UTC
I don't have this problem on my own testwiki.
Comment 6 Sam Reed (reedy) 2012-02-17 23:15:15 UTC
It seems to have fixed itself on my test wiki...

Replicable on, but seems fine...
Comment 7 Erik Moeller 2012-02-18 01:23:19 UTC
Fixed by actually deploying r111695.
Comment 8 Erik Moeller 2012-02-18 01:23:52 UTC
(Some odd caching issues seem to cause things to be still broken with ?debug=true , but fixed in production at this point. Debug mode issues should be examined separately.)
Comment 9 Rob Lanphier 2012-02-18 02:44:17 UTC
We embarked on a bugfixing mission to fix bug 34469 on Friday afternoon.  This bug is a problem with adding and removing items from ones watchlist.

Several of us spent a lot of time looking at this issue.  We thought this one was fixed by r111695, with there only being a problem with deployment of this file.  After Andrew scap'd the entire tree to ensure we had a consistent environment, we found it more difficult to reproduce the problem, but still can in isolated instances.

The most peculiar part of this is that this seems to be dependent on which user is logged in.  Aaron first discovered that he wasn't able to watch pages on enwikibooks, which RobLa confirmed.  Erik had no problem watchlisting with his main account.  We even tried logging in on each other's machines, and still witnessed the problem.  Erik then discovered that he wasn't able to watchlist on eowiki.

RobLa was able to switch browsers from Chrome to Firefox, and have it work with an account that failed under Chrome.

What seems to be a reliable failure is appending ?debug=1 to the bug seems to reliably expose the issue (that is, it's always broken).

The common denominator when this fails is that mw.user.options fails to load, which is easily confirmed by calling mw.user.options.get() from the javascript console.  This gets back to our old friend, bug 34409, which is a much bigger problem than just watchlists.

Bug 34409 is a blocker for 1.19, and we may need to roll back until we get this fixed.
Comment 10 Rob Lanphier 2012-02-18 18:00:58 UTC
With the passage of time and the kicking of the proxy caches that's happened, this bug has partially disappeared.  (I can't reproduce it under normal conditions)

With debug=true, it still reproduces pretty reliably.  However, it may not be dependent on bug 34409 after all.  There is a valid mw.user.options and mw.user.token object.  With debug=false, mw.user.tokens.values.editToken is "50bbcmumblemumblemumblemumble+\".  With debug=true, mw.user.tokens.values.editToken is "+\"
Comment 11 Michael M. 2012-02-19 09:13:31 UTC
(In reply to comment #10)
> With debug=true, it still reproduces pretty reliably.  However, it may not be
> dependent on bug 34409 after all.  There is a valid mw.user.options and
> mw.user.token object.  With debug=false, mw.user.tokens.values.editToken is
> "50bbcmumblemumblemumblemumble+\".  With debug=true,
> mw.user.tokens.values.editToken is "+\"

With debug=true the tokens are served from, but the browser doesn't send the login cookie there, so the user is treated as anonymous, hence editToken === '+\'.
Comment 12 Sam Reed (reedy) 2012-02-20 20:18:06 UTC
Per above, does this still need Highest/major?
Comment 13 Rob Lanphier 2012-02-20 21:54:07 UTC
(In reply to comment #12)
> Per above, does this still need Highest/major?

Probably not.  Leaving on the 1.19wmf1 milestone, though, since not having a reliable debug mode will probably bite anyone who is trying to diagnose a script problem, of which we should anticipate many given our current problems.
Comment 14 Trevor Parscal 2012-02-21 22:13:37 UTC
Resolved in r112052 by preventing user token and user options modules from being served through bits, which was causing them to give logged in users generic (cached) responses.

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