Disable Chosen on iOS devices (iPad, iPod, iPhone)

[koenpunt]

As a solution (until actual support is implemented?) for #27, #382, #1088 and #1233 I've flagged iOS browsers as unsupported.

[kenearley]

Seems like a good idea to me.

[kenearley]

Maybe we should do the same for Android. https://github.com/harvesthq/chosen/issues?direction=desc&labels=Android&page=1&sort=created&state=open

[tjschuck]

Two lines up, we're returning null instead of false. Should probably be consistent. (Though probably consistent with false, not null.)

[pfiller]

I think I'd rather we change two lines up to be false. We're returning true by default and I think it's better to assume that a method name like browser_is_supported will return a boolean (or a JavaScript approximation of a boolean).

[pfiller]

Oh - I see @koenpunt's reply below and he's right. We're not returning null, we're returning the value of the comparison. Carry on.

[tjschuck]

Would close #409 as well.

[koenpunt]

We're not returning null, we're comparing to null ;)

[koenpunt]

Or is isnt short for js if (!...)?

[tjschuck]

@koenpunt I really have no idea there. That line should probably be rewritten altogether :)

[pfiller]

On the iPhone, I don't think there should be any question that Chosen should be disabled. The keyboard covers up the list and searching is awkward.

On iPad, it's less cut and dry. When you zoom in on Chosen, I think it's probably better than the default select control. When it's at 1:1, it's probably a slight edge to the native select (but only because of size). I'm not sure we should make a choice like this for a developer when it's totally functional on iPad. People can opt out when they apply Chosen, no?

I'm not sure what to say about Android. I assume the small form factor problem the iPhone presents is also a problem on Android phones, but is there an easy way to separate phones vs. tablets? I guess there it would make sense to block all devices.

Confusing.

[koenpunt]

I've updated the tests that only iPod and iPhone are not supported and neither are Android devices if the useragent string contains mobile.

[ursbraem]

Hmmm... it's not an even trade, as on the iPhone, there's no typeahead for the select. If you're using chosen for a list of 3500 places (like me), there's going to be a lot of swiping.

[pfiller]

It's easy enough to undo this change in your own project if you feel Chosen is better (just remove the test). This change is about making Chosen's default settings the best they can be.

[stof]

@pfiller then maybe it should be an option (defaulting to disable on mobile) instead of forcing to edit the source and recompile it ?

[ursbraem]

As well as

AbstractChosen.default_multiple_text = "Select Some Options";
AbstractChosen.default_single_text = "Select an Option";
AbstractChosen.default_no_result_text = "No results match";

which would be nice to be able to pass in as an option (the tool I'm using can't write the data-placeholder) for multi-language use.

But of course hacking the plugin is an option, just normally developers discourage that :-)

[ursbraem]

I've disabled the test for mobile in my setup. For me, that's better, thanks

[MrBigDog2U]

The Chosen UI doesn't behave correctly on iPad devices. It just shows the list of options below the Chosen control and doesn't allow the user to select one. I tested this on iPad using both Chrome and Safari and got the same behavior on both.

I recommend adding the iPad to the detection code for unsupported browsers.

[janseliger]

"It's easy enough to undo this change in your own project if you feel Chosen is better (just remove the test). This change is about making Chosen's default settings the best they can be." by pfiller

Could you please add the browser check as a constuctor option. In my case chosen works like a charm on the static disabled devices.

[koenpunt]

You can alter the display of the select's on mobile by just using CSS.
Example here: http://bavotasan.com/2011/style-select-box-using-only-css/

And the last example would look like this on the iPhone:

[sebszocinski]

Yes thats nice but then you still get the default UI select drop down - ugly and too obtrusive on mobile... I prefer a div like in this site im working on...

[kumar74g]

Has anyone been able to use Chosen on mobile devices?

[MichaelWatzke]

I tried to activate chosen(only basic single dropdown) on iPad/iPhone/Android and everything seems to be okay.

[milengg]

We use Chosen with good results on our mobile web views. The only thing the user needs to do is scroll up slightly after search start. It will be better if Chosen calculate distance to top/bottom and opens where there is more space.

[Rikaelus]

I agree an option would be nice. I've hacked the code to make the test fail, thereby getting Chosen to work on mobile, but that's obviously not ideal since it'll be overwritten if/when I update Chosen to any newer version.

At the very least, if it's the search field that is believed to present visual problems on mobile, maybe have the test only apply when search is enabled. But a full option would still be best.

[rafenden]

There is any way to turn on support for iOS and Android devices without hacking chosen lib?

[Ruxton]

@rafalenden you can override the function. Provided you override it before you initialise chosen it seems to work ok.

AbstractChosen.browser_is_supported = function() { return true; } // or replace with your own tests to return false/true

[koenpunt]

@Ruxton the AbstractChosen class is not exposed in the jQuery version.

[rafenden]

I'm using jQuery version.

[campbeln]

Rather than redefining AbstractChosen.browser_is_supported why not just change the two test lines from...
if (!AbstractChosen.browser_is_supported()) {
to...
if (!AbstractChosen.browser_is_supported() && !options.disable_search) {

Then devs who want to have a consistent UI experience (and have multiple selected elements shown nicely on-screen) without the weirdness of the on-screen keyboard can have it.

Of course, this only works if search is disabled, so a valid argument could be made for an options.disable_on_mobile or likewise.

Anyway... my 2c.

[rafenden]

I've created fork that works on mobile devices.
Feel free to use it: https://github.com/rafalenden/chosen

[marc-gist]

Seems to work fine on Android 4.4 ... will test in iPad etc.

so i agree with above people we should get an easy to set option to override this behavour.

[manmohan-bisht]

Hi Marc..is this working for you on all mobile and touch devices ? If yes could you pls share your... code here..

[marc-gist]

manmohan-bisht: i just followed what others said to do; on line 504 I did this to the function there

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;
    };

    AbstractChosen.default_multiple_text = "Select Some Options";

    AbstractChosen.default_single_text = "Select an Option";

    AbstractChosen.default_no_result_text = "No results match";

    return AbstractChosen;

  })();

I've tested on iPad 2 (fully updated, not sure what version that means), and Android 4.2+ and it seems to work just fine. Can scroll a bit "funny" but works well enough.

[fritzgithub]

I agree with rockethouse (may 7 2014)
I use Chosen for design and UI but i do not at all need the search feature.
I cannot understand why this cannot be turned off for multiple selects (or do i keep overseeing things?).
Without search (and keyboard opening) on mobile devices, chosen would work like a charm (at least on my single test with firefox an android tablet).
Is there any chance i can deactivate search on multiple selects?

[Mushr0000m]

Hi, any plans to make Chosen stable on iOS and Android ?

[koenpeters]

If support for Chosen is eventually added I think it would be a good idea to simply use a full screen view (filter + list) for the phone and small tablet use cases. This mimics the native combo boxes and offers the best usability for users, especially a big chunk of the screen is taken up by a keyboard.

[koenpunt]

@koenpeters I like that thought! But probably required a LOT of CSS updates.

[koenpunt]

@mlettini maybe you can do a suggestion on what @koenpeters idea could look like?

[mlettini]

@koenpunt @koenpeters That is a neat idea, and it might be doable, but it probably requires JS changes too. Because if we're talking CSS-only then you'd need to move the Chosen select out of it's position, which would require position: fixed. And if it's fixed, that usually doesn't work too well on mobile. And then the CSS would need to accommodate if the keyboard is open or not, and I'm not entirely sure how well that is handled (probably "not well at all"). And on top of all this, there's the different mobile OSes and their styles, and then we'd have to support certain mobile browsers... high effort IMO.

If I had the time, I might try a prototype, but alas, I don't right now.

[koenpunt]

Issues with position: fixed was the first thing that came to mind for me as well, but if you take a look here: http://caniuse.com/#feat=css-fixed, you'll see that's probably not much of a problem anymore.

[tjschuck]

@koenpeters @koenpunt @mlettini Any additional discussion about enabling Chosen on mobile should probably be a new issue. You can link back to this thread, but this thread is "closed" (via merge), so it's more likely to get lost when people are looking for open feature issues.

@koenpeters Do you mind opening a new issue summarizing from your comment down?