Only trim input_width to container_width when calculable.

[adunkman]

@harvesthq/chosen-developers to fix #2480.

This PR adjusts the logic used to calculate the width of the text input when in multi-select mode.

If Chosen is not visible when initialized (it’s within a hidden container), the calculated width of Chosen’s container is 0. This means that we’re setting the search input width to an initial value of -10px, which is nonsense — resulting in a fallback to it’s default width in CSS (25px).

This, of course, is adjusted after Chosen is interacted with, since it is now visible and the container width can be correctly calculated.

Since we don’t know when Chosen becomes visible, I propose we adjust the default width for the search input to be the full calculated width, and ignore the calculated container_width if it results in zero. The text doesn’t actually overflow outside of the container — the only downside is that a few pixels of space isn’t present.

Here’s a GIF of Chosen (which was rendered off-screen initially) being opened and closed. Before, the width of the search input was not contained to the container, and after it is:

If you didn’t catch it, look for the tail end of the “a” character. This is significantly better than what’s currently happening — the input is rendered at 25px wide:

	Before this PR	After this PR
Before Opening
After Opening

[satchmorun]

@adunkman and I paired on this, because I couldn't reproduce the issue in my jquery HTML test page.

While working on it, we discovered a fun issue with jquery's outerWidth method. The short of it is that if the element is hidden, one should not trust jquery to do anything sensible. For example, with a style of width: 98% (on a non-visible element), it will return 98. Le sigh.

So we needed to do a different thing in the jQuery version than in the prototype version.

Go early 2000s!

[braddunbar]

This is definitely better than the current behavior! 👍 💯