Interestingly this doesn't happen on desktop Safari (even in detached mode). I wonder if this could be related to hover styles?

It would be great if it could be an option exposed to the developer who could then choose between the two behaviours

• By default: it focuses
• It doesn't focus, and the end-user need to click in the input

I don't think this needs an option, not focusing is simply a bug @seafoox

The input element does receive focus (notice the purple outline which comes from a :focus style), what we don't have is the keyboard popping up.

This is probably related to the fact that iPhones don't let you programmatically assign focus (at least that was the case in the past), just like they don't allow you to autoplay videos, etc. We can set focus if this is done within a user event callback (which is the case here and it works) but we can't open the keyboard, this only happens when the user deliberately taps the input (we can't even simulate it). As far as I know there's no way around it.

I guess this is a wontfix situation.

@FabienMotte might have found a dark magic way around it 🔥 will try it!

We've investigated this behavior and unfortunately, we can't work around it without introducing a hack. This hack forces us to change how we schedule DOM updates, which has unintended side-effects such as reopening the search modal on close when the query has been updated.

We'll close it for now, as this is intentional browser behavior and there's no clean, non-invasive way around it.

This is sad, but I understand why you don't want to fight the browser here... Would a better fix be to have the search box that a user sees on mobile that is actually a button right now, be the <input> that gets moved up at the top of detached mode? That way the user clicked an input and we're not trying to trick anyone.

I don't know if it's possible, and if it is, it's probably a bunch of work. As of right now the search feels kind of broken for mobile users since it requires that extra tap.

We did consider that approach, but it would require faking the input to look like a button, which likely is a nightmare for accessibility behaviour.

I definitely see what you mean with it feeling a little broken, but what we found is the best fix is showing some UI on empty query, either query suggestions or static content, which makes that screen more interactive, and also makes more sense not to immediately cover it up with the keyboard.

You can see a similar pattern in many mobile applications (twitter, reddit), where the search button goes to an explore page, which allows people to find that immediately, but also requires two taps to get to the actual search bar.

We might reconsider this in the future, but for the time being this resolution makes sense to us.

@Haroenv could we have a demo of how to work around this problem? 😃
I think it is useful for everyone because we all will have this problem in iOS anyway.

Has there been a change? Or is it still this way

@amirhega the problem isn't solved yet.

With all due respect to the maintainers' decision, I disagree with this being closed with "wontfix". In our use case, the majority of users are using mobile and the majority of those iOS devices, resulting in a poor user experience for at least half of our users. In fact this is even broken on Algolia's own website.

This is probably related to the fact that iPhones don't let you programmatically assign focus (at least that was the case in the past), just like they don't allow you to autoplay videos, etc. We can set focus if this is done within a user event callback (which is the case here and it works) but we can't open the keyboard, this only happens when the user deliberately taps the input (we can't even simulate it). As far as I know there's no way around it.

iOS Safari does allow programmatic focus() including activating the on-screen keyboard, as long as the focus call is a result of a user interaction. Which appears to be the case when opening the detached panel by clicking on the fake search input (which is a button) with one catch.

However, the code calling focus() is wrapped in requestAnimationFrame, which - in my theory - makes the focus() call look like not having been triggered by a user interaction. Whether this is a bug or a feature in Safari is another question - I have not found any authoritative documentation on this matter, only dozens of StackOverflow threads. (The fact that the bug does not occur in iOS simulator suggests that this is rather a bug in iOS Safari.)

I've tried removing requestAnimationFrame to prove this theory, and it indeed fixed the issue on iOS. It is not obvious to me what purpose requestAnimationFrame serves. Removing it does not break any tests, and things seem to keep working (briefly tested on iOS Safari and various desktop browsers). The code including requestAnimationFrame was added in 1239b63 by @francoischalifour, maybe he can explain?

For the impatient, I've published my fork on npm: https://www.npmjs.com/package/@salomvary/autocomplete-js

I believe the requestAnimationFrame was to ensure the panel exists and is ready to be shown, however that may not be required as you show in your fork. Are you interested in making a pull request to backport your change? It looks useful to me, this is indeed a recurring problem that we hadn't found a solution for.

Thanks a lot for your contribution already @salomvary

I just spoke with @francoischalifour and the initial reasoning was to slow down the setters a little so "other work on the page" can happen too. As fixing this bug is clearly more important, we should definitely remove the requestAnimationFrame.

Are you interested in making a pull request to backport your change? It looks useful to me, this is indeed a recurring problem that we hadn't found a solution for.

Here we go #1231

Thanks again @salomvary , the fix is now part of autocomplete v1.14.0.