By utilizing .focus() in iOS8, the virtual keyboard will be displayed and the page will automatically scroll upon touch

Question

By utilizing .focus() in iOS8, the virtual keyboard will be displayed and the page will automatically scroll upon touch

In the era before iOS8, when utilizing the Javascript .focus() method on an input element, it seemed as though nothing happened - the virtual keyboard did not make an appearance. However, with the latest iOS 8 update, executing the .focus() method initially seemed ineffective upon page load. Nevertheless, once a user tapped anywhere on the screen, the virtual keyboard would promptly pop up and scroll the page to the focused element. This predicament also occurred when employing the HTML attribute "autofocus."

This alteration has led to complications for iOS8 users visiting my website. When attempting to click a button, the abrupt scrolling and sudden keyboard presence often causes them to accidentally tap a button located further down the screen.

I presume that this is a flaw in iOS8 rather than an intentional feature. Therefore, my query is: what is the most efficient solution to rectify this issue?

Must I consistently check navigator.userAgent to determine if the device is running iOS8 whenever I utilize the .focus() method?

javascript ios uikeyboard autofocus

Answer 1

Answer №1

It seems like you've encountered a bug specific to iOS 8. In iOS7, Safari would overlook or leave elements unfocused that were set with focus before the page loaded. This includes both <input autofocus> and input.focus() functions that occur prior to a certain point, possibly during page load (I tested this with an inline script).

In iOS 8, Safari now remembers that the element was focused but doesn't actually focus on it until a touch down event occurs. It then blindly sends a click event to whichever element received the touch up.

Both browsers behave identically for input.focus() executed after page load. They both zoom to the element and bring up the keyboard.

Testing:

input.focus() before page load: http://fiddle.jshell.net/qo6ctnLz/3/show/
<input autofocus>: http://fiddle.jshell.net/qo6ctnLz/4/show/
input.focus() after page load: http://fiddle.jshell.net/qo6ctnLz/6/show/

The positive news is that you only need to be concerned about new behavior on elements you wish to prefocus. Additionally, while you may need to implement a user-agent workaround, you can use it for all iOS versions since they were already behaving as if autofocusing wasn't enabled:

if (!/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
    element.focus();
}

This seems to be the approach used by http://www.google.com based on some basic user-agent testing:

Mac Book Pro: autofocus before page load.
iPhone: no autofocus
iPad: no autofocus
Kit Kat (Android): focus after page load, potentially conducting extra detection for the presence of a software keyboard.

If you haven't already, it's recommended to submit a radar report to Apple at .

Answer 2

It seems like you've encountered a bug specific to iOS 8. In iOS7, Safari would overlook or leave elements unfocused that were set with focus before the page loaded. This includes both <input autofocus> and input.focus() functions that occur prior to a certain point, possibly during page load (I tested this with an inline script).

In iOS 8, Safari now remembers that the element was focused but doesn't actually focus on it until a touch down event occurs. It then blindly sends a click event to whichever element received the touch up.

Both browsers behave identically for input.focus() executed after page load. They both zoom to the element and bring up the keyboard.

Testing:

input.focus() before page load: http://fiddle.jshell.net/qo6ctnLz/3/show/
<input autofocus>: http://fiddle.jshell.net/qo6ctnLz/4/show/
input.focus() after page load: http://fiddle.jshell.net/qo6ctnLz/6/show/

The positive news is that you only need to be concerned about new behavior on elements you wish to prefocus. Additionally, while you may need to implement a user-agent workaround, you can use it for all iOS versions since they were already behaving as if autofocusing wasn't enabled:

if (!/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
    element.focus();
}

This seems to be the approach used by http://www.google.com based on some basic user-agent testing:

Mac Book Pro: autofocus before page load.
iPhone: no autofocus
iPad: no autofocus
Kit Kat (Android): focus after page load, potentially conducting extra detection for the presence of a software keyboard.

If you haven't already, it's recommended to submit a radar report to Apple at .

Answer 3

Answer №2

For those working on a Cordova project, the solution is as simple as inserting the following line:

<preference name="KeyboardDisplayRequiresUserAction" value="false" />

into your config.xml document. This method has been successfully tested on IOS 8.3 and IOS 8.4.

Answer 4

For those working on a Cordova project, the solution is as simple as inserting the following line:

<preference name="KeyboardDisplayRequiresUserAction" value="false" />

into your config.xml document. This method has been successfully tested on IOS 8.3 and IOS 8.4.

Answer 5

Answer №3

It appears that there has been an update in iOS 8 which has altered the way the javascript focus() command is handled by default. If you are working on a hybrid app where you have control over Apple's web view facade, the following information is taken directly from Apple's documentation.

A Boolean value that determines if web content can show the keyboard programmatically.

[myWebView setKeyboardDisplayRequiresUserAction:YES];

When this property is set to YES, the user must physically tap the elements in the web view to bring up the keyboard (or any other relevant input view) for that element. When set to NO, a focus event on an element will automatically display the input view associated with it.

The default value of this property is YES.

Based on the last paragraph, it seems like this method call is not just limited to the keyboard. It suggests that it applies to all input views such as drop-down menus and date pickers.

However, I have encountered a bug as this method call does not seem to be functioning correctly for me. The current behavior I am experiencing indicates that it defaults to NO instead.

Answer 6

It appears that there has been an update in iOS 8 which has altered the way the javascript focus() command is handled by default. If you are working on a hybrid app where you have control over Apple's web view facade, the following information is taken directly from Apple's documentation.

A Boolean value that determines if web content can show the keyboard programmatically.

[myWebView setKeyboardDisplayRequiresUserAction:YES];

When this property is set to YES, the user must physically tap the elements in the web view to bring up the keyboard (or any other relevant input view) for that element. When set to NO, a focus event on an element will automatically display the input view associated with it.

The default value of this property is YES.

Based on the last paragraph, it seems like this method call is not just limited to the keyboard. It suggests that it applies to all input views such as drop-down menus and date pickers.

However, I have encountered a bug as this method call does not seem to be functioning correctly for me. The current behavior I am experiencing indicates that it defaults to NO instead.

Answer 7

Answer №4

Here is the answer:

Turn off all input options
Activate the specific input you want to highlight
Direct focus towards that particular input
Switch on the rest of the input choices

Answer 8

Here is the answer:

Turn off all input options
Activate the specific input you want to highlight
Direct focus towards that particular input
Switch on the rest of the input choices

Answer 9

Answer №5

If you're tired of adding the userAgent test every time you use jQuery.focus, here's a handy conditional monkeypatch for it.

JavaScript

if (/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
  (function($) {
    return $.fn.focus = function() {
      return arguments[0];
    };
  })(jQuery);
}

CoffeeScript

if /iPad|iPhone|iPod/g.test navigator.userAgent
  (($) ->
    $.fn.focus = ->
      arguments[0]
  )(jQuery)

Keep in mind that I'm using arguments[0] to ensure method chaining like $(el).focus().doSomethingElse() still works smoothly.

Answer 10

If you're tired of adding the userAgent test every time you use jQuery.focus, here's a handy conditional monkeypatch for it.

JavaScript

if (/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
  (function($) {
    return $.fn.focus = function() {
      return arguments[0];
    };
  })(jQuery);
}

CoffeeScript

if /iPad|iPhone|iPod/g.test navigator.userAgent
  (($) ->
    $.fn.focus = ->
      arguments[0]
  )(jQuery)

Keep in mind that I'm using arguments[0] to ensure method chaining like $(el).focus().doSomethingElse() still works smoothly.

Answer 11

Answer №6

After reporting a bug through the Apple Bug Reporter, it was marked as a duplicate by their team. This suggests that they are actively addressing the issue. However, the lack of additional details on the duplicated item or the problem itself is somewhat frustrating. All I am able to observe is that the status of the duplicate item remains 'Open'.

Answer 12

After reporting a bug through the Apple Bug Reporter, it was marked as a duplicate by their team. This suggests that they are actively addressing the issue. However, the lack of additional details on the duplicated item or the problem itself is somewhat frustrating. All I am able to observe is that the status of the duplicate item remains 'Open'.

Answer 13

Answer №7

If you are reading this in 2018, a helpful plugin has been developed to address this issue. Simply download and install the https://github.com/onderceylan/cordova-plugin-wkwebview-inputfocusfix plugin, and you will find that input.focus() now functions automatically without any extra steps needed.

Answer 14

If you are reading this in 2018, a helpful plugin has been developed to address this issue. Simply download and install the https://github.com/onderceylan/cordova-plugin-wkwebview-inputfocusfix plugin, and you will find that input.focus() now functions automatically without any extra steps needed.

By utilizing .focus() in iOS8, the virtual keyboard will be displayed and the page will automatically scroll upon touch

Answer №1

Answer №2

Answer №3

Answer №4

Answer №5

JavaScript

CoffeeScript

Answer №6

Answer №7

Similar questions

Set the style of the mat-select element

Transferring Information Among Scenes in SpriteKit

Using Multiline Strings for Arguments

Expanding iframe elements

Restricting Meteor Publish to specific user (admin) for all collections

An AJAX request will only occur if there is an alert triggered on a particular computer

Is there a way to swap out multiple characters within a string when using ng-repeat in AngularJS?

Having trouble binding form data to a React component with the onChange() method?

Extract image file name and date information (day, month, year) from an HTML form using Angular

Error: The React styleguidist encountered a ReferenceError due to the absence of the defined

Exploring the TypeScript compiler API to read and make updates to objects is an interesting

Is there a method in React Native to include the "share" icon in my drawer instead of a button?

The process of eliminating body padding in Nuxt.js

Having trouble resolving "react-native-screens" from "node_modules eact-navigation-stacklibmoduleviewsStackViewStackViewCard.js"? Here's how to fix it

Using placeholder in number and range input in Angular.js to display a placeholder text instead of a value when the input is 0

Avoid mutating the prop directly and instead, utilize a data or computed property that is based on the value of the prop. The prop that is being mutated in this case is

Having trouble transferring files to an unfamiliar directory using Node.js?

Ways to display spinner animations during image loading on Next.js?

PHP/AJAX user action history manager

Deleting items from an array in ReactJS