ibaker wrote:

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.

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

ibaker wrote:

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.

ibaker wrote:

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

frwikisource users said they were seeing this with more than just IE8

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

Simplest reproduce: Type

mw.user.options.get();

in JS console. Resulting object should contain user options. Does not contain them in 1.19.

Should be fixed as of deployment of r111695.

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.

The issue can also be more reliably reproduced by using ?debug=true .

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

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*

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?

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

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

Per Robla, being bold and closing this bug. If someone's still experiencing this, please reopen.