New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 3 commits into from Jul 24, 2013

Conversation

Projects
None yet
@koenpunt
Member

koenpunt commented Jul 22, 2013

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

@kenearley

This comment has been minimized.

Show comment
Hide comment
@kenearley

kenearley Jul 23, 2013

Seems like a good idea to me.

kenearley commented Jul 23, 2013

Seems like a good idea to me.

@kenearley

This comment has been minimized.

Show comment
Hide comment
@tjschuck

This comment has been minimized.

Show comment
Hide comment
@tjschuck

tjschuck Jul 23, 2013

Member

Would close #409 as well.

Member

tjschuck commented Jul 23, 2013

Would close #409 as well.

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jul 23, 2013

Member

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

Member

koenpunt commented Jul 23, 2013

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

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jul 23, 2013

Member

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

Member

koenpunt commented Jul 23, 2013

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

@tjschuck

This comment has been minimized.

Show comment
Hide comment
@tjschuck

tjschuck Jul 23, 2013

Member

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

Member

tjschuck commented Jul 23, 2013

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

@pfiller

This comment has been minimized.

Show comment
Hide comment
@pfiller

pfiller Jul 23, 2013

Contributor

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.

Contributor

pfiller commented Jul 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jul 24, 2013

Member

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

Member

koenpunt commented Jul 24, 2013

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

pfiller added a commit that referenced this pull request Jul 24, 2013

Merge pull request #1388 from koenpunt/browser-support
Disable Chosen on iPhone / iPod and Android mobile devices by default

@pfiller pfiller merged commit 6638dd7 into harvesthq:master Jul 24, 2013

@koenpunt koenpunt deleted the koenpunt:browser-support branch Jul 25, 2013

pfiller added a commit that referenced this pull request Jul 26, 2013

Version 0.14.0
- CSS Updates #1368, #1371
- Prevent text selection on Chosen #1374
- single_backstroke_delete defaults to true #1375
- No longer expose classes to window context #1389
- Single select value fix #1392
- Remove javascript:void and attr references #1385, #1377
- Disable Chosen on iPhone / iPod and Android mobile devices
  by default #1388
- Add Destroy Method #1396
- Option to Hide Selected & Disabled Options #1404
- Always clear result highlight #1407
- Replace characters only once #1411

- Document all the things. #1366, #1376, #1383
- Add Gemfile for compass dependency #1373
- Update copyright and license link #1397
- Add @koenpunt as a maintainer #1399
- Add anchors to documentation headers #1395
- Updated stackoverflow instructions #1403
@ursbraem

This comment has been minimized.

Show comment
Hide comment
@ursbraem

ursbraem Jul 29, 2013

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.

ursbraem commented Jul 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pfiller

pfiller Jul 29, 2013

Contributor

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.

Contributor

pfiller commented Jul 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@stof

stof Jul 29, 2013

Collaborator

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

Collaborator

stof commented Jul 29, 2013

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

@ursbraem

This comment has been minimized.

Show comment
Hide comment
@ursbraem

ursbraem Jul 29, 2013

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 commented Jul 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ursbraem

ursbraem Jul 29, 2013

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

ursbraem commented Jul 29, 2013

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

@MrBigDog2U

This comment has been minimized.

Show comment
Hide comment
@MrBigDog2U

MrBigDog2U Aug 6, 2013

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.

MrBigDog2U commented Aug 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@janseliger

janseliger Aug 21, 2013

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

janseliger commented Aug 21, 2013

"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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt May 7, 2014

Member

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:
screen shot 2014-05-07 at 14 35 55

Member

koenpunt commented May 7, 2014

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:
screen shot 2014-05-07 at 14 35 55

@sebszocinski

This comment has been minimized.

Show comment
Hide comment
@sebszocinski

sebszocinski May 8, 2014

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

image

sebszocinski commented May 8, 2014

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

image

@kumar74g

This comment has been minimized.

Show comment
Hide comment
@kumar74g

kumar74g May 24, 2014

Has anyone been able to use Chosen on mobile devices?

kumar74g commented May 24, 2014

Has anyone been able to use Chosen on mobile devices?

@MichaelWatzke

This comment has been minimized.

Show comment
Hide comment
@MichaelWatzke

MichaelWatzke Jun 6, 2014

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

MichaelWatzke commented Jun 6, 2014

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

@milengg

This comment has been minimized.

Show comment
Hide comment
@milengg

milengg Jul 22, 2014

chosenongalaxys3

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.

milengg commented Jul 22, 2014

chosenongalaxys3

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

This comment has been minimized.

Show comment
Hide comment
@Rikaelus

Rikaelus Jul 28, 2014

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.

Rikaelus commented Jul 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@rafenden

rafenden Jul 28, 2014

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

rafenden commented Jul 28, 2014

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

@Ruxton

This comment has been minimized.

Show comment
Hide comment
@Ruxton

Ruxton Jul 30, 2014

@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

Ruxton commented Jul 30, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jul 30, 2014

Member

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

Member

koenpunt commented Jul 30, 2014

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

@rafenden

This comment has been minimized.

Show comment
Hide comment
@rafenden

rafenden Jul 30, 2014

I'm using jQuery version.

rafenden commented Jul 30, 2014

I'm using jQuery version.

@campbeln

This comment has been minimized.

Show comment
Hide comment
@campbeln

campbeln Sep 3, 2014

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.

campbeln commented Sep 3, 2014

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.

gavinhungry added a commit to gavinhungry/sandbug that referenced this pull request Sep 5, 2014

@rafenden

This comment has been minimized.

Show comment
Hide comment
@rafenden

rafenden Oct 10, 2014

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

rafenden commented Oct 10, 2014

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

@marc-gist

This comment has been minimized.

Show comment
Hide comment
@marc-gist

marc-gist Nov 29, 2014

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.

marc-gist commented Nov 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@manmohan-bisht

manmohan-bisht Dec 9, 2014

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

manmohan-bisht commented Dec 9, 2014

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

@marc-gist

This comment has been minimized.

Show comment
Hide comment
@marc-gist

marc-gist Dec 9, 2014

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.

marc-gist commented Dec 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@fritzgithub

fritzgithub Mar 20, 2015

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?

fritzgithub commented Mar 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Mushr0000m

Mushr0000m Aug 12, 2015

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

Mushr0000m commented Aug 12, 2015

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

@koenpeters

This comment has been minimized.

Show comment
Hide comment
@koenpeters

koenpeters Oct 2, 2015

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.

koenpeters commented Oct 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Oct 2, 2015

Member

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

Member

koenpunt commented Oct 2, 2015

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

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Oct 2, 2015

Member

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

Member

koenpunt commented Oct 2, 2015

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

@mlettini

This comment has been minimized.

Show comment
Hide comment
@mlettini

mlettini Oct 2, 2015

Member

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

Member

mlettini commented Oct 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Oct 2, 2015

Member

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.

Member

koenpunt commented Oct 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tjschuck

tjschuck Oct 2, 2015

Member

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

Member

tjschuck commented Oct 2, 2015

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

@harvesthq harvesthq locked and limited conversation to collaborators Oct 2, 2015

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