Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#26 | allow_chosen_mobile.patch | 98.46 KB | TiagoZ |
#7 | chosen-mobilephonesupport-1338446.patch | 2.72 KB | Anonymous (not verified) |
Comments
Comment #1
Cyclodex CreditAttribution: Cyclodex commentedAny 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 ?
Comment #2
philsward CreditAttribution: philsward commentedAt 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!
Comment #3
Exploratus CreditAttribution: Exploratus commentedI agree a simple exclusion would be fantastic. It really makes mobile unfriendly and hard to use.
Comment #4
dtarc CreditAttribution: dtarc commentedI 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.
Comment #5
Exploratus CreditAttribution: Exploratus commentedI 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.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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:
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 ;)
/K
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedPatch 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.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedneeds review of course
Comment #9
Hydra CreditAttribution: Hydra commentedNot 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.
Comment #10
Hydra CreditAttribution: Hydra commentedThis is more a feature request then a bug actually..
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
/K
Comment #12
Hydra CreditAttribution: Hydra commentedWell 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.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedWhat 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) :)
/K
Comment #14
Hydra CreditAttribution: Hydra commentedI'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!)
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedSo your proposal is: to make this possible only when the breakpoints module is present then.?
Comment #16
Hydra CreditAttribution: Hydra commentedYeah, as an optional feature.
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedAs 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:
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,
Comment #18
Hydra CreditAttribution: Hydra commentedBreakpoints 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.
Comment #19
junedkazi CreditAttribution: junedkazi commentedOK look like the library has been updated and chosen will be disabled automatically at by checking window navigator
https://github.com/harvesthq/chosen/pull/1388/files
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.
Comment #20
junedkazi CreditAttribution: junedkazi commentedI will mark it as works as designed. As it is coming from the library.
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedSo 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.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedLooks like it doesn't have an official release yet for the version with iOS/Android exclusion.
https://github.com/harvesthq/chosen/releases/
so I'm changing status posponed untill it's officially release.
Comment #23
junedkazi CreditAttribution: junedkazi commented@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.
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedMy bad,
To use the latest version of the library, update the module to dev version.
Comment #25
zilla CreditAttribution: zilla commentedand 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)
Comment #26
TiagoZ CreditAttribution: TiagoZ as a volunteer commented.