I am testing on my iPhone, by clicking on the normal select list (without Chosen widget) popups the built-in iPhone list selector. However, after switching to the Chosen widget, neither the builtin list selector shows up nor the keyboard to type the characters.

#7 chosen-mobilephonesupport-1338446.patch2.72 KBkentoro
Members fund testing for the Drupal project. Drupal Association Learn more


Cyclodex’s picture

Status: Active » Postponed (maintainer needs more info)

Any suggestions what we can do here?

Chosen replaces the select and so it will not work with the special iphone behavior.

Not sure what we can do about this. Any suggestions ? Exclude it ?

philsward’s picture

At this point, would love to see it excluded somehow for mobile... I just tried it out and found it to be a pain in the ass to use :-/ Works great on desktop though!

Exploratus’s picture

I agree a simple exclusion would be fantastic. It really makes mobile unfriendly and hard to use.

dtarc’s picture

I agree. Chosen is great on Desktop but I'm not using it on a few sites that need to be mobile friendly.

The tough part is determining whether or not it's a mobile page.

One way that I can think of that could be easy is to base it on a css class. So, Chosen module adds a settings variable to hold an exclude class to check for in the page body. Then, when the select element is being replaced, check if this css class is on the body, and if so, then don't replace.

This would allow for easy configuration with responsive themes like Omega (which puts a class in the body indicating a mobile screen). It also allows for other types of mobile-targeted solutions to tweak things by changing the body class.

Exploratus’s picture

I was using chosen js with a magento site, and the mobile functions still worked fine but looked styled as is the case with chosen. Ideally, we need a way to be able to have mobile functionality on mobile site, and great desktop functionality offered by chosen. More and more traffic is going the way of mobile.

kentoro’s picture

I had the same issue and solved it easily with jQuery, (i did this in chosen 7.1 but as i read the code for 7.2 my recommendation should work in 7.2 as well)

The thing is, even the iPad has a custom behavior when using select lists, so you may not only want to exclude it from phones but maybe even for tablets in portrait mode (my case)

So this is what i recommend:
Have an additional option where you put the chosen width for the window's width:
var minWindowWidth = Drupal.settings.chosen.minimum_window_width;
where we could insert e.g: 480 or 980 or etc. [default 0]

then on line 12 of the chosen module add this condition:

      $(Drupal.settings.chosen.selector, context)
        .not('#field-ui-field-overview-form select, #field-ui-display-overview-form select') //disable chosen on field ui
        .each(function() {
        if ($(this).find('option').size() >= Drupal.settings.chosen.minimum) {
            width : ($(this).width() < minWidth) ? minWidth : $(this).width()

So when the screen is bigger than the value in minWindowWidth chosen will be available else it would be ignore.
Add me to contributors and i'll fix it my self ;)


kentoro’s picture

Version: 7.x-1.0 » 7.x-2.x-dev
Status: Postponed (maintainer needs more info) » Patch (to be ported)
2.72 KB

Patch adds a GUI textfield for input of the min window width,
register the variable and sends it to the js, in the js it will ignore anything less than the minimun window width.
First patch ever, hope it works well.

kentoro’s picture

Status: Patch (to be ported) » Needs review

needs review of course

Hydra’s picture

Status: Needs review » Needs work

Not sure if this is the right approach. If you are optimizing for mobile devices, you usually already saved the mediaquery informations. I think using the breakpoints module to achieve that would be a nice solution. Since it's part of drupal8 and there is a nice backport, we should try using it. Just guessing...
I'm open for other ideas, too. The general idea behind this issue is reasonable and the solution needs to be discussed.

Hydra’s picture

Category: bug » feature

This is more a feature request then a bug actually..

kentoro’s picture

I hear you,
post #4 gives a great example of using the already generated ".responsive-layout-mobile" class
but since i would also like to iPad in portrait to play nice with the select elemtents I now propose an array of classes, to be included or be excluded.

So the discussion goes on, should the setting exclude or include the classes provided in such an array?

-I see this as an extension of the chosen module instead of requiring yet another module.


Hydra’s picture

Well right now, chosen has no dependencies on any modules. This would also be an optional dependency. If you're using breakpoints for instance, you can use it to make chosen responsive friendly, you see?
Right now we do the same with libraries module. It's not required (anymore), but if you're using it, chosen will use it.

kentoro’s picture

What if people with already predefined breakpoints as in omega won't like to add the breakpoints module to their enviroments?
Omega is already defining the breakpoints and giving them the body classes needed so why install the second one? [just to add a tiny feature to chosen?].

Is this a possible scenario?

In that case, it should have the option for classes incorporated to the module and IF you are using the breakpoints module, to get the variables from there instead? the textarea hides and checkboxes with generated information from breakpoints could show.

(Keep in mind we're just discussing options here) :)


Hydra’s picture

I'm using the omega theme a lot. The approach Omega 3 uses is pretty bad and not reusable by other modules. Fubhy was aware of this and removed this in Omega 4.x in favour of more customizable and reusable options.
I see your point, but I still think using a generic approach would be better. This is where all ather modules and themes will develop to, too (See D8).

(I know, we are just considering options, thanks for giving so much input!)

kentoro’s picture

So your proposal is: to make this possible only when the breakpoints module is present then.?

Hydra’s picture

Yeah, as an optional feature.

kentoro’s picture

As it turns out, i am unable to get to the responsive-layout-normal class,
since chosen is "and iam guessing here" being loaded before omega does its thing,
so when looking for that class, that class hasnt actually being defined yet. any thoughts?

Not even with the:

  drupal_add_js('delete Drupal.behaviors.chosen', 'inline');

and then adding it in my custom.js is working.

i wonder if it'll even react to the breakpoint module since its not reacting to omega when the time is right,

Hydra’s picture

Breakpoints module only provides an api to store breakpoints. How you use them in your module belogns to you. Since it's storing mediaquery definitions, we could check on resize event, if the current window.width() is >= minumum.breakpoint.width to load or not load chosen for example, you know what I mean? We can access these settings directly in javascript, their is no need of using any classes set by js.

junedkazi’s picture

Status: Closed (works as designed) » Needs work

OK look like the library has been updated and chosen will be disabled automatically at by checking window navigator


AbstractChosen.browser_is_supported = function() {
      if (window.navigator.appName === "Microsoft Internet Explorer") {
        return document.documentMode >= 8;
      if (/iP(od|hone)/i.test(window.navigator.userAgent)) {
        return false;
      if (/Android/i.test(window.navigator.userAgent)) {
        if (/Mobile/i.test(window.navigator.userAgent)) {
          return false;
      return true;

So anyone facing this issue. Please update to the latest version of chosen. If any issue please report it back to the chosen issue queue on github.

junedkazi’s picture

Status: Needs work » Closed (works as designed)

I will mark it as works as designed. As it is coming from the library.

kentoro’s picture

Status: Needs work » Closed (works as designed)

So here you are testing if its iOS or Android,

What if it is a blackberry or FirefoxOS, or Tizen, or UbuntuTouch,
Then we are back to 0 again. Although i agree that the added support should be in the library it seems cleaner.

Awesome input by the way.

kentoro’s picture

Status: Closed (works as designed) » Postponed

Looks like it doesn't have an official release yet for the version with iOS/Android exclusion.


so I'm changing status posponed untill it's officially release.

junedkazi’s picture

@kentoro the code mentioned above is from the 1.0.o release only. For other mobile OS support I believe you should create a ticket in the chosen issue queue.

kentoro’s picture

Status: Postponed » Closed (works as designed)

My bad,

To use the latest version of the library, update the module to dev version.

zilla’s picture

and then replace the .js file only from harvest source site (it's at 1.0)? detailed instructions would be great

i noticed that the files from the direct download appear to be quite different from the drupal implementation (per the 1.0 release at https://github.com/harvesthq/chosen/releases) - so i'm still confused about what to swap out in the dev version. my understanding is that, for example, the webkit issues were fixed for mobile safari in latest chosen (and some multiselect issues on android)