I am developing a WebApp and want to create a kind of login screen with html. For this I have four input fields, which focus on the next field after a number has been typed in.
In osX safari this works without any problems. Unlike iOS on my iPhone. Yoo-hoo.
The problem on mobile safari is that I don’t know how to automatically "jump" to the next input field programatically (set the focus programmately). The user can do it via a button (working fine), but is there a way to do this automatically?
See my code:
$('.text').on('input', function() {
$(this).next('input').focus()
});
.text {
margin: 5%;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<input type="text" class="text" />
<input type="text" class="text" />
<input type="text" class="text" />
<input type="text" class="text" />
The focus is working quite fine on webBrowsers like safari or chrome but not for iPhone iOS safari like to can see in this gif - The focus get's lost and the keyboard disappears:
What I've found during my research was e.g this question:
Programmatically focus on next input field in mobile safari
Mobile Safari: Javascript focus() method on inputfield only works with click?
But none of the answers did the job for me because whether they are not working / they are to jerky or they use a workaround that is not really working with my styles like http://jsfiddle.net/EbU6a/194/ did.
So any help how to fix this would be really appreciated. Thanks in advance!
Since I am pretty sure that someone will get this problem too, I decided to answer my own question.
So I've fixed the issue partly using this line of code:
myWebView.keyboardDisplayRequiresUserAction = false
I found the solution while reading the apple documentation for UIWebView.
Please see this reference.
I am affraid iOS does not allow you to focus programatically. You can try workaround from here
Related
Autofocus is, in theory, completely unsupported in mobile Safari (http://caniuse.com/#feat=autofocus). We're seeing, however, this very strange behaviour where when a touchstart event is bound to document (whether the function has any behaviour or not) when a click happens anywhere on the page the first input with autofocus becomes focused and the onscreen keyboard displays.
This can be reproduced using iOS 8 in the iOS simulator. Here is the minimal html and javascript to reproduce the problem:
<html>
<head>
<script>
document.addEventListener("touchstart", function() {});
</script>
</head>
<body>
<input type="text">
<input type="text" autofocus="autofocus">
</body>
</html>
And here's a jsfiddle: http://jsfiddle.net/qd858nob/
Simply click anywhere outside of the inputs, and the second input will become autofocused. Ideally I'd love to find a global solution that resolves this without having to remove autofocus from all of our input elements.
See in iOS8 using .focus() will show virtual keyboard and scroll page after touch for a broader discussion on this issue. It looks like it's an iOS 8 "bug". I've filed a report with Apple -- best you can do is the same and hope it bubbles high enough up on their list to fix soon.
On mobile devices using a custom keyboard it seems that it does not follow the rules set:
<input type="text" autocapitalize="off">
I assume this is a bug, I wonder if there is a JavaScript` solution to such a problem. But, if I used js to force lower case this is a rather bad user experiencing?
But how can I fix this? So that the user needs to click the shift button on their keyboard (mobile keyboard)
Seen here:
You can use a textarea width height: 22px (or more).
<textarea style="height: 22px" ...></textarea>
How can I trigger a select file dialog on iOS 6 for an input element in the DOM programatically? (i.e. using Javascript)
<input type="file" id="foo">
Notes:
Mobile Safari and Safari seems to behave differently. I've got it working using document.querySelector("input[type=file]").click() in safari.
If it's within a native clickhandler, i.e. initiated by the user, it seems to work, but I'd like to trigger the dialog on will.
After some more research it seems like this isn't possible. Least I haven't found a method that works.
I decided to solve this using an <input type='file'> positioned on top of the button, with opacity 0.01 to make the button visible.
we have an issue where a disabled form element (input, textarea, ...) does not react to a right-click action (oncontextmenu attribute). Everything works fine when the form element is enabled. Please consider the following pseudo-code:
<div id="test" oncontextmenu="someFunction()">
<input id="textbox" type="text" disabled="disabled">
SOME_PADDING
<input id="calendar" type="image" disabled="disabled">
</div>
The real catch is it does not work in Chrome and Firefox, but it does work in IE8 and Opera.
When we right-click on the textbox or calendar elements in Chrome or Firefox, nothing happens. If we click in between the elements (SOME_PADDING) then the right-click menu does appear.
Hence it seems as if a right-click action on a disabled form does not work in Chrome and Firefox. Has anyone experienced a similar behaviour before?
Thanks in advance!
Stijn
EDIT: As mentioned by Pekka, a disabled form element not reacting to a right-click does make sense. The real issue seems to be the oncontextmenu attribute of the div around it not reacting properly when clicking on a disabled form element in Firefox / Chrome.
EDIT2: Online example can be found here: http://jsbin.com/isite4/6 - This works in all but IE8. Any proposed work-arounds to force IE to behave normally?
Hmmmm, interesting. Never seen this before. It could be argued that it is not entirely wrong to hide the context menu, though. The W3C has the following to say about disabled controls:
Disabled controls do not receive focus.
Disabled controls are skipped in tabbing navigation.
Disabled controls cannot be successful.
and about receiving focus:
In an HTML document, an element must receive focus from the user in order to become active and perform its tasks.
So the behaviour shown by Chrome and FF kind of makes sense IMO.
Ideas for how to work around it:
Put a transparent element on top of the input element, and catch the event there (yuck)
Use z-index: -1 to put the disabled element behind the container - not sure whether this works across browsers though
Do not work with the disabled attribute, but use CSS styling and a jQuery workaround to prevent those controls' values from being submitted
The latter would be the best suggestion, I think.
We opted for a work-around, as their doesn't seem to be a straight-forward approach.
We decided to add an image over the disabled form element, that responds to a normal left-click.
There is a simpler way that I have used and that was to readonly the element instead of disabling it. If the 'look' might confuse your users, just match the "disabled" colours with css on the element. I know it is not relevant to the original poster but anyone else who comes looking might benefit.
I am working on getting my website to display nicely in IE7.
IE6 is already done, and also FF, Chrome, Safari, Opera etc...
I am running IE7 in IETester if that makes any difference.
I have a problem with an input type='file' in IE7. The button next to it (browse button) is very short with hardly any width at all. It is as if the button has a width set to 4px or something.
And on top of that, when I click the very small button, nothing happens. A browse window should appear, but nothing happens.
Here is the code:
<td height="30px" align="left" style="vertical-align:top;">
<input type="file" id="pic_1" name="pic_1">
</td>
I have tested setting the width of both td and the input, but no luck.
Does anybody know what the problem might be here?
Thanks
avoid IETester. Get a copy of expression web superpreview for IE. Its free.
Seems like the problem was with IETester.
I tested it on a different computer with IE7 and it works just fine.