Hi,
I have an application with a text field that needs to be programmatically focused when its view is shown. This in turn brings up the virtual keyboard on mobile devices (as is expected whenever a text field is ever brought into focus).
This feature worked perfectly before the latest Kendo UI upgrade. Once upgraded, android no longer brings the keyboard into view. iOS does not even focus the text field.
I have created a test application to demonstrate the mechanism:
When calling the same function from a button, it works as expected. It seems that calling the event through the view's show event somehow suppresses default behaviours.
To further explore this issue, I wrapped the focus() call in a setTimout function. Seeing as the call from the button happens at a much later time then when the view's show event is fired, it may behave differently.
Unfortunately, this is also unable to focus the text field from the view's show event. In fact, doing this also makes the button's call no longer work. After doing some research, I found that Mobile Safari has a feature that limits multi-threading functionality (such as those created by setTimeout) for usability/secuirty reasons. Perhaps there is a threading issue with the view show event.
Hope this helps. Any help with a fix is greatly appreciated.
Thanks,
John
I have an application with a text field that needs to be programmatically focused when its view is shown. This in turn brings up the virtual keyboard on mobile devices (as is expected whenever a text field is ever brought into focus).
This feature worked perfectly before the latest Kendo UI upgrade. Once upgraded, android no longer brings the keyboard into view. iOS does not even focus the text field.
I have created a test application to demonstrate the mechanism:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<
html
xmlns
=
"http://www.w3.org/1999/xhtml"
>
<
head
>
<
title
>Text Field Autofocus</
title
>
<
link
href
=
"kendo.mobile.all.min.css"
rel
=
"stylesheet"
type
=
"text/css"
/>
<
script
src
=
"jquery-1.7.2.min.js"
type
=
"text/javascript"
></
script
>
<
script
src
=
"kendo.mobile.min.js"
type
=
"text/javascript"
></
script
>
</
head
>
<
body
>
<
div
id
=
"one"
data-role
=
"view"
>
<
div
class
=
"km-navbar"
data-role
=
"navbar"
>
Page 1
</
div
>
<
br
/>
<
span
>Click the button to be taken to the 2nd page</
span
>
<
br
/>
<
br
/>
<
a
class
=
"km-button"
href
=
"#two"
>Go To Page 2</
a
>
</
div
>
<
div
id
=
"two"
data-role
=
"view"
data-show
=
"focusTextbox"
> <!-- function call does not work here -->
<
div
class
=
"km-navbar"
data-role
=
"navbar"
>
<
a
class
=
"km-button km-back"
onclick
=
"javascript:history.go(-1)"
data-align
=
"left"
>Back</
a
>
<
input
id
=
"input"
type
=
"search"
data-align
=
"left"
placeholder
=
"Search Box"
/>
</
div
>
<
br
/>
<
span
>The text field should be programatically focused on the view's show event.</
span
><
br
/>
<
br
/>
<
button
onclick
=
"focusTextbox()"
>Manually Focus</
button
> <!-- calling from here works -->
</
div
>
</
body
>
<
script
type
=
"text/javascript"
>
var app = new kendo.mobile.Application($(document.body));
function focusTextbox() {
$("#input").focus();
}
</
script
>
</
html
>
When calling the same function from a button, it works as expected. It seems that calling the event through the view's show event somehow suppresses default behaviours.
To further explore this issue, I wrapped the focus() call in a setTimout function. Seeing as the call from the button happens at a much later time then when the view's show event is fired, it may behave differently.
setTimeout(function () {
$("#input").focus();
}, 500);
Unfortunately, this is also unable to focus the text field from the view's show event. In fact, doing this also makes the button's call no longer work. After doing some research, I found that Mobile Safari has a feature that limits multi-threading functionality (such as those created by setTimeout) for usability/secuirty reasons. Perhaps there is a threading issue with the view show event.
Hope this helps. Any help with a fix is greatly appreciated.
Thanks,
John