if select is initially hidden, doesn't work #92

Open
iamnader opened this Issue Jul 27, 2011 · 116 comments

Projects

None yet
@iamnader

This is because when setting the width it will return 0. Using this technique works: http://www.foliotek.com/devblog/getting-the-width-of-a-hidden-element-with-jquery-using-width/

The code should check if the elmt.is(:visible) and if so use the above technique. I'm happy to fix in a fork. @hat is the procedure? Just patch the coffeescript? How do you generate js and js min?

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

obie commented Jul 28, 2011

+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;
}
Contributor
pfiller commented Jul 28, 2011

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()
Contributor
aziz commented Jul 28, 2011

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

v15h commented Aug 1, 2011

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

Contributor
aziz commented Aug 1, 2011

👍 👍 👍

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

@AndrewRayCode AndrewRayCode pushed a commit to AndrewRayCode/chosen-hacks that referenced this issue Aug 5, 2011
Andrew Ray making chosen work with whatever width the input box is set to with c…
…ss for jquery, addressing issue #92
e950156
AlexMC commented Oct 10, 2011

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

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

bewest commented Oct 21, 2011

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.

Contributor
pfiller commented Oct 21, 2011

@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, AndrewRayCode@e950156

bewest commented Oct 21, 2011

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

bewest commented Oct 22, 2011

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

bewest commented Oct 22, 2011

@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 <
reply@reply.github.com

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?

Collaborator
stof commented Nov 16, 2011

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

cballou commented Dec 5, 2011

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.

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 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 :)

dhampik commented Dec 30, 2011

same problem, please, fix it

bewest commented Dec 30, 2011

@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

dhampik commented Jan 7, 2012

@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 )

jotbe commented Jan 19, 2012

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');
Contributor
jcsrb commented Apr 2, 2012

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

Member
koenpunt commented Apr 2, 2012

@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?

Webvida commented Aug 20, 2012

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.

Contributor
pfiller commented May 20, 2013

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?

hugomn commented May 23, 2013

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.

wictor81 commented Jun 4, 2013

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

Contributor

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

trisweb commented Aug 12, 2013

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

Contributor

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.

trisweb commented Aug 12, 2013

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

diosney commented Aug 20, 2013

👍 for a fix!

neokio commented Aug 21, 2013

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.

@saevarom saevarom pushed a commit to saevarom/chosen that referenced this issue Sep 27, 2013
Sævar Öfjörð Magnússon Fixing issue #92, initially hidden select has zero width. 3e0438f
@changi67 changi67 pushed a commit to changi67/tiki that referenced this issue Nov 17, 2013
jonnybradley [FIX] bootstrap: Previous fix to workaround long-running bug harvesth…
…q/chosen#92 was breaking bootstrap tabs leaving tab content hidden. Use alternative clone method to calculate width when needed while they fix it...

git-svn-id: file:///var/local/code.tiki.org/tikisvn/trunk@48511 b456876b-0849-0410-b77d-98878d47e9d5
9b113e7
ratpik commented Mar 19, 2014

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?

monove commented Mar 28, 2014

+1 for this fix

ayyash commented Apr 25, 2014

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

trisweb commented Apr 26, 2014

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: #92 (comment)

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

ayyash commented Jun 28, 2014

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; }
@ghost
ghost commented Jul 11, 2014

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,

ve3 commented Sep 4, 2014

chosen-width

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

👍 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});
xfer84 commented Oct 17, 2014

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?

bbrooks commented Jan 25, 2015

👍 for a fix. Ran into this today

wndxlori commented Feb 5, 2015

👍 Wasted way too much time tracking this down.

@brettsheffield brettsheffield added a commit to brettsheffield/gladd.js that referenced this issue Feb 9, 2015
@brettsheffield brettsheffield hack to fix hidden jquery.chosen combos 6f76eed

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

1

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

@rickychilcott rickychilcott added a commit to RBSavvy/chosen-rails that referenced this issue Apr 1, 2015
@rickychilcott rickychilcott Patching chosen-rails bug to get us OK for deploy. See harvesthq/chos…
…en#92 for more info
55415a8

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 ❤️

@micgro42 micgro42 added a commit to cosmocode/dokuwiki-plugin-farmer that referenced this issue Aug 20, 2015
@micgro42 micgro42 Set width to 100% to workaround chosen issue 747f255
erobwen commented Sep 10, 2015

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?!?!

@randycoulman randycoulman added a commit to OregonShakespeareFestival/digital-archives that referenced this issue Oct 28, 2015
@randycoulman randycoulman Ensure production credits selectors display correctly
In the bulk upload form, the production credits selectors are initially
hidden.  Because of a [known bug in
chosen.js](harvesthq/chosen#92), that causes
the Chosen widget to have a width of 0px.

The [Chosen
documentation](https://harvesthq.github.io/chosen/options.html)
indicates that you must specify a width explicitly in this case.

Based on the styling of the underlying select element, I chose to use
`width: “100%”`, and that seems to work quite well.
b84bac8
@randycoulman randycoulman referenced this issue in OregonShakespeareFestival/digital-archives Oct 28, 2015
Merged

Ensure production credits selectors display correctly #84

+1

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

Shakthivakeeswaran commented May 3, 2016 edited

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

@sminnee sminnee pushed a commit to sminnee/silverstripe-admin that referenced this issue May 13, 2016
@unclecheese @chillu unclecheese + chillu BUGFIX: When Chosen dropdowns are instantiated on hidden tabs, the wi…
…dth is rendered very small and they are unreadable. This is a known bug in Chosen. A change has been proposed at the Chosen page here: harvesthq/chosen#92 but no pull request has been executed.
ef2b32b
@pfiller pfiller removed the Has Solution label Jun 3, 2016
@koenpunt koenpunt added the Sizing label Oct 15, 2016
@apeters apeters added a commit to archesproject/arches that referenced this issue Oct 29, 2016
@apeters apeters chosen binding needs to be updated after changing it's visibility sta…
…te from hidden to shown (harvesthq/chosen#92), this is a little be of a hack, but works, so.... in she goes, re #997
4b77c61
fsparv commented Oct 30, 2016

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.

fsparv commented Oct 30, 2016 edited

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.

@pbearne pbearne referenced this issue in alleyinteractive/wordpress-fieldmanager Dec 23, 2016
Open

A fix to handle showing Chozen items if they are loaded in a hidden block #569

brianjcohen commented Apr 5, 2017 edited

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment