Last modified: 2014-11-17 10:35:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36409, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34409 - 'mw.user.options' and 'mw.user.tokens' are sometimes empty on 1.19, breaking watchlist, gadgets, etc.
'mw.user.options' and 'mw.user.tokens' are sometimes empty on 1.19, breaking ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.19
All All
: Highest blocker with 1 vote (vote)
: 1.19.0 release
Assigned To: Roan Kattouw
:
Depends on:
Blocks: 31217 34469
  Show dependency treegraph
 
Reported: 2012-02-15 02:17 UTC by Rob Lanphier
Modified: 2014-11-17 10:35 UTC (History)
7 users (show)

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


Attachments

Description Rob Lanphier 2012-02-15 02:17:22 UTC
Reported https://meta.wikimedia.org/wiki/Talk:Wikimedia_maintenance_notice

"I hit http://test2.wikipedia.org/wiki/Main_Page, then Special:Random, and the page "Wine" came up with a JavaScript error in IE8:
Line: 340
Error: 'mw.user.options' is null or not an object"
--Maiden taiwan 20:04, 14 February 2012 (UTC)

Aaron confirmed this one, but didn't have a good idea on how to fix.  Possibly Roan or Krinkle should look.
Comment 1 Ian Baker 2012-02-15 20:09:03 UTC
I was able to reproduce this an hour ago, but now I can't.  I suppose it's possible someone pushed some code that fixed it.

Regardless, it seemed to depend on my cookies being cleared.  That is, I could only reliably reproduce this bug with a browser that had never heard of test2.wikipedia.org.

The procedure used to be: load Main Page (on test2), clear cookies, type 'wine' into search box, error would occur on the Wine article.  If someone can reliably reproduce this, let me know and I'll continue to debug.
Comment 2 Roan Kattouw 2012-02-15 20:17:43 UTC
(In reply to comment #1)
> I was able to reproduce this an hour ago, but now I can't.  I suppose it's
> possible someone pushed some code that fixed it.
> 
> Regardless, it seemed to depend on my cookies being cleared.  That is, I could
> only reliably reproduce this bug with a browser that had never heard of
> test2.wikipedia.org.
> 
> The procedure used to be: load Main Page (on test2), clear cookies, type 'wine'
> into search box, error would occur on the Wine article.  If someone can
> reliably reproduce this, let me know and I'll continue to debug.
This is probably caused by the 1.18 dependency map being in the browser cache, leading to some sort of Frankenstein page where there's 1.19 JS in the HTML of the page, but the dependency map used to decide if it can be run yet is the old one from 1.18.

In 1.19, we made mw.user.options depend on mw.user . If the 1.19 dependency map is loaded in your browser, the loader will behave correctly and defer execution of mw.user.options until mw.user arrives. But this dependency isn't in the 1.18 map, so if that one is still in your browser cache, the mw.user.options code is run prematurely and crashes.

You should be able to fix this with a hard refresh. It should also just go away after 5 minutes, because the dependency map is stored in the startup module with a cache expiry (both client-side and server-side) of 5 minutes.
Comment 3 Ian Baker 2012-02-15 22:07:15 UTC
That makes sense, but I don't think that's it.  I had cleared the browser's cache (and restarted it) many times.

Aaron gets the bug on his ie8 with a hard refresh of the Wine article every time, I can't seem to get it (even with a hard refresh).  It seems like it might be a timing problem: mediawiki.user is loaded moments before mw.user.options.set() is called.  Perhaps this is happening asynchronously and my VM is slower to process the page vs the time it takes to load the data than his?

Anyway, the fact that he gets the error (only on hard refresh) and I don't while running in mostly identical environments on different machines suggests a race condition.
Comment 4 Ian Baker 2012-02-16 00:10:50 UTC
After some more intensive debugging effort, it sounds like this is indeed an RL issue having to do with cached 1.18 pages loading some 1.19 resources.  Roan has a fix in mind that takes this into account.  Passing the bug on to him...
Comment 5 Mark A. Hershberger 2012-02-17 20:48:22 UTC
frwikisource users said they were seeing this with more than just IE8
Comment 6 Mark A. Hershberger 2012-02-17 21:06:02 UTC
<phe> I can trigget it with this js :
      http://test2.wikipedia.org/wiki/User:Phe/common.js
<phe> both with FF 3.6 and chrome 17.xxx
<phe> mw.user.options exists but is empty
<phe> hexmode, inspecting it with a debugger doesn't show options as null, the
      Map exists but it's not populated with data
<phe> beside that, we have many half random bug report, but I guess most of
      them come from this mw.user.options
<phe> sometimes it's populated, sometimes not ;(
Comment 7 Erik Moeller 2012-02-18 00:36:19 UTC
Simplest reproduce: Type

mw.user.options.get();

in JS console. Resulting object should contain user options. Does not contain them in 1.19.
Comment 8 Erik Moeller 2012-02-18 01:26:22 UTC
Should be fixed as of deployment of r111695.
Comment 9 Erik Moeller 2012-02-18 02:42:50 UTC
This issue still appears inconsistently in spite of the deployment of Roan's fix (r111695). When it does, the "add to / remove from watchlist" feature is broken, as are any gadgets relying on mw.user.options and probably other JS features.

Consistent reproduction is hard (in some user sessions, seemingly impossible, with others, continually appearing), suggesting a bug that's triggered under certain timing conditions.

Escalating priority until we've got a better handle on this.
Comment 10 Erik Moeller 2012-02-18 02:47:05 UTC
The issue can also be more reliably reproduced by using ?debug=true .
Comment 11 Roan Kattouw 2012-02-18 10:41:45 UTC
(In reply to comment #9)
> This issue still appears inconsistently in spite of the deployment of Roan's
> fix (r111695). When it does, the "add to / remove from watchlist" feature is
> broken, as are any gadgets relying on mw.user.options and probably other JS
> features.
I didn't deploy it correctly, I forgot mediawiki.user.js . This should be resolved now that Andrew has re-pushed it.

> Consistent reproduction is hard (in some user sessions, seemingly impossible,
> with others, continually appearing), suggesting a bug that's triggered under
> certain timing conditions.
> 
> Escalating priority until we've got a better handle on this.
I have touched and synced a few files (mediawiki.js , mediawiki.user.js and startup.js) in an effort to fix this, cause I think it's probably just cached old code.
Comment 12 Rob Lanphier 2012-02-18 13:41:57 UTC
Thanks for looking at this Roan.  I was able to reliably repro this problem on wikibooks yesterday shortly after Andrew did the full scap, but not now.  I suspect had we been patient enough, we would have seen this clear up even without the additional file syncs you did today.

As noted in my comment in bug 34469, the weird part was that it did seem to be tied to which user was logged in.  *shrug*
Comment 13 Tim Starling 2012-02-19 02:52:16 UTC
If I upgrade a wiki from 1.18wmf1 to trunk after r111695, then until the startup module expires (5 minutes) I get errors "mw.user is undefined" and "mw.util is undefined", it doesn't get as far as mw.user.options.

I don't think that is the bug we're looking at here. But as an aside, would it be possible to reduce the startup module expiry to a few seconds, or remove the Expires header entirely, prior to deploying a new version?
Comment 14 Roan Kattouw 2012-02-21 21:57:19 UTC
(In reply to comment #13)
> If I upgrade a wiki from 1.18wmf1 to trunk after r111695, then until the
> startup module expires (5 minutes) I get errors "mw.user is undefined" and
> "mw.util is undefined", it doesn't get as far as mw.user.options.
> 
> I don't think that is the bug we're looking at here. But as an aside, would it
> be possible to reduce the startup module expiry to a few seconds, or remove the
> Expires header entirely, prior to deploying a new version?

RobLa and I discussed this and we decided we'll drop down the startup module expiry to 1 minute. We'd have to do this at least 15 minutes prior to deploying 1.19 to a wiki so we know everything is gonna pick up on the changed expiry in time.
Comment 15 Roan Kattouw 2012-02-22 00:19:04 UTC
(In reply to comment #10)
> The issue can also be more reliably reproduced by using ?debug=true .
That's bug 34469, which is now fixed. Can this bug be closed? I think the issue is fixed now, and we're gonna be doing what Tim suggested in comment 13.
Comment 16 Roan Kattouw 2012-02-22 00:21:53 UTC
Per Robla, being bold and closing this bug. If someone's still experiencing this, please reopen.

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


Navigation
Links