.focus() doesn't work on chrome mobile when not activated with click. Workaround?

Question

I've come across some strange functionality on chrome, mobile.

When I try to focus on an element on chrome, it doesn't work when you try to just load the input, getItById and do .focus(). However, if you wrap it in an event listener attached to a button, and click the button with your mouse, it works fine.

So, I tried to trick it by seeing if you could call btn.click(), but that doesn't activate the .focus()

Have a go below: On mobile, chrome (at least for iOS), load the page. You should get an alert 'Clicked', but it won't focus on the input. Then, try clicking on the button. You will get both the alert AND the focus works.

I found this interesting and wanted to see if people knew of a workaround.

Link here - jsfiddle

const btn = document.getElementById('button')

btn.addEventListener('click', () => {
  alert('clicked')
  const input = document.getElementById('input')
  input.focus()
})

btn.click()

<input id="input" type="text">
<button id="button">Button</button>

Edit

Another thing I've noticed, is that if you put your phone go to sleep, and open it again, the focus() works without the click.

Edit 2 - added link for mobile

Answer 1

Why does this happen?

Because mobile devices usually need to change the screen dimensions when a keyboard is shown, they come with some restrictions on when a focus event can be triggered. This is intentionally limited browser behavior on touch devices to guarantee a good UX and avoid performance issues of resizing the browser window ( = potentially very expensive style recalculation).

There's some cross browser differences in how far these restrictions go, and some browsers have bugs on top of that.

But in general they all require an actual user interaction to have happened not too long before the focus is programmatically triggered. Using btn.click() is not the same as an actual touch event, and so the browser will ignore it seeing there was no recent touch event.

On a tracking issue on this behavior for Webkit, Apple provides a motivation:

We (Apple) like the current behavior and do not want programmatic focus to bring up the keyboard when you do not have a hardware keyboard attached and the programmatic focus was not invoked in response to a user gesture. Why you may ask...because auto bringing up the software keyboard can be seen as annoying and a distraction to a user (not for your customers, but for everyone not using your app) given that:

1. We bring up the keyboard, which takes up valuable real estate on screen.
2. When we intent to bring up the software keyboard we zoom and scroll the page to give a pleasing input experience (or at least we hope it is pleasing; file bugs if not).

This similar issue with the autoplay attribute, which also requires a gesture (or page load) to have happened recently enough, could be helpful in understanding the kind of problem.

How to work around these limitations?

Most of the time

Likely you don't need to, as most code that would trigger focus is running as a response to a user action and will be allowed to trigger focus. I didn't find data yet on how big the window of time is, but I guess it's big enough that in regular cases it's not a problem (unless you set timeouts of course).

A possible problem for those cases is the script would run so long that the event is already considered too long ago. In fact that's what happened in the related autoplay issue, where the code would request some network resource, and only after the response would trigger the video to play. Depending on the speed of the network/device the video would sometimes auto play, and sometimes not.

Technically the same could happen with an input that is only focused after a network delay making it not show the keyboard. As long as your code doesn't do any network requests you won't have this kind of problem.

On page load

This is definitely not a "fix" for the problem, but you can do a best effort to manage focus on page load by using the attribute specifically made for it. This still won't make a keyboard appear when it otherwise wouldn't.

The autofocus attribute is at least partially supported on all browsers.

Perhaps just calling focus() directly in a script on page load works, but again there's a chance that this code runs too long after the page started being displayed, especially on slower devices. This probably also happens when adding HTML with the autofocus attribute programmatically (e.g. React). If the initial HTML contains the autofocus attribute on the right element that shouldn't occur.

Answer 2

There is deinfitely something weird happening here.

It seems "part" of the DOM thinks that the input element is in focus initially, but chrome does not complete the focusing. For exmaple, if the background is set with:

document.activeElement.style.backgroundColor = "pink";

Then the input element's background is pink. So, some part of chrome's DOM thinks the input element is in focus.

Initially, in my case, the input element is rendered by chrome in its default non-focus styling.

The alert() seems to be interfering with the process. In my case, taking the alert out had the effect of changing the styling of the input element from non-focus styling to in-focus styling, but the cursor did not appear in the input element, nor did the pop up keyboard appear.

By:

• removing the alert
• wrapping the click inside a function
• calling that function on load

fixed the problem in my case. Initially now the element is in-focus styled, the cursor appears in the element's box, and the keyboard pops up.

The solution to the posting by @HJo, January 2019, is to replace:

btn.click();

with:

function load() { btn.click(); }

remove the alert(),

and make the body tag as:

<body onload="load()">

@Peter. If this does not fix your problem too, can you please provide minimal code for your context.

Answer 3

const event = new Event('tap');
   const btn = document.getElementById('button')
   const input = document.getElementById('input')

    btn.addEventListener('click', () => {
      prompt('clicked')
      input.focus();
    })
    window.onload = function(){
      btn.dispatchEvent(event);
    }
}

The code above works when the website tab is just opened, but not on reload for some reason. I tested it on an Ipad and Iphone so hopefully it works well on your end too.

Here's a link to a repl: https://r.hackinggo306.repl.co

Edit: This seems to be the closest I can get, but also acknowledge the fact that mobile devices might be deliberately preventing this. (It would be annoying if a website looped this.)

Answer 4

On the mobile, you will need to use touchstart event instead of click event.
You can find it here. Hope this helps.

Answer 5

I think, this problem can occur, because of the your JavaScript script is executed before the DOM is Mounted. so you can do different things, One Thing add defer keyword to script tag. Basically it does is, that script is only run after the DOM is mounted. See

Second Thing

Wrap window.onload event with your input focus functionality.

 <script type="text/javascript">
    window.onload = function () { 
const btn = document.getElementById('button');
 const input = document.getElementById('input')
  input.focus()
 
    }
</script>

window.onload event is only fired when the DOM is finishing mounting.so that may be your JavaScript script run before the input element is mounting.so add onload event to your code.see this