live_select
live_select copied to clipboard
maxmarcon
Keyboard does not show if I click on a liveselect that has a populated value
I am having an issue with my live production app. When I click inside a liveselect that already has a value, it does not show the keyboard to be able to type another value. Since most of the visitors this days are on mobile phones this is a nasty bug. See below a recroding of showcase app (https://live-select.fly.dev/) that shows this problem
https://github.com/maxmarcon/live_select/assets/509403/927c7712-4760-480e-aff1-8708da243deb
As more details I am using an Iphone and Safari browser
Hi. I've tested live select extensively on my mobile phone (Android) and it works fine there. I don't have access to an iPhone. However, I downloaded the iOS simulator for XCode and opened the showcase app there. Indeed, the keyboard is not showing when you focus on the liveselect with the selected value.
I tried to connect Safari to the simulator to take a look at the JS console as explained here, but it didn't work for me.
Do you have access to an iPhone or are you able to debug this problem on XCode Simulator?
I tested on my daughter android phone and the same thing happens.See the recording attached. As you can see I had to click twice in the input to be able to see the keyboard although the input seems to have cursor after first click I guess is something related to focus event and the fact that the input already has a value. I will try to investigate myself also.
https://github.com/maxmarcon/live_select/assets/509403/15f8e494-0ac2-4608-9b43-37920886b926
Thanks. I was able to replicate this on my phone using Chrome as browser. The issue doesn't appear with Firefox (the browser I normally use). I will have a look soon.
I'm running into this now and I'm about to take a look at it.
From what I've gathered regarding WebKit quirks, Apple seems to have elected a rather non-standard way of handling focus that (among other things) creates issues with showing the virtual keyboard when expected.
Maybe this is of interest:
- https://gist.github.com/cathyxz/73739c1bdea7d7011abb236541dc9aaa
- https://github.com/ampproject/amphtml/pull/14676
There is a recent thread on the Elixir Forum regarding the iOS keyboard issue:
https://elixirforum.com/t/triggering-focus-on-mobile-via-js-module/67915
It also links to an issue with the WebAuthn component library.
Tyre kicked this on Android 13. Firefox works great but I can also replicate the reported behaviour in Chrome 131.0.6. For completeness, this is what I observed:
I search for "berl" which displays options Berlin and Uberlândia. I choose Berlin and the options are hidden.
I click the select element again — the previously displayed options are shown again but the keyboard is not shown. A click event is sent to the LiveView with the following parameters %{"value" => "Berlin"}.
However, I noticed that if I click the select element a second time the keyboard does show up then. Again, a click event is sent, this time the parameters send an empty value; e.g: %{"value" => ""}.
This issue only happens in single mode, because we are making the text input readonly after selection (to prevent the user from continuing to type in the input field). I suppressed this behavior, and the keyboard should be showing now (tested on Chrome on Android)
Can someone please check out the latest main and see if it works for them, too? Testing on a mobile Safari would be particulary helpful. Thanks!
I just checked on the same Android device I previously mentioned @maxmarcon and it appears to be working well.
Following the same steps as above, I can select an option and it is chosen. When I click the input element again, I am shown the filtered list of options that I expect. In that scenario, the keyboard does not disappear at any point.
Or, if I blur away from the element (clicking elsewhere the body etc.) and then return focus to the input element, I observe the same behaviour. In this scenario, the keyboard disappears on blur but pops right back when focusing on the input element as well.
I'd consider the behaviour in both cases to be what I expect and both feel pretty natural. Considering the first scenario in particular, let's say a user filters down to a subset of options but then chooses the wrong one by accident — it's better UX (imho) to keep focus in this case because the user's attention remains with the element. They click again, make the correct choice, and done.
Actually, I didn't really zero in before on the fact that selecting a single option used to force the keyboard to close, and if memory serves lose focus on the element as well — I realise in retrospect I found this a bit jarring. I much prefer this new behaviour!