Access issues on mobile and tablet Webkit/Chrome browsers
Opened this issue · 7 comments
We have used this in webapplication and on all the browsers on laptops this is working fine, but accessing this on the tablet browsers like on android(chrome browser) and iOS (safari), the list is not displaying the content.
Please find the attached screen shot on laptop browser
Please find the attached screen shot on tablet browser
I can replicate this behavior on Chrome on Android (but not Firefox on mobile).
It appears that Webkit-derived browsers will show this alternative to <select> lists. Tapping the gray area will allow a user to select the items, but this is not as ideal as a traditional <select> list. This may further drive the need for custom option rendering (#38) to provide a more attractive UI for mobile devices.
@jakezatecky Any ETA that we can get to make this work ? I mean on custom option rendering feature ?
To be frank, that feature is a bit lower on the priority list.
I would welcome a pull request that implements custom option rending. Whatever we support needs to emulate many of the similar DOM events that <select> elements have. It is very feasible but a bit of a chore.
I spent a fair bit of time today researching how to mitigate this issue. It appears there is no way to force Webkit and Chromium mobile browsers to render a list of items when using the multiple flag on <select> elements like we do. It will always show that "X selected" interface even when specifying the size property. Firefox behaves correctly, but it is a minority browser.
The only way to approach this issue is to forgo the native <select> and <option> elements and use custom DOM elements to mimic that functionality. This is not an easy task, and would require either using a third-party library or writing our own.
any updates on mobile view issue? @jakezatecky
I already detailed my findings above.
Without replacing the native select HTML elements with something custom, this issue will persist. I am not keen on spending 20+ hours rewriting the entire internals to use custom elements all because Chrome refuses to provide any mechanism to force regular behavior on mobile devices. Thus, this is exceptionally low priority.
A Chromium bug tracker exists for this issue. It is unlikely to get any fix anytime soon, so a rewrite of underlying components may be necessary.