Page MenuHomePhabricator

nav collapse missing in beta
Closed, ResolvedPublic


nav expand/collapse triangles missing

As of June 20 in beta labs the expand/collapse in the left navigation bar often does not appear, nor do search prompts. See screen shots.

I thought that this was related to but now I think I was wrong.

Version: unspecified
Severity: major
See Also:


nav_missing.png (758×513 px, 96 KB)



Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:44 AM
bzimport set Reference to bz49911.

Created attachment 12597
search suggestions missing when typing a term


search_prompt_missing.png (645×1 px, 191 KB)

This is actually two bugs. The search part was broken because the lucene index was dead, I have restarted the service there ( /etc/init.d/lucene-search-2 restart ) and that fixed it up.

About the sidebar expansion, that seems to be a regression somewhere in our code. Either in Vector skin, the Vector extension or something even nastier. On Safari 6.0.5 I do see them though.

The collapsibleTabs javascript has been moved from Vector to MediaWiki core recently.

I found out that Vector in mediawiki/extensions.git has not been updated, the last commit is Date: Fri Mar 29 22:32:03 2013 -0300 . That is a known issue (bug 49906) and might be the cause of the problem.

Vector is properly updating, false alarm.

Rob pointed the copy of a JavaScript collapsibleTabs script from Vector to MediaWiki/core:

MatmaRex highlighted a similar issue happening on the production plwikisource . Sam had to clear /* cache key: plwikisource:resourceloader:filter:minify-js:7:4f71a68f01c144d82798d7c8c82ba20b */

So in core, skins.vector.js had its dependencies changed: Maybe that does not properly invalidate the cache key.

Timo confirmed that if the content does not change, the minify output does not need a new cache key since the minified result will be fine. Dependencies are not involved there.

MatmaRex pointed that the beta error is about jquery.delayedBind not being available, that is a new dependency to the module. Seems like it did not trigger an invalidation of the module :( That would be a bug in the resourceloader.

I have restarted both memcached instance, purged all the load.php URLs but that is still the same issue. I have exactly zero clue now about what might be wrong :(

I could reproduce this in FF18 not being logged in. After logging in this still happened, appending &useskin=vector to the URL does not show the problem, and now reloading (and bypassing cache) does not trigger the issue anymore either.

Going to in Google Chrome 27 or Opera 12.15 for the very first time (not being logged in), I cannot reproduce the issue either anymore.

Not being logged in seems to be important to reproduce this.

The Javascript was not properly purged from the cache. The resource loader material, loaded with load.php, is cached on the text squid, so I pruned the cache using:

ssh deployment-squid.pmtpa.wmflabs
sudo -s
/etc/init.d/squid stop
cd /mnt/squid_cache
rm -r *
squid -z
/etc/init.d/squid start

With a cold cache, the load.php were queried again and loaded with the proper javascript.

The load.php should be loaded from the bits cache, that needs to adjust $wgLoadScript in MediaWiki which is

So the issue is fixed. The root cause are stalled URLs in the squid cache :/

Thanks very much for fixing this!

Is there a risk of this happening in the same way in production as well as it did in beta labs? I think the answer is "yes" but I am not sure.

(In reply to comment #14)

Thanks very much for fixing this!

Is there a risk of this happening in the same way in production as well as it
did in beta labs? I think the answer is "yes" but I am not sure.

Yeah we talked about it with Sam. In production, caches are properly cleaned while deploying a new branch.

The issue happened on the production plwikisource iirc, some cache hasn't been properly purged on that wiki. Sam fixed it on sight.