Calling activate_field on choices_click, fixes #1729

[jordanstephens]

Fixes #1729 simply by sending focus to .search-field input when clicking .chosen-choices.

At first, I imagined two possible solutions to this issue:

1. Modify the width of .search-field input to fill the width of .chosen-choices minus the width of any currently selected values.
2. Send focus to .search-field input when clicking .chosen-choices.

The first option was not selected as it was more complicated and it would fail to address the case of clicking inside the red circled area in the following screenshot:

[efedorenko]

It would be great if you guys accept this PR. This issue is annoying.

[jordanstephens]

I just went ahead and rebased this branch to bring it up to date with the latest from master.

Let me know if I can answer any questions.

[jordanstephens]

I hadn't thought of this, but @efedorenko mentioned in #2003 that clicking on .no-results will also take focus away from .search-field input.

I don't think it's as bad of a usability issue as not being able to set focus by clicking inside the visible text field, but it may be a good idea to set focus on this event also.

In general, I think we should strive to maintain focus on that text field as long as the user is interacting with that instance of Chosen; I think clicking on an empty results list falls under that umbrella.

Thoughts? Should we call activate_field() on .no-results click as well?

[koenpunt]

@harvesthq/chosen-developers, @stof; got anything against merging this?

[anteq]

+1, we're affected by #1729 and this seems to fix the problem - would love to see this merged!

[jordanstephens]

Wow, this was on of the first pull requests I ever submitted to an open source project—a little over three years ago. Thanks for merging this!