Opera Mobile 9.7 Beta Set Focus [duplicate] - javascript

This question already has an answer here:
Scan inputs with Opera Mobile 10
(1 answer)
Closed 3 years ago.
We use a handheld scanner to move items in and out of inventory. The scanner runs an ASP page that submits the form to move the item. We recently purchased a new scanner running Windows Mobile 6.1 and soon realized that Mobile IE is completely useless. It does not render tables correctly and worse, it doesn't recognize onblur, onkeypress and many other common javascript functions.
We tested out many mobile browsers and found that Opera Mobile 9.7 works great except for setting the focus on an input text field when the page loads. The page has many text fields that and submits the form back to itself for processing. Once one field is scanned (or entered on the keyboard), the form submits itself, process the input and enables the next field on the form. At the end of the markup, select() and focus() are called to select any text in the field and to set focus so all the user has to do is scan the value. Here is what the javascript looks like at the end of the page.
document.forms["frm1"].elements["txt1"].select();
document.forms["frm1"].elements["txt1"].focus();
Is there any way to set focus on Opera Mobile 9.7?

You can use autofocus for the input field in Opera 9.7 like this:
<input type="text" autofocus />
However, that only seems to work on the first load, after submitting the form the field loses focus again. Please let me know if you find a solution.

Related

Auto Focus Form Element on iPhone/iPad

I'm trying to create a web application that automatically focuses the text input box upon page load.
However, I know that the 'autofocus' attribute isn't supported in mobile safari. The reason I need it to autofocus is because I am developing a web application so to say, and it basically requires the user to use their bluetooth scanner to send input to a PHP page that then POSTs that data (and hence, leaves the page briefly). Upon return, I wish for the box to be focused again, ready for the next scan. And as you may have guessed, my client wishes to use an iPad/iPhone.
The input is essentially just a keyboard wedge, a series of keyboard strokes will be sent wherever the focus is.
I've tried using the JavaScript and jQuery code below to no avail;
$( document ).ready(function() {
$( "#scan-input" ).focus();
});
Didn't work. And;
function formfocus() {
document.getElementById('scan-input').focus();
}
window.onload = formfocus;
Didn't work either when placed at the bottom of the page(s).
I've tried searching for this problem and found;
How can you autofocus on a form field in iPhone Safari?
But there wasn't any helpful information returned either.
Now when I use the JavaScript and jQuery code posted above, it does infact work on my web browsers but again, not on the iPad or iPhone (I'm using an iPhone for testing with an incognito window each time to clear cache as a precaution).
Does anyone know a way to force the focus to a text input box on iPad/iPhone?
For usability reasons all the focus() functions are ignored by Safari in iPhone/iPad for usability reasons
Quora

Focus on input in iOS8 Makes the whole page jump

I have two problems that happen only in iOS 8:
I have a login form which includes two inputs for username and password. In iOS 8 Safari, when I move from input to input, the page jumps in a weird way. I found a post that describes exactly the same thing: https://github.com/driftyco/ionic/issues/2256
After focusing a text input by clicking on it, the window closes itself. And that's the more serious problem. Is there a way to solve it with only JavaScript/jQuery?

in iOS8 using .focus() will show virtual keyboard and scroll page after touch

Prior to iOS8, using the Javascript .focus() method on an input element would appear to have no effect (the virtual keyboard would not display). After the latest iOS 8 release, running the .focus() method seemed to have no effect on page load but once a user touched anywhere on the screen the virtual keyboard would instantly appear and scroll the page to the element in focus. (This is also an issue when I use the HTML attribute "autofocus")
This change has caused issues with iOS8 users on my site. When a user attempts to click a button on my page the sudden scroll and keyboard appearance causes them to unintentionally click a button that was lower on the screen.
I am assuming this is a bug in iOS8 and was not intentional feature, my question is what is the most efficient solution to fixing this problem?
Do I have to check navigator.userAgent to see if the device is iOS8, every time I use the .focus() method?
It looks like you're definitely hitting an iOS 8 bug. In iOS7, Safari would (apparently) ignore or keep unfocused elements that had focus set prior to page load. This includes both <input autofocus> and input.focus() that occur up to some point, possibly page load (I tested just with an inline script).
In iOS 8, Safari is now apparently remembering that the element was focussed but not actually focussing it until a touch down event. It is then blindly sending a click event to whichever element received the touch up.
Both browsers behave the same for input.focus() occurring after page load. They both zoom to the element and bring up the keyboard.
Tests:
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 good news is that you only need to be worried about new behavior on elements you want to prefocus. The other good news is that while you will have to use a user-agent workaround, you can use it for all iOS versions since they were already behaving like you weren't autofocusing:
if (!/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
element.focus();
}
This appears to be the approach http://www.google.com uses 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, possibly doing extra detection for presence of software keyboard.
If you haven't, you should go ahead and file a radar with Apple at https://bugreport.apple.com.
If you are developing a Cordova project, you can fix it adding this line
<preference name="KeyboardDisplayRequiresUserAction" value="false" />
to your config.xml file. Tested in IOS 8.3 and IOS 8.4
It seems that in iOS 8 there has been an API change on the default handling for the javascript focus() command. If your application is a hybrid app in which you have direct control over Apple's web view facade the below is directly from apples docs.
A Boolean value indicating whether web content can programmatically
display the keyboard.
[myWebView setKeyboardDisplayRequiresUserAction:YES];
When this property is set to YES, the user must explicitly tap the
elements in the web view to display the keyboard (or other relevant
input view) for that element. When set to NO, a focus event on an
element causes the input view to be displayed and associated with that
element automatically.
The default value for this property is YES.
From the last paragraph it seems this method call is not strictly for the keyboard. It indicates that it is for input views across the board i.e. drop down and date picker etc.
It seems though there is a bug as this method call is not currently working for me. The current behavior I am receiving corresponds as if it defaults to NO.
I have a solution:
Disable all inputs
Enable the input you wish to focus
Set the focus to that input
Re-enable all the other inputs
Here's a conditional monkeypatch for jQuery.focus so you don't need to add the userAgent test everywhere.
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)
Note: I'm returning arguments[0] so we don't break method chaining such as $(el).focus().doSomethingElse()
I've logged a bug about this into the Apple Bug Reporter and they closed it as duplicate, which is a sign they are working on fixing this. Unfortunately they didn't give me some more information about the duplicate item or about the problem itself. I can only see the duplicate item state, which is Open.
For anyone coming to this on 2018, there is a plugin that fix it. Just install this https://github.com/onderceylan/cordova-plugin-wkwebview-inputfocusfix and input.focus() will work automatically without any additional work.

Google chrome's tabbing behavior

I have a simple web form which is having four input text fields.
Assume I have currently focused on 2nd text field and now I'm moving out from it and clicking on an empty area of the window (so now the focus will not be there).
If I press the tab key now, then apparently it should move to the 3rd text field. This happens in firefox, IE and even in Chrome 27 when I checked. But in Chrome 33 and latest Chrome versions focus goes to 1st text field**.
Is this the default behavior of Chrome latest versions? Are there any possibilities to avoid this and get the same behavior of IE and firefox for tabbing feature?
Note: You can test this scenario using gmail's login page form.

Return key in IOS/android + phonegap/cordova framework

I am creating an app in IOS/android with phonegap/cordova framework. I have a set of input types like input boxes, picklists, etc. How can I set the return key to work such that it focuses on the next input box when pressed. I have tried to use javascript in phonegap like:
document.getElementByid('nextElement').focus();
on return/enter; But it does'nt seem to be working ie. focus is lost from the current element but the soft keyboard is vanishing and focus is not coming to the next element. Any idea of where am i missing?
After some googling, it turns out this is not possible on Mobile Safari (although desktop WebKit works).
You can set focus on next element, but soft keyboard won't appear at all.
Here's the PoC of this: http://www.hakoniemi.net/labs/focusOnNext/

Categories

Resources