chosen.js is the cause of the low backend performance

[Fedir]

I noticed that the admin side works very slow in my browser (I use Opera)

it clearly visible /administrator/index.php?option=com_config

issue  [#29641] Very slow of JavaScript performance in Isis in Opera

after small investigation I found that the cause of so slow work it is Chosen.js

if run Profiling for  /administrator/index.php?option=com_config page in Chrome can see that chosen take a lot time for execution ...

and if disable chosen.js then all works a lot faster.

Results with chosen.js enabled:

chosen.js disabled:

 

so I think it not only for Opera and nothing for isis template, 

it can be for any other user with slow PC and mobile ;)

[piotr_cz]

I have similar problem with chosen.js.
Rendering config or complex edit pages where chosen is used becomes
super laggy on mobile devices (~1Mhz).

I really like how native <select /> element renders and OS uses native
UI
(https://issues.jboss.org/secure/attachment/12348188/android-select-
correct.png)


Chosen has one advantage though: It allows interactive searching
trough the list.

I'd much more prefer using native <select /> + Datalist which has same
functionality as chosen (https://developer.mozilla.org/en-US/docs/Web/
HTML/Element/datalist).

A downside is a bit lacking support for <datalist /> element:
http://caniuse.com/datalist but still I think there are more pros.

On Jun 2, 2:35 pm, Fedir <fed...@gmail.com> wrote:
> I noticed that the admin side works very slow in my browser (I use Opera)
> it clearly visible /administrator/index.php?option=com_config

> issue  [#29641] Very slow of JavaScript performance in Isis in Opera<http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...>

>
> after small investigation I found that the cause of so slow work it is
> Chosen.js
> if run Profiling for  /administrator/index.php?option=com_config page in
> Chrome can see that chosen take a lot time for execution ...
> and if disable chosen.js then all works a lot faster.
>
> Results with chosen.js enabled:
>

> <https://lh5.googleusercontent.com/-mcW6NSDiseo/Uas522l6q-I/AAAAAAAAAI...>
>
> chosen.js disabled:
>
> <https://lh3.googleusercontent.com/-M8R4k0bvYks/Uas5y-dkKXI/AAAAAAAAAI...>

[Seth Warburton]

Thanks for bringing this up Fedir, and for testing it.

There's a number of usability issues also with Chosen, and there was a lot of discussion about these at JAB13, so I think we should try and get some consensus on next steps;

Do we drop chosen.js and revert to native select handling with Bootstrap styling, or do we try and fix the issues in chosen.js? I do not have the skillset to be any help with the second option!

Best,

Seth

[Fedir]

it is good question, I really have no idea :)

I did not found any alternative for chosen.js

can add some option in the template(or somewhere) for disable it, so user can disable it if have performance problem - but songs very tricky and it is not real solution ;)

about try to optimise chosen.js - maybe it only one thing that we can do, but I have no such experience so cannot tell any. On their issues tracker a couple performance issues already closed but but...

Вівторок, 4 червня 2013 р. 11:25:22 UTC+3 користувач Seth Warburton написав:

[Viper]

"I did not found any alternative for chosen.js" At least 2 alternatives exists. And Select2 is really good.

[Fedir]

thank!, just found Select 2 :) need to test

which another alternative?

Вівторок, 4 червня 2013 р. 12:44:04 UTC+3 користувач Viper написав:

[Viper]

In the evening, I can say a couple of alternatives.

PS! Now I use Select2 for regular list and as ajax suggested list of items and it is work good.

[Viper]

And another script http://nicolasbize.github.io/magicsuggest/ Looks similar to chosen and select2.

[Fedir]

MagicSuggest - not really same, it do not use auto wrapping for a select tag

but Select2 looks better than Chosen...

my testing result on the Config page  /administrator/index.php?option=com_config

with chosen.js:

with select2.js

without any script for the select tag:

As can see, Select2 works faster than Chosen not less than 1.6 times

So Chosen was a bad choice :-p

also Select2 not so fast as the clean select.

So maybe we really need to use just a clean select with bootstrap styling by default, and make some plugin or the template option, so user can enable Select2 or Chosen for all <select> tags on the page

Середа, 5 червня 2013 р. 04:58:13 UTC+3 користувач Viper написав:

[Matt Thomas]

On Wed, Jun 5, 2013 at 1:03 PM, Fedir <fedikw@gmail.com> wrote:

So maybe we really need to use just a clean select with bootstrap styling by default, and make some plugin or the template option, so user can enable Select2 or Chosen for all <select> tags on the page

It's great to have data-driven decisions like this. I like the idea of enabling Select2 by plugin.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Viper]

I agree too. It can be done in the form of a plugin, as well as the chosen. Just extend the settings via JRegistry object.

[piotr_cz]

I like most the idea of native <select /> + <datalist />.

I think the way to go is using JLayout, see Michael's answer at SO:
Extend, modify, or override Joomla's bootstrap.php?
http://stackoverflow.com/questions/16904713/extend-modify-or-override-joomlas-bootstrap-php/16908624#16908624

On Jun 5, 7:12 pm, Matt Thomas <m...@betweenbrain.com> wrote:

> On Wed, Jun 5, 2013 at 1:03 PM, Fedir <fed...@gmail.com> wrote:
> > So maybe we really need to use just a clean select with bootstrap styling
> > by default, and make some plugin or the template option, so user can enable
> > Select2 or Chosen for all <select> tags on the page
>
> It's great to have data-driven decisions like this. I like the idea of
> enabling Select2 by plugin.
>
> Best,
>
> Matt Thomas

> Founder betweenbrain <http://betweenbrain.com/>™

> Lead Developer Construct Template Development

> Framework<http://construct-framework.com/>

[Bakual]

Just a note: if you're going to change the behaviour of chosen now, you're creating backward compatibility issues. As an example I'm using a Javascript to update the chosen select after an item was added. This will break if it changeS to select2 or whatever. So don't change it in the 3.x series. You can change it in 4.0 if you really must.

[Viper]

4.0? This is a long time. Maybe in 3.5?
In any case, no one talks about a complete change now. Only as an alternative.

[Bakual]

Backward compatibility breaks are only allowed to go into 4.0. 3.5 has to be compatible with 3.0. As long as it may be, it's a decision made by the PLT (I think) and it's a good one.

Even an alternative would break the DOM and thus Javascript code interacting with it. You can't expect 3rd party developers to write code for three variants of select boxes.

Make a decision for the x.0 release and stick with it for the next two years till the next x.0 release comes. It's not like something is really broken and needs to be fixed. However your "fix" will certainly break things.

[piotr_cz]

I agree, this could break things.
But I'd add note about depreciation.

Bakumal: I think you should manipulate the genuine <select /> element
and it's options and trigger manually the onChange event (if it's
possible), so chosen updates itself. It's a decorator after all.

I've commited a patch for media manager when it wasn't updating
directory tree, maybe that helps:
https://github.com/joomla/joomla-cms/pull/423

[Bakual]

That's exactly what I do. I update the origin select and initiate the update function for the chosen element:

if(document.getElementById("jform_" + element + "_chzn")){

jQuery("#jform_" + element).trigger("liszt:updated");

}

However this will not work with select2 or others as the generated "id" and the update function will have a different name.

[piotr_cz]

That's right.
In case there should be a proxy method attached, like in Editor
plugins (jInsertEditorText), but this would be harder for complex
operations like ajax-populated list and so on.


// Chosen
function jUpdateSelect(elementId) {
jQuery(elementId).trigger("liszt:updated");
}

// Select2
function jUpdateSelect(elementId) {
jQuery(elementId).trigger("change");
}

// Native Select
function jUpdateSelect(elementId) {
document.getElementById(elementId).onchange();

[Achal Aggarwal]

According to me using native <select/> for mobile platform is best idea. 

Because of chosen the combo box field doesn't work as it should. http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=30728

I found a way to make combo box work by subtracting chosen from it and using the twitter/bootstrap code. I got upto this point http://postimg.org/gallery/w3kb0y2/64fe43ad/ .

So in all I think we can use select2 for non mobile platform  on <select/> and something like my design for combobox and <select/> for mobile platform.

I am working on adding html5 into form fields this summer as a GSOCer and I am considering adding <datalist>. As plot_cz mentioned it is not yet supported by all browser and old browser versions, so we can add fallback code to mimic the behavior.

[Matt Thomas]

One thing that I feel that we really need to avoid is getting into sniffing user agents and implementing device specific solutions. In my opinion, if it doesn't work on mobile, we should ask ourselves if it is really necessary. I'd rather see native select everywhere if select2 doesn't work on mobile.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Fedir]

people, I think you're lost the topic, no? :)

I like the idea of enabling Select2 by plugin.

it was just a first thought in my head, but more simple will be a template option, 

we just remove JHtml::_('formbehavior.chosen', 'select'); from all views and add in the template:

if(use the styled select){

 JHtml::_('formbehavior.select2', 'select'); or JHtml::_('formbehavior.chosen', 'select');

 or just add <scrip src="">

}

Четвер, 6 червня 2013 р. 18:46:28 UTC+3 користувач Matt Thomas написав:

[Bakual]

I vote against an additional formbehaviour for the reasons I already posted. It creates issues with extensions that manipulate select boxes. We already need to take care of regular boxes and chosen boxes since you never know what a template will do. We sure don't need a third variant which we need to take care of.

It's quite simple:

 

Pro:

• Some (small? big?) improvements in loading time, especially in backend with many select boxes.

Against:

• Compatibility issues with Javascript code and CSS rules (different ids and classes).

While the improvement is situational and only really in a few places notable, I think the compatibility issues will impact a lot of the designers and developers.

[Fedir]

hm, but what compatibility issues can be in this case?

I did not told to remove formbehaviour class from CMS, so who use it in own extension still can use...

ah, but yes if some extension already use formbehaviour.chosen, and we try apply Select2 for the same <select> - can be funny result hahahah

then just do not use any <select> script by default :-p

Четвер, 6 червня 2013 р. 21:18:42 UTC+3 користувач Bakual написав:

[Anibal]

Off topic, but cool anyway. From today hackernews:

A Guide to the New HTML5 Form Input Types

http://sixrevisions.com/html5/new-html5-form-input-types/

http://html5test.com/

Page to check the new Input types, it mostly works with Chrome

http://cdn.sixrevisions.com/demos/0345-new_html5_form_input_types/new-html5-form-input-types.html

Regards,

Anibal

[Viper]

Isn't work in FF and IE

[Fedir]

ok, so we cannot simple replace Chosen.js to something else..

there is the patch that allow enable/disable it in the Isis template https://github.com/joomla/joomla-cms/pull/1302

Пʼятниця, 7 червня 2013 р. 17:21:33 UTC+3 користувач Viper написав:

[piotr_cz]

+1
IMO chosen.js is a decorator after this patch it will be where it's
place is - in template

On Jun 19, 1:21 pm, Fedir <fed...@gmail.com> wrote:
> ok, so we cannot simple replace Chosen.js to something else..

> there is the patch that allow enable/disable it in the Isis templatehttps://github.com/joomla/joomla-cms/pull/1302

>
> Пʼятниця, 7 червня 2013 р. 17:21:33 UTC+3 користувач Viper написав:
>
>
>
>
>
>
>
>
>
> > Isn't work in FF and IE
>
> > On Friday, June 7, 2013 5:05:52 PM UTC+3, Anibal wrote:
>
> >> Off topic, but cool anyway. From today hackernews:
>
> >> A Guide to the New HTML5 Form Input Types<http://sixrevisions.com/html5/new-html5-form-input-types/>

> >>http://sixrevisions.com/html5/new-html5-form-input-types/
>
> >>http://html5test.com/
>
> >> *Page to check the new Input types, it mostly works with Chrome*
>
> >>http://cdn.sixrevisions.com/demos/0345-new_html5_form_input_types/new...
>
> >> Regards,
> >> Anibal

[Beat]

As just commented on github pull request:

This change imposes chosen to all extensions as it makes it on by default for all core components and extensions.

This will most probably break extensions not using chosen.js but their own decorators/features enhancers.

The idea to move that behavior to template is nice, but it should not control directly the addition of chosen.js . Instead, it could control if each of the components does add it or not when the behavior is requested. So the behavior instruction should not be removed from core components, but the effect of it could be controlled by the template.

Best Regards,

Beat

http://www.joomlapolis.com/

[Fedir]

...but the effect of it could be controlled by the template.

how?

I know that I can only disable/enable in way that I did there :)

Четвер, 20 червня 2013 р. 09:31:06 UTC+3 користувач Beat написав:

[Matt Thomas]

I was wondering if anyone has further thoughts on this. Personally, I'd like to see Chosen removed. One major issue that I've stumbled upon is that it breaks native browser multi-select (shift + click) capability. This is a huge UX issue if you ask me. 

If we can't remove it, would it be possible to add an icon next to select to toggle Chosen on/off?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.

[Adam Rifat]

I agree, I don't think it necessary and often I see a FOUC. Also, the search thing is annoying on mobile as the keyboard always pops up when I just want to select something from the list.

I would say remove it as well, if that's possible.

[Daniele Rosario]

IMHO, lot of end users like it a lot. It makes it easier to filter thanks to the search inline.

I'm against removing it, also for BC reasons (lot of extensions could potentially rely on it being in the core).

I would either use select2.js or give in the config the option to disable it, leaving it on by default.

Daniele Rosario

[Youjoomla.com]

Yes please remove it. It is nothing but trouble.  It brakes native selects, does not react with onchange functions ,must always look for 

some funny workarounds to get the js actions and is slow. 

On Wed, Sep 18, 2013 at 10:18 AM, Adam Rifat <ad...@littledonkey.net> wrote:

--

Best Regards
Dan Casky
Youjoomla Customer Service
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Bakual]

My biggest concern isn't really chosen itself, but the way we use call it. The JHtml function would by default only apply chosen to selects with the class "advancedSelect". But we almost always use it in the non default way and lazy apply it to each select.

If done right, an extension could specify selects which made sense to have a chosen field and the template could the load chosen or not.

[Adam Rifat]

Yes, that would make sense.

Would we need a parameter on the template and extensions though? Just on the template would be on or off for all extensions...or do you mean just to control it via a css class?

[Bakual]

Would we need a parameter on the template and extensions though? Just on the template would be on or off for all extensions...or do you mean just to control it via a css class?

 

If we want it on template level, we would have to

• remove the JHtml::_('formbehavior.chosen', 'select'); calls from all layouts
• add the class "advancedSelect" to each select we think it would be wise to have an advanced select field. As an example it doesn't make much sense on a select which usually has only very few options (like state or access level).
• Add JHtml::_('formbehavior.chosen'); to the template. Or even better add an option where you can select if chosen should be loaded, and if yes only for the "advancedSelect" or for all selects.

The drawback here is that the chosen Javascript gets loaded always, if it's needed or not on the particular page. Usually it's only needed on listing pages with filters and on forms.

 

However the call should be JHtml::_('formbehavior.chosen'); anyway, and not be applied to each select. But this is not an easy change as a lot of files need to be touched and tested. I did a PR once for the menu item view (see https://github.com/joomla/joomla-cms/pull/1620) and used a little trick with the list field so I didn't had to add the "advancedSelect" class to each field. It still needs changes in 4 files only for this single view. Also to note: There is not a single test yet on the tracker, which is especially noteworthy as a solution was requested by someone in the JBS group.

 

Imho the best thing would be if the JHtml classes could be overriden by the templates, but I don't think that is possible yet?

[piotr_cz]

It the decision was just up to me, I'd go with native <input /> + <datalist />

The result is very similar: https://developer.mozilla.org/samples/html/datalist.html (Just have to double click on element), responsive and works on mobile.

Of course this would break b/c where javascript manipulation is used.

I hope this (and other HTML5 features) could be used in next major version of CMS.

[Matt Thomas]

I was thinking about this last night and I concluded that a reasonable solution would be for a way to designate elements that are not corrupted by chosen. That is, if I have a select element in my extension, I should be able to opt-out.

<rant>
I personally find chosen to be horrible, one of the worst UX decisions ever made, and would rather rip it out of the CMS.
</rant>

But, I recognize that some people like it and that there may be b/c issues with it's removal.

For me, chosen breaks necessary functionality in one of my extensions and prevents me from supporting Joomla 3.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

--

[Matt Thomas]

Isn't now the time to make these changes? Isn't that idea of STS and LTS?

@piotr_cz one of the biggest issues for me with chosen is that you can't select multiple options at once (shift + click). Does <input /> + <datalist /> support at?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

[Matt Thomas]

Another idea, and I don't know if it's even possible, would be to add a toggle next to select elements to allow chosen (or any other script) to be disabled for that element. Any idea if that is even possible?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Hannes Papenberg]

Yes, pleaase give me yet more options. I wanna feel like this http://www.youtube.com/watch?v=xcDD22R6Lck

(P.S.: I don't like chosen either)

[Michael Babker]

I don't think it's possible to just on the fly enable/disable Chosen.  With that said, unless someone screwed that up again, it is opt in at the extension level.  If you want it, add JHtml::_('formbehavior.chosen', 'select'); (where the second param is the selector to apply Chosen to).  If not, leave it out.

[Matt Thomas]

Michael,

How can that be done, let's say, for a module that has a select element? Doesn't com_modules determine that for the module?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Matt Thomas]

Hannes,

I agree. My idea was an attempt to maintain some sort of backwards compatibility.

In that case, I propose we remove it. I'm seeing more consensus about people not liking it than anything else.

 It's not progressively enhancing anything but changing the intended behavior of a widely-used HTML element, which is a major issue in my book.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Michael Babker]

Someone screwed it up and made the form behavior apply to all <select> elements, not an element with a specific class (like it was originally intended).  If you do JHtml::_('formbehavior.chosen', 'select'); then EVERY <select> element will get styled.  Reviewing the method declaration, it was intended to apply to a unique class by default.

[Bakual]

It's not done by com_modules as far as I know. It's done by the component output (usually in the layout). This also means that depending on the component, your module may have chosen applied or not.

 

Like Michael said, someone screwed that up by lazy using "select" as the selector instead using the default behavior ".advancedSelect".

[Matt Thomas]

If someone can help provide a few more details (i.e. I'm not sure how to fix it yet), let's get this onto a tracker item and I can pick away at it. Sounds like a straightforward fix.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Michael Babker]

Change the method call to JHtml::_('formbehavior.chosen'); any place it's called with the 'select' param added and make sure all core <select> elements have the advancedSelect class.  We can discuss ripping out Chosen for 4.0 (and could even theoretically start working on it just after 3.2 with the new git branching setup we'll be using) at a later time.  This will make sure all core elements are styled with Chosen as intended and developers can make sure they aren't getting styling forced on them.  I'm now waiting for one of the design people to come in and complain about how that will work with mixed Chosen and non-Chosen <select> elements on the same page.

[Bakual]

Basically you have to hit each layoutfile and change the call JHtml::_('formbehavior.chosen', 'select'); to JHtml::_('formbehavior.chosen');. After that is done, chosen will only be applied to select elements with the class "advanceSelect". Now to get the same behavior as before you need to add this class to each select in core. That means you are going to edit each xml form, the filter layouts and a lot more hidden somewhere in the code.

I did a PullRequest to do exactly that for the menu item view and you could use that as a general guide: https://github.com/joomla/joomla-cms/pull/1620

In my PR I changed the list formfield the way that it will default to the advancedSelect class if none is given. This way I didn't have to manually add the class to each XML file.

I also adjusted the formfield to remove that class again in case there is a huge amount of options because chosen has issues then. That was basically the reason for the PR in the first place :-)

As you can see it still took changes in 4 files besides the formfield and the test file to do it properly. Only for a single view.

[piotr_cz]

Unfortunately, no, you cannot choose multiple options :(

It's still an input (text) element made for one and any value so more like combo-box than select

Some articles if anyone is interested:

http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/introducing-the-html5-datalist-element/

http://www.raymondcamden.com/index.cfm/2012/6/14/Example-of-a-dynamic-HTML5-datalist-control

[Fedir]

small talk was also there https://github.com/joomla/joomla-cms/pull/1302

alternative for overwrite the behaviors:

allow the behaviors to interact with template through the template parameters, like: the behavior check if there exist the specific template parameter then it take it, other way continue with default...

Четвер, 19 вересня 2013 р. 11:36:44 UTC+3 користувач piotr_cz написав:

[Fedir]

new pull https://github.com/joomla/joomla-cms/pull/2018

Четвер, 19 вересня 2013 р. 11:57:06 UTC+3 користувач Fedir написав:

[Bakual]

Just browsed the chosen project page a bit and saw that they released a much improved version v0.12 three months ago. According to the release notes it should take care of the issues with big select lists.

Also they released a version v1.0 two months ago. Unfortunately they did a name change for the CSS prefix from chzn- to chosen- and JS events from liszt to chosen

So 1.0 is a B/C break and would need updates in CSS files and custom JS code. But updating to the latest pre 1.0 release (which is v0.14.0) would be possible.

 

I'd say this would be a good move. Thoughts?

Am Sonntag, 2. Juni 2013 14:35:19 UTC+2 schrieb Fedir:

I noticed that the admin side works very slow in my browser (I use Opera)

it clearly visible /administrator/index.php?option=com_config

issue  [#29641] Very slow of JavaScript performance in Isis in Opera

after small investigation I found that the cause of so slow work it is Chosen.js

if run Profiling for  /administrator/index.php?option=com_config page in Chrome can see that chosen take a lot time for execution ...

and if disable chosen.js then all works a lot faster.

Results with chosen.js enabled:

chosen.js disabled:

 

so I think it not only for Opera and nothing for isis template, 

it can be for any other user with slow PC and mobile ;)

[Michael Babker]

Absolutely update.  We've already updated the jQuery libraries for 3.2, and Bootstrap a few months ago.  Let's get this one in.

[Bakual]

Turns out it isn't that easy as it looked.

 

First we did some changes in chosen for Joomla. Mainly for RTL support and some to support Joomla language strings. The RTL ones maybe are no longer needed as there are some fixes done on their side as well.

 

The other issue is that they have a known bug in chosen which sets the width of an initially hidden select to 0. That means chosen elements on tabbed pages (like configuration) are going to be messed up. There are fixes proposed on their site like https://github.com/harvesthq/chosen/pull/1439.

 

So we need a JavaScript savvy person who could apply these fixes first.

Unfortunately I lack those skills myself.