Chosen: if select is initially hidden, doesn't work

Yes you should patch the coffee script. Also I'm for the ability to setup hidden elements.

+1 ran into this issue today

+1 as did I

As a workaround, you can set the width of the created div with an !important flag:

#my_select_chzn {
  width: 100% !important;
}

Actually, this will get you closer to where you need to be. The widths aren't perfect, but everything will be visible.

#my_select_chzn {
  /* This is the only width setting you'll need to change. */
  width: 100% !important;
}
#my_select_chzn .chzn-drop {
  width: 100% !important;
}
#my_select_chzn .chzn-drop .chzn-search {
  width: 99% !important;
}
#web_template_exploit_name_chzn .chzn-drop .chzn-search input {
  width: 98% !important;
}

An earlier version of Chosen actually tested to see if the form field width was set via css. If so, it didn't use the width calculation. I think I prefer this method of fix to adding 30 lines of code for testing hidden elements. Would something like this work for you?

Set the width:

  <select style="width:350px;" class="chzn-select">

JS tests for set width first:

  @f_width = if @form_field_jq.css('width')? then parseInt(@form_field_jq.css('width'),10) else @form_field_jq.width()

@pfiller there's a small bug in your code. If the inline style has a width in any unit other than pixels (like em) the code will interprete it as pixels. see line 56 in chosen.jquery.coffee

I think people will continuously complain about it and you'll ultimately need to add that 30 lines of code.

Hi @pfiller, that doesn't work. Both width() and css("width") return 0 for hidden elements. I'm using the getHiddenDimensions technique and it's working well.

btw, you need to use it both for f_width and also in get_side_border_padding

+1 for this.

A lot of the logic on the site I'm integrating Chosen on relies on some selects being hidden on first load, so we get all kinds of problems with this.

+1 as well. Visibility checks should be built in.

:+1: :+1: :+1:

What about the solution where the dropdown width isn't set permanently on first startup, and is just resized to the width of the textbox when it opens? That way you don't have to ever touch the width of the input, just assume it's set with css and read it every time you open the dropdown.

+1 for this. I've decided to turn Chosen into a fieldtype for the ExpressionEngine CMS, but the publish layouts of EE allows for fields to be hidden on page load.

I'm not sure if this is related, but in the case of EE it would be best if the width were fluid, or simply was always 100% of its containing element...

http://www.alistapart.com/articles/now-you-see-me/

Bumped into this one... it's still happening in the latest version

+1
This bug is blocking usage of the Chosen plugin for internal apps at Netflix

:+1: on this issue, ran into this problem today

You can hide your content with: position: absolute; left: -999em;
This way, screen readers and Google can "read" them too, and your Chosen dropdown WILL be visible when showing it again.

My pull request fixes this issue, but like my other one and many of the ones for chosen they are being ignored. This project has too many contributors with too small of a code base.

DelvarWorld, thanks for your patch. This has been bugging me, and I was just about to implement a similar solution and thought I'd double check to see if anyone had already done so.

I'll be deploying this to production code shortly after I test it.

@DelvarWorld what pull request are you referring to? I see one open pull request from you and it does not address this issue.

@pfiller The one listed above in this thread, https://github.com/DelvarWorld/chosen-hacks/commit/e9501568acae1988ba51b5a29269023d3400db42

More important than using the css is using the "current" width of the element when rendering the results, instead of using an incorrectly cached width from the construction of Chosen.

There have been many changes, and I'm not quite sure of the best way to merge them myself. Will you have a merged version shortly?

@bewest my pull request does that, every time the dropdown is shown it matches the width of the element

@delvarworld I know, just making sure the right distinction is made.

Can you try bringing your auto-width branch up to date with HEAD? I tried merging from a similar checkout around the end of August, but the input box is now the wrong width (it is too wide, overflowing the width of chosen's container).

I'm taking a look, but there's also been some re-organization... the constructor has been removed in favor of a setup and finish_setup methods. I'm also not familiar with coffeescript so your progress in merging might be faster than mine and submitting a pull request my help, since there seems to be a lot of interest in this issue.

Actually, my branch has diverged past just that change, and eventually I gave up working on the prototype version. My fault, and I think at this point it's not mergeable.

@DevarWorld Yeah, it needs to be reworked a bit so that some bits go in the Abstract implementation. This should make it easier to maintain the differences between prototype and jquery.

Would you be willing to give it another go?

A polite bump...is anyone working on this?

Chosen doesn't work for me since it's hiding my select, and then unable to calculate the width. I have to hack it by arbitrarily setting a width on each of the chzn components in CSS. This does not seem like how this is suppose to work, and it really doesn't even look normal like it does on the websites I've seen it on.

I also ran into this problem. As it turns out, the method that chosen uses to get the width of an element is broken in earlier version of jquery (I'm sorry, but I don't have the exact version numbers). As noted above, the bug was when an element is not visible the width would return 0. This bug is very well documented, and there are many ways around it.

The solution for us was to simply upgrade to the newest version of Jquery. Yes, we had to do some patching and testing of old code that used jquery, but in the long run it fixes a lot of issues and reduces the need for little hacks throughout your js/css.

I am installing the latest jquery that is packaged in the rails jquery gem and jquery-ujs. I suppose this is still too old?

Yes, an actual version number would be nice to have. I can confirm 1.6.2 is
too old as well.

On Wed, Nov 16, 2011 at 11:23, Kevin Elliott <
[email protected]

wrote:

I am installing the latest jquery that is packaged in the rails jquery gem
and jquery-ujs. I suppose this is still too old?

@RoyJacobs newest currently is 1.7 as it has been released.

@RoyJacobs I can confirm that we are using 1.6.4 without issue.

This is strange. Yeah the jquery-rails gem is using jQuery 1.7. But it's still not working for me.

You can see that it is not rendering with a width. Inspection shows all the calculated widths to be 0px. This occurs even if I set .chzn-select to have a width in CSS or directly in the style parameter of the select tag.

https://skitch.com/kevinelliott/gjufg/winetribe
https://skitch.com/kevinelliott/gjufp/winetribe

Certainly annoying. The select seems to be getting display:none (I assume from the chosen javascript), and I can only imagine that it's then not able to calculate the width properly.

Thoughts?

I really wish I could get this to work in ANY circumstance (even if I have to force it). Nothing seems to work. I will be forced to abandon this entirely (and I certainly won't want to deal with this broken stuff again).

Make sure your select has some CSS applied, stylesheet or inline. If you do it with stylesheet it means you have to inject the element into the DOM before you call chosen().

But I agree that getting this right is very difficult. I would really like to be able to apply a width to the chosen select via CSS. One class, one width, px or %.
My CSS would then look like

.example select, .example .chzn-smth {
width: 50%;
}

And this would apply the width correctly no matter how or when or where you call chosen.

I have tried it inline and via stylesheet with no change in behavior though.

Pretty substantial problem for lightboxes and accordions. Anybody working on a patch?

I don't think anyone is! I'm shocked because I don't understand how this is usable to anyone. I'm not even artificially hiding my content. The chosen() call seems to be doing it. So strange.

@kevinelliott I think those that were having this issue have either moved on, or found a fix. As I said, in our case it was simply a matter of upgrading jquery. Keep in mind also that we have styled our element to have a width of 224px and we set 'display: none;' directly on the element and not in a style sheet.

I hope this is helpful for you and you are able to get it working.

RichardBlair on 6 Dec 2011

Thanks Richard. I upgraded my jQuery and that did not help. The strange thing is that I am not hiding my select element. Chosen is hiding it. So I'm not even sure what is happening.

kevinelliott on 6 Dec 2011

@kevinelliott Np. I am curious, are you setting the width of your

element at all? If so are you using percentage or pixels?

I am. I'm setting it with pixels. I have tried setting it on the element directly with the style attribute, and I have also tried it in CSS.

@kevinelliott To be honest I'm at a bit of a loss. The only remaining suggestions I have is 1) wrap the select element in a element (we do this, and our works fine), and 2) stepping through the chosen library to find out at what point chosen is hiding your select element... I also had to do this when we ran into our issues.

Sorry I couldnt be more help.

I have a case, that even with a fixed width in select the chosen create a width: 0px.
I can't figured why, doesn't work on this situation, and work in others...

@tiagobrito: I have the exact same problem and have never been able to solve it, fixed or not.

@RichardBlair Thanks for your help. If you think of anything else, let us know :)

+
same problem, please, fix it

@tiagobrito, @dhampik can you put together a small gist that demonstrates the problem?

@bewest I already figured out! It append when I use jquery 1.4.x in my projects.
Next monday I will tell you the correct version of jquery that cause me the width: 0px

@bewest I also confirm,
that old versions of jquery (I suppose, prior 1.6.4)
mess up the layout of select, which is initially hidden
Here are 2 fiddles:
messed layout (old jquery): http://jsfiddle.net/dhampik/2E9fG/
correct layout (new jquery): http://jsfiddle.net/dhampik/Rs9Z3/

Thanks god, jquery's version was updated with new upcoming version of Yii framework )

I have this issue when I try to integrate Chosen into Trac. The initial select-boxes in the properties form of a ticket have a width 0. The properties are hidden by default and can be expanded by clicking on a link. jQuery v1.7.1

Update: I worked around the issue since at least the CSS trick mentioned in the foliotek blog post didn't work with jQuery 1.7.1. I did not try the JS approach yet.

My workaround (for Trac):

$("#modify").parent().removeClass('collapsed');
$("#field-test").chosen();
$("#modify").parent().toggleClass('collapsed');

for those using jQuery <= 1.7.1

I worked arround this issue using jQuery Actual
Changed chosen.jquery.js#301 from
this.f_width = this.form_field_jq.outerWidth();
to
this.f_width = this.form_field_jq.actual( 'outerWidth' );

//edit thx @koenpunt for the 1.7.2 comment

@midday According to the README of jquery.actual this is only needed for jQuery versions prior to 1.7.2

Older version of jQuery(>=1.7.1) has trouble finding the width/height of invisible DOM elements.

@midday thank you for finding that, after implementing the actual plugin it fixed the issue with chosen

I'm still having this problem, any ideas how to fix it?

Same here still an issue - I can't believe this has been going on for years...

I've also run into this problem. Would love some help.

This CSS trick seems to work:

/* Fix 100% width */
.chzn-container, .chzn-drop, .chzn-drop .chzn-search, .chzn-drop .chzn-search input {
  width: 100% !important;
  -webkit-box-sizing: border-box;
     -moz-box-sizing: border-box;
          box-sizing: border-box;
}

/* Override width */
.chzn-container { width:250px !important; }

@gyopiazza. It did fix the problem for me. Thank you.

FWIW I've found that setting a min-width (even without !important) on .chzn-container, .chzn-drop, and .chzn-search input works for initially-hidden selects as well.

My workaround

css:

.chzn-container, .chzn-drop {
    width: 100% !important;
}

html:

instead of setting width in the select element I choose to add a wrapper div to the orginal select element and set the wrapper's width.

Chosen now offers an option to initialize with a set width which overrides any attempt at calculation. This is probably a satisfying workaround for most use cases where the select is hidden at the initialization point:

$("select").chosen({ width: '50%' });
$("select").chosen({ width: '200px' });
$("select").chosen({ width: '15em' });

I think that this workaround is probably as we're going to do for fixing this bug. I really want to avoid including code that moves the select off the screen to measure as it would add more complexity.

Does anyone have a problem with closing this bug based on this solution?

I was using version 0.9.8 and my hidden selects was working normal. Today I've updated do 0.9.14 and they stopped working. I was using the minnified version. When I change to the normal version everything works fine again (chosen.jquery.js 0.9.14). Is it normal? It's an error in the minnifying proccess?

Neither hidden is not working for me on jQuery min or full size 0.9.14.

The new option 'width' worked for me. Work, at least, for new chosen inputs that was previously hidden.

@trisweb This is an open source project and hostility is not welcome here. There are a lot of people here who have given a lot of time and energy to make Chosen what it is today. Please try to contribute to the improvement of the project or refrain from commenting. Thanks.

@kenearley I'm fully aware of open source etiquette and should have designed my comment to be more effective. Sorry about that.

That said, I really think sometimes you need someone to yell over all the noise.

I propose that a zero-value for the width of any chosen element isn't logical, and some reliable method should be devised by which the correct width is determined. Failing that, a reasonable default should be used, and for many reasons that should be self-evident, zero is not a reasonable default.

It may be a hard problem, which is why this bug has been around for so long, but I'm confident there is some solution. Personally I don't think the new 'width' attribute solves the problem, since this still relies on configuration more than convention, and thus might result in the non-functioning zero-width chosen in the default case.

That said, I really think sometimes you need someone to yell over all the noise.

No. There is no need to 'yell over the noise.' If someone feels strongly enough about how the code should be written, they can offer a pull request or fork the repo and change as desired.

That said, I appreciate your follow up and agree that the current solution is not ideal. As we move forward we will be looking into better solutions and would greatly appreciate pull requests by anyone who has an interest in getting this changed.

@kenearley I politely disagree with your opinions on rhetoric—but of course code speaks louder than words always. This is an irritating problem for us at the moment so a pull request may be coming if I find a good solution.

:+1: for a fix!

I've had my eye on Chosen for almost two years now, and it's still the most elegant select UI improvement around. But this hidden issue is still a major deal-breaker, and 100% width is no solution.
+1 to fix this. Go team chosen!

+1 for fix

In addition to the official workaround which enables the caller to programmatically set the width, I would also suggest a decent workaround, loosely based on the following thread:

http://stackoverflow.com/questions/1841124/find-the-potential-width-of-a-hidden-element

The workaround basically relies on this function:

// to be placed anywhere before the jquery.chosen initialization
    var getHiddenOffsetWidth = function (el) {
    // save a reference to a cloned element that can be measured
    var $hiddenElement = $(el).clone().appendTo('body');
    // calculate the width of the clone
    var width = $hiddenElement.outerWidth();
   // remove the clone from the DOM
   $hiddenElement.remove();
   return width;
};

Wich is then called by the following mod of the jquery.chosen code (as of 1.0.0):

AbstractChosen.prototype.container_width = function() {
    if (this.options.width != null) {
        return this.options.width;
    } else {
        return "" + (($(this.form_field).is(":visible"))
            ? this.form_field.offsetWidth
            : getHiddenOffsetWidth(this.form_field)) + "px";
    }
};

See also #795 for further details on this.

A quick fix. Instead of hiding your select do $(elem).chosen(options) and then a $(elem).hide() i.e first create the chosen element and then hide it. That way the original width is retained.

Is this not fixed yet, 3 years open?

+1 for this fix

Version 0.9.8 did not have this bug! you used to call jquery outerWidth to get width, now you use HTML offsetWidth, which yields to zero...

I believe he means it's a regression, which is promising. Was there a
reason for switching away from the jQuery method?

@pfiller I was having this issue using jQuery 1.10.2 and your $("select").chosen({ width: '50%' }); solution works great for me. This is a workable workaround for my use cases.

I use $(this.form_field).outerWidth() to get offset width, below the complete code:

AbstractChosen.prototype.container_width = function() {
    if (this.options.width != null) {
        return this.options.width;
    } else {
        return "" + $(this.form_field).outerWidth() + "px";
    }
};

+1 I really need this fix. I'm hiding a form by default and the user must click a button to show it. Since it's hidden it is not properly setting the width of my selects

@henesnarfel - You may want to try to just use the workaround that @pfiller posted here: https://github.com/harvesthq/chosen/issues/92#issuecomment-18163306

bump, issue is still there. There should be a built-in solution for this. I'd +1 that.

The only work around I could think of was going to line 455 (on my editor at least), which returns the following code from function container_width:

return "" + this.form_field.offsetWidth + "px";

and replaced it with

return "" + $(this.form_field).outerWidth() + "px";

The problem disappeared.

@ayyash doesn't fix the issue completely. Just makes it better than width 0.

For me, this did the trick (fill in your own sizes for pleasure):

/* Fix  width bug */
.chosen-container, .chosen-drop, .chosen-drop .chosen-search, .chosen-drop {
  width: 220px !important;
  -webkit-box-sizing: border-box;
     -moz-box-sizing: border-box;
          box-sizing: border-box;
}

/* Input Box has to be slightly smaller, don't know why and I don't care. */
.chosen-search input {
    width: 210px !important;
  -webkit-box-sizing: border-box;
     -moz-box-sizing: border-box;
          box-sizing: border-box;
}

/* Override width of the whole thing */
.chosen-container { width:220px !important; }

Thanks

@Thinklabsnk Thanks, nice and quick fix.

EDIT: This only works if all your select elements will have the same width.

Here's my workaround for this, based on some of the other suggestions. It clones the hidden inputs and appends them to the body in order to measure the width, but it also sets the visibility of the clones to hidden before appending, so that they won't be displayed on screen.

Find this line of code in chosen.jquery.js (line 455 in my version):

        return "" + this.form_field.offsetWidth + "px";

and replace it with this:

        var calculatedWidth = this.form_field.offsetWidth;
        // Fix for zero width on hidden inputs.
        if (0 == calculatedWidth) {
          var clone = this.form_field_jq.clone();
          clone.css("visibility", "hidden");
          clone.appendTo('body');
          calculatedWidth = clone.offsetWidth;
          clone.remove();
        }
        return "" + calculatedWidth + "px";

Hope that helps.

@danjjohnson Thanks, that did the trick!

The only thing is that I had to change:

clone.offsetWidth; 

to

clone.outerWidth();

For some reason, clone.offsetWidth was giving me an undefined value.

Best regards,

This bug happens in Firefox, never test on Chrome, or others.

1st image (on top)
The chosen set width as it has scroll bar while it has not. This is incorrect result.

2nd image (middle)
Chosen set width as it has scroll bar like first image but this time it has scroll bar which is correct.

3rd image (bottom)
This is how first image should be while it has no scroll bar. This test i was set chosen width to width: 100% !important

:thumbsup: for @danjjohnson's fix with @johnmerced's modification

I have another fix, simple and works. The point in don't let the width to become zero:

   // don't let the width to be "0"
   $(".chosen-select,.chosen-multiple-select").each(function(){
        if($(this).width() == 0){
            $(this).width(240);
        }
    });
    // call it :)
    $(".chosen-select,.chosen-multiple-select").chosen({allow_single_deselect:true});

Hallo,
my soution for this issue is a combination of the until now posted solutions (chosen 1.2.0):

    AbstractChosen.prototype.container_width = function () {
        if (this.options.width != null) {
            return this.options.width;
        } else {
            //Original:
            //return "" + this.form_field.offsetWidth + "px";
            //Workaround:
            if(this.form_field.offsetWidth > 0) {
                return "" + this.form_field.offsetWidth + "px";
            } else {
                if($(this.form_field).css('width')) {
                    return parseInt($(this.form_field).css('width'),10) + "px";
                } else {
                    return "" + $(this.form_field).outerWidth() + "px";
                }
            }
        }
    };

Just define a static css-width in px for the hidden selects.

An overall fix is still required.

The problem here is that if you change the size of the window, the select always appears the same size as there was initialized. I think a better solution would be to resize the select when shown or when window is resized, rather than to guess the width it should take at initialization when it is hidden.

Is there no way to dynamically change the size of the chosen object? Since I know when to change the size (resize event or onShow or similar), it could be a workaround. Is there an API function to change the size of the chosen object? Or reinitialize somehow?

:+1: for a fix. Ran into this today

:+1: Wasted _way_ too much time tracking this down.

Still having a problem with size in modals. Any plan to fix it in 4.0 release?

@danjjohnson your fix does not fix problem when first element is much smaller then others

based on @danjjohnson that's what worked for me

hack

find line

return "" + this.form_field.offsetWidth + "px";

replace with

var calculatedWidth = this.form_field.offsetWidth;
          // Fix for zero width on hidden inputs.
          if (0 == calculatedWidth) {
              var clone = this.form_field_jq.clone();
              clone.css({"left": 10000, "position": "fixed"});
              clone.appendTo('body');
              calculatedWidth = clone.outerWidth();
              clone.remove();
          }
          return "" + calculatedWidth + "px";

$('select').chosen({width: '100%'}); by @pfiller worked for me in a collapsable panel.

Thanks

How can I get rid of the chosen-search class as I am not able to load the assets in my project directory?

I had to add a timeout, when loading static selects from a template that had not been rendered yet. Nothing in the hierarchy had metrics when it attempted initialization. Wrapping it in a zero timeout at least bumped initialization to the end of the event queue..

// Found this in chosen.jquery.js and patched it as follows
AbstractChosen = (function () {
    function AbstractChosen(form_field, options) {
        if (!AbstractChosen.browser_is_supported()) {
            return;
        }

        var self = this;
        window.setTimeout(function () {
            self.form_field = form_field;
            self.options = options != null ? options : {};
            self.is_multiple = self.form_field.multiple;
            self.set_default_text();
            self.set_default_values();
            self.setup();
            self.set_up_html();
            self.register_observers();
        }, 0);
    }

I've just been bitten by this bug, 100% fixed the problem for me.

@harvesthq would you accept a pull request fixing this? Not sure about the best solution yet but I would be happy to fix and make a pull request :heart:

A robust workaround for this is to use ng-if instead of ng-show. Works perfectly and is simple.

I have figured out that ng-if is the prefered choice in many situations. Not only repairing broken ng-select, but also to allow recursive controllers (using a combination of ng-if, ng-controller, ng-init and ng-template).

so it seems this 4 years old issue is still not resolved?!?!

+1

+1 in the meantime... I'm using select2

Is there any way to have a spinner in the area expanding when clicked chosen picklist, It must happen while data is being appended to the chosen jquery. I am processing a huge number of records into chosen jquery and it takes time to process and show them. ??

What an epic 5 year bug... and still biting people (ouch!).

Google has a similar bug with their map that doesn't display properly in a hidden div. however both these problems have workarounds that are simple to implement.

Yes, I hit that google maps bug some time last year IIRC, but how many folks spent half a day cursing and trying various things before finding this report? Bugs like these in popular libraries waste hours of time. Multiplied across the number of folks learning either of these libraries each year the aggregate costs are probably staggering... If they aren't going to fix it, that's ok. Fixing it at this point might interact strangely with vast numbers of deployed workarounds perhaps... In that case they should admit they aren't fixing it and document the workaround somewhere prominent in the documentation so that folks don't struggle to make (or miss) deadlines over this stuff.

My "overall" fix is similar to others, and it assumes that all my selects' widths in the markup are 100% of their parent div. We use bootstrap so this is the case for us.

Run this code just after you initialize .chosen() at page load.

```
$(".chosen-container").each(function(i, elem) {
if ($(elem).width() == 0) {
$(elem).width("100%");
}
});
````

To those of you that had a problem where if the element was initially inside a css hidden container, and then when made visible had a width of 0px - the fix I found was to set the width in js config;

var config = { '.chosen-select' : {}, '.chosen-select-width' : {width:"95%"} } for (var selector in config) { $(selector).chosen(config[selector]); }

Then I gave the select inputs the css class chosen-select-width

<select name="f01" class="chosen-select-width" id="item_select_staff">

Seemed to do the trick with chosen v1.6.2 and jquery version 3.1.1.

I just leave the default chosen width option (auto) and add

.chosen-container { min-width:5em; }

to my site's CSS (adjusting the min-width as needed). This makes it never become 0px (or just too small to use) while still fitting the select's ideal width when possible (forcing a 100% width or something to that effect doesn't work well when you have select elements inline with other content & this method addresses the core issue as well as allowing for inline select elements & seemingly offering the simplest & most straightforward implementation).

How is this still broken after SEVEN years?

My workarond with bootstrap 3 is adding the following style:

.chosen-container {
    min-width: 90%;
}

My workarond with bootstrap 3 is adding the following style:

.chosen-container {
    min-width: 90%;
}

Buy then the dropdown still doesn't show.... @koenvanderlinden

it is already documented
https://harvesthq.github.io/chosen/options.html
Check the width option and its description

@qbadev Although this makes it so the element doesn't size to fit the content when needed so I don't really see that as a fix (especially when using min-width provides a better result than this).

The documentation's description effectively just calls out the bug (which should be possible to resolve) and mentions using that as a potential workaround for the bug.

@koenvanderlinden recommends min-width:90%; so it's normally 90% width with it going up to 100% width if the contents of the select necessitate it. Then again, I still opt for min-width:5em; (exact em value varying depending on the use case) so it's never too small, but it still tries to expand to fit the content of the select rather than sizing based on the parent element.

@KZeni I didn't say it's a fix. It's just documented. And it is a fine solution. My main issue was that Chosen was almost 0 width after init. Now, after "fix", I can see chosen and can do with it whatever I want using CSS classes applied to parent element.

I faced such problems many times before, that couldn't be calculated because object was 0 width. It can't be resolved in a universal way, as each application differs.
So when ones select is visible in a moment of init, no action is needed, but if it's hidden, using width option is a way to be used.

Custom Width Support
Using a custom width with Chosen is as easy as passing an option when you create Chosen:
$(".chosen-select").chosen({width: "95%"});

https://harvesthq.github.io/chosen/

I found this problem after jQuery upgrade from 1.* to 3.* release.
Solved that:

chosen.jquery.js:543
AbstractChosen.prototype.container_width = function () {
return this.form_field.offsetWidth + "px";
->
return $(this.form_field).outerWidth() + "px";