For the record

Bugzilla 39035 > https://phabricator.wikimedia.org/T41035
Bugzilla 67954 > https://phabricator.wikimedia.org/T69954

But could we create a setting and disable it by default. It will then bring the ability back and also not needing an extension to do it.

See T69954#716675

That is the way it would probly be but need to be moved out of core and into vector so it may look different to that.

We have been trying to reduce on core options for a reason. But ,Krinkle has said all that needs to be said on this topic I think. Rewrite it to perform and then we can talk about adding it back, until that has been done (by a volunteer), it's not too likely that this will return in any form, other than a gadget.

Hi but the option won't be in core it will be in the vector skin that patch is old and is in core. Vector was broken into its own skin after that patch was closed.

And plus what do you mean by rewriting it to perform.

Hi I have created this extensionhttp://www.mediawiki.org/wiki/Extension:CollapsibleVector but it should really be back in vector. But any ways could someone test the speed of it to see if it reduces since there is some changes to it like for example in collapsiblenav.less I have copied changes from the gadget on Wikipedia that removes duplicates in the file including copying from .js file for collapsiblenav that fixes tab index due to recent changes to core of MediaWiki.

@Paladox: the new ext.vector.collapsibleNav.js seems to be essentially a copy of the code which was removed from skins/vector/collapsibleNav.js in
https://gerrit.wikimedia.org/r/#/c/131259/4
So, I don't think the performance issues were fixed.

Please bring back the collapsible sidebars. Removing them was a big mistake. Wikipedia went downhill from there.

[OT] Please see T69954#1006866. In general, "+1"/"me too" comments are not welcome in Phabricator as they don't add additional / technical value to the discussion. Feel free to use tokens in Phabricator to express support for some task.

The option for collapsiblenav should be brought back to vector even if it has performance problems it can also be disabled by default and the site can then choose to turn it on by default and then choose to either allow there users to be able to enable or disable it.

I hope Wiki brings this back before July 31, 2015.

In T69954#1038825, @TheMetalHead1999 wrote:

I hope Wiki brings this back before July 31, 2015.

Why, what happens then?

@TheMetalHead1999: I wrote T69954#1036247. You still added a comment here that does not help anybody else but creates bugmail for anybody else. Please read the Phabricator etiquette and refrain from such actions in Wikimedia Phabricator if you would like to stay active on Wikimedia Phabricator. Thank you.

Change 190717 had a related patch set uploaded (by Paladox):
Add collapsiblenav back

https://gerrit.wikimedia.org/r/190717

Patch-For-Review

Could we add some of this https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCollapsibleVector/84b8fbdbf3a4b7cf0497d13a38945b3dfb3d21b5/CollapsibleVector.hooks.php code so that a user can disable it or enable it on there preference.

@Paladox: Your question was answered already in https://gerrit.wikimedia.org/r/#/c/190717/ - not sure why you bring it up yet again.

Just bring back collapsible.

@SlayerFanatic1999: You were warned in T69954#1039086 already that "me too" comments without any further useful content are not welcome. Please stop that or your Phabricator account might get disabled.

In T69954#1006896, @He7d3r wrote:

@Paladox: the new ext.vector.collapsibleNav.js seems to be essentially a copy of the code which was removed from skins/vector/collapsibleNav.js in commit https://gerrit.wikimedia.org/r/#/c/131259/4
So, I don't think the performance issues were fixed.

Q @He7d3r : Did collapsibleNavs ever "enjoy" having the jquery.throttle-debounce module as a dependency as it relates to performance as collapsibleTabs does currently?

The reason I ask is after adding it as a dependency to both en.Wikisource versions of the gadget "restoring" collapsible sidebar menus/lists as well as the gadget eliminating the sidebar altogether for a horizontal flat-list along the top instead, the previous amount of quite noticeable 'quirky-jerky' element shuffling taking place on the way to final rendering became almost undetectable afterwards. Not sure if that indicates "better performance" or not but things sure do seem to appear "smoother" than without the module.

So if I add dependency on jquery.throttle-debounce in collapsiblenav the performance may increase abit.

In T69954#1228594, @Paladox wrote:

So if I add dependency on jquery.throttle-debounce in collapsibleNav the performance may increase abit.

I can't say that would or would not be the case with any authority - I only asked because I noticed the dependency associated with the collapsibleTabs entry in the php so I played around with associating it in the two local Gadgets I mentioned above with agreeable to very worthwhile results depending.

I can't say the gadget restoring collapsibleNavs' performance improved all that much [if at all] to the naked eye but for the gadget eliminating the sidebar altogether (sidebar-flatlist) for a h-list like series of drop downs across the top it made all the difference.

You should note the latter gadget's menus act more like the .vectorMenu class-based tab(s) do than the menus previously associated with collaspsibleNavs. This is because the menus drop down only upon hover and only stay pinned open while you're on a particular page (i.e. no cookies, no caching). Plus you'll note RL(?) loads collapsibleTabs with some priority (position => top) while collaspibleNavs currently does not (if it ever did).

I just tried jquery.throttle-debounce and seems to improve speed of when it is loaded. My website now loads sometimes instantly. instead of a lag.

I will upload the updated patch and would ask someone to test it for performance to see if jquery.throttle-debounce makes any difference.

Hi this site seems to allow collapsible nav http://lostmediawiki.com/Home But there js isent collapsiblenav. Please see https://github.com/examsmyantra/bswiki/blob/master/resources/js/bswiki.js

We would still need to add caching but would that speed things up.

Maybe instead of certain tabs being closed by default like tools and the other bits and just lanaguge is opened by default maybe we want to keep them all open by default unless the user closed it meaning it is in there cache. It maybe more performant to have them open by default instead of closed.

@Paladox: Please test yourself, document your steps and changes properly, and share them plus your test results. More likely to create progress than adding a bunch of people to the CC list which might not be interested in this task...

Ok sorry. Well I created following what wikieditor and the old vector extension have done by allowing it to be enabled or disabled in preference. I disabled it by default. Since it hasent been improved in a performat way.

In T69954#1488005, @Paladox wrote:

Maybe instead of certain tabs being closed by default like tools and the other bits and just lanaguge is opened by default maybe we want to keep them all open by default unless the user closed it meaning it is in there cache. It maybe more performant to have them open by default instead of closed.

Fwiw... I'm pretty sure the concern over performance in the current approach is multi-faceted.

• First.— The entire premise of scripting in a default capability resulting in a state of either expanded or collapsed per each "menu" found in the sidebar no longer seems optimal per the various comments here and on the related Gerrit to date. You must accept the fact that a static expanded sidebar menu is the Vector default and your notion of adding a non-enabled User: preference option to have some measure of compactness (ie, collapsibility) of those menus is the best possible alternative here. The worst case scenario would be to continue to provide "compactness" per User: selected Gadget.
• Second.— That "best" alternative probably means all menus are collapsed by default. Period. Expansion would take place only upon a mouse-over hover (or cursor tabbed focus) per .css settings much like the current More button's vectorTab menu's behavior is now. In short, any related scripting needed (if any at all) would then be limited to just (re)moving, amending or adding of class names to the key elements found within the sidebar -- no more facilitating the caching of the expanded or collapsed state set in the previous editing/viewing session. Just like the current More vectorTab, you can tick a menu open but that state will not be cached after leaving/closing the page in question.
• Third.— If indeed hover or focus expansion is achieved thru simple .css and/or .js manipulation, the need to cache each those states from one page to the next is no longer needed the way I see it. In other words -- the amount of "mouse" effort expended in order to move-to then tick-on an expanded Sidebar menu's option is negligible from the effort needed in moving-to, hovering-open and ticking on that same menu option.

The above line of thinking, I believe, addresses the current performance concern with regurgitating the prior collapsibleNav.js but other folks better in the know about this stuff should verify that before actually going down that code re-writing path.

@Paladox , (or anyone else interested for that matter),

I'm trying to re-work the collapsible side-bar nav menus with as small a .js footprint as possible but seem to be going in circles.

Please enable <gadget-CollapsedSidePanels> under the Appearance gadget section of test2.wikipedia.org.

The hover over part seems to work fine but I can only "pin" (force) open every other menu on any given page for some reason. Any idea why?

Relevant files (work in progress):

• https://test2.wikipedia.org/wiki/MediaWiki:Gadget-CollapsedSidePanels.js
• https://test2.wikipedia.org/wiki/MediaWiki:Gadget-CollapsedSidePanels.css

@GOll thanks for trying to rework it.

For it to be enabled it needs to be done by someone who has access to that website files Or how ever they enable it.

When you think it's ready to be used in vector I can upload it and get it reviewed or you could upload it not sure what you want to do.. There may be changes such as instead of using css it would use less.

It's seems to allow only one collapsed at a time. Maybe allow it to drop down like it was in collapsible vector and have a transparent background instead of white.

@Paladox

It is still needs work before it can be considered as an alternative. All I was asking is if you could log in to test2.wikipedia.org, enable the gadget, evaluate it and possibly look for whatever is preventing me from ticking open all the menus.

I have admin rights there so I do have access to those files btw. In theory, you could just copy the gadget css & js to your vector.css/js if that makes any difference (& remember gadgets have no effect on user preference pages).

Ok. I will. Sometime today when I have access to a computer. I could see what the problem is and help.

I am on a mobile at moment but to be able to test some fixes I need a computer.

Here some feedback that would help.

It is defiantly faster then collapsiblenav.

In T69954#1872459, @Paladox wrote:

It's seems to allow only one collapsed at a time. Maybe allow it to drop down like it was in collapsible vector and have a transparent background instead of white.

Every menu should be collapsed by default; the problem is I can only pin open every other menu (1st & 3rd or 2nd & 4th - never 1, 2, 3 & 4). I nullified the box-shadow & background so it should be transparent again.

In T69954#1872468, @Paladox wrote:

Here some feedback that would help.

It is defiantly faster then collapsiblenav.

There is really nothing to it but .css. The little bit of scripting (and part of the problem I suspect) is there only because in the original Vector uses H# headings without any "inner wrapper" to play against

Vector gives us...

<h3 id="p-tb-label">Tools</h3>

... when the .text (Tools) should be wrapped in a span or something by [skin] default...

<h3 id="p-tb-label"><span>Tools</span></h3>

... in order to make it "easier" for us to manipulate the headings & menu bodies as is the case here.

@Paladox - I managed to resolve the problem; any and all menu panels can be pinned open now.

I'm sure it can be improved upon regardless.

@GOIII ok good.

Could I ask do you plan on cookies. Like they are always closed even when someone has it open it closes if you refresh would it be possible to remember or was cookies a problem for performance.

Seems to still be an issue with when you have one open and you want to open another it still closes them and leave the one open.

Tested using iPhone 6 Plus iOS 9.2

In T69954#1873208, @Paladox wrote:

Could I ask do you plan on cookies. Like they are always closed even when someone has it open it closes if you refresh would it be possible to remember or was cookies a problem for performance.

Pretty sure that was part of the original performance problem. I don't find recalling what was collapsed and what was not from the previous page very useful personally, but the whole point of the test gadget is to see what the minimum threshold's are for things like that when it comes to the extension(s).

In T69954#1873211, @Paladox wrote:

Seems to still be an issue with when you have one open and you want to open another it still closes them and leave the one open.

Tested using iPhone 6 Plus iOS 9.2

It could have been between edits I was making (last one was a bit before your post here).

Fwiw... I know ticking on the arrow head controls the pinning open & un-pinning better than selecting the heading text does for some reason (plus I didn't think any farther than Vector on a desktop when it comes to this).

Like I said - I know it can be improved upon, (pointing fingers and going in circles wasn't going to lead to a solution imho).

@GOIII the reason you can only have one open at a time is because of this code.

			/**
			 * Dropdown menu accessibility
			 */
			$( this ).on( 'click keypress', function ( event ) {
				if ( event.type == 'click' || event.type == 'keypress' && event.which == 13 ) {
					$( this ).toggleClass( 'bodyForceShow' );

// event.preventDefault();

				}
			} );

try removing it and see if it works.

@Paladox, I disabled the event.preventDefault earlier.

As far as I can tell, the current revision no longer has any base issues; any and/or all menus can be ticked open now.

Ive updated the js a bit.

Please see http://pastebin.com/Q2bY0CpT

I know it looks a lot similar but it does have some changes.

It doesen't use map which should increase performance a but.

It doesn't do $( function ( $ ) { any more. That should also increase performance.

What we should do is collapsiblenav should show before the whole page loads.

In T69954#1874679, @Paladox wrote:

I've updated the .js a bit. Please see http://pastebin.com/Q2bY0CpT

I know it looks a lot similar but it does have some changes.

It doesn't use map which should increase performance a bit.

It doesn't do $( function ( $ ) { any more. That should also increase performance.

Even with those changes, I don't know if it will be viewed any different than the original revision(s) scrapped for performance issues (or whatever) was.

What we should do is collapsiblenav should show before the whole page loads.

Ahhh... I was wondering about that too. Just about everything I've seen modifying the sidebar in some way or degree has an unwelcomed effect of 'flashing' or 'bouncing' on the way to final rendering.

The only thing -- as far as I can tell -- that doesn't do this is the not-so-long-ago addition of the Wikidata item portal link to the standard tools panel.

I suspect the reason that addition is near undetectable is thanks in some part to the hook(?) added in https://gerrit.wikimedia.org/r/132607

If this is the case, why aren't all sidebar-ish modifications done in the same manner? Is this something we can tap into here?

Having ULS-CompactLinks nowadays, does that solve this task?

Not really, although it helps to shorten the potentially longest list in there.

Change 190717 abandoned by Paladox:
Add collapsiblenav back

https://gerrit.wikimedia.org/r/190717

FYI, this is implemented on the Korean Wikipedia with a gadget: https://ko.wikipedia.org/wiki/%EB%AF%B8%EB%94%94%EC%96%B4%EC%9C%84%ED%82%A4:Gadget-CollapsibleSidebar.js
Rather sleek, IMO.