I am trying to use the <datalist> as an autocomplete populated via ajax. This works fine on desktop browsers including Safari. (There are some older posts on stackoverflow which indicate that Safari does not support the datalist, but current versions do.)
iOS Safari does not display the options by default and will only display once the user clicks the down arrow icon on the right of the input.
It is unintuitive to the user that there are options to choose from in the datalist and it is awkward that clicking the down arrow has the negative effect of closing the keyboard.
Is there a way to trigger the display of the list while the user is typing?
I ran across the same issue. To update a datalist in safari, you have to replace the datalist node completely. Safari otherwise does not seem to force a render update for the datalist. I wasn't able to trick Safari into updating it with a redraw.
From the solution provided Force DOM redraw/refresh on Chrome/Mac you can do this
document.getElementById('datalistID').replaceWith(document.getElementById('FirdatalistID').clone(true));
If you have events bound they will be lost. You have to attach your event listeners higher up in the node and then target the child. Such example is provided here Attach event to dynamic elements in javascript
However after this, Safari doesn't auto-open the data list. You have to manually expand the list. I haven't found a workaround for that.
Related
I am trying to add an EventListener on the body tag, which works fine on Chrome, but not on Internet Explorer (Edge). See code below. However, it works in IE, but only after I select an input textbox. But I don't want to select an input textbox first, the EventListener should listen immediately after I load the page.. What am I doing wrong here?
document.getElementsByTagName('body')[0].addEventListener('paste', function() {
console.log('hi');
});
This is a known limitation of Internet Explorer. It:
Only fires copy event on a valid selection and only cut and paste in focused editable fields.
You are doing nothing wrong.
Since you haven't focused an element (e.g. with autofocus), no editable field will have the focus just after the document has loaded.
Keep in mind that IE11 is not a browser under active development. It continues to exist primarily for compatibility with ancient Intranet applications. Not with modern web applications.
I have a page with a form that built with react and on the inputs, while the user start to write something, the autocomplete open but if the user scrolling up/down the autocomplete stay at the position that it open (Like a fixed position).
**
I can't inspect this of course...
This happens on all browsers (CH, FF, IE)
Any idea...?
All these auto complete are browser specific. It depends on browsers how they have styled and positioned their autocomplete. For some browser it is also possible to not have auto-complete feature. You can not changed it from your project you can disable them from your browsers if you want.
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.
I have a lightbox-like div which appears over pages to present scrollable content. In FF, IE, and Chrome, allowing the user to scroll the lightbox with the arrow and pagedown/up keys is as simple as assigning it a tabindex and calling .focus().
In Opera, .focus() does nothing and tab/arrow/page keys will continue acting on whatever tabstop elements are in the background page.
Here's a fiddle to illustrate the problem: http://jsfiddle.net/9W943/5/
I have seen many examples of how to focus a div, but none seem to acknowledge that the tabindex approach doesn't work in Opera. Is there any way I can force Opera to focus the lightbox? Failing that, what's the best workaround - listen for key events and then "manually" scroll the lightbox? (Or can I redirect the events?)
I have tried calling .click() on the lightbox, and creating+dispatching a fake click event - since keyboard scrolling works correctly after you click it - but neither worked.
Also I am very curious why it's not standard for non-input elements to be focusable, since they can and do receive keyboard events! How do you define a focused element, if not as the element which can be interacted with via the keyboard?
This is a known bug (internally DSK-269802) - unfortunately there is no nice workarounds that I know of :-/
I ran into this problem yesterday myself and will give the bug a "bump" - perhaps we can fit it into some on-going development work. I'd recommend that you ignore the bug and just code as if it worked in Opera, because some day it will.
I'm writing an iPhone web app, and I want to automatically focus a text field when the page is loaded, bringing up the keyboard. The usual Javascript:
input.focus();
doesn't seem to be working. Any ideas?
It will only show the keyboard if you fire focus from a click event, so put a button on the page with a onclick that does the focus and it will show the keyboard. Completely useless except for validation (on click of submit validation code focuses on invalid element)
Edit: The following no longer works on iOS - UIWebView did allow autofocus and home screen links used to autofocus but they disabled that many versions ago.
The autofocus (see below) property doesn't work from a url in Mobile Safari but does work if you are:
using a UIWebView
using a home screen link
The fontsize of the input needs to be large enough to avoid the iOS10 zoom on double-tap (now that viewport is always zoomable) and to design the page to be sized so that it fits the screen (otherwise on page loading you get strange timing/race bugs in zoom, or if scrollable the field sometimes doesn't center to the screen properly).
autofocus: The HTML5 spec for doing this is the autofocus property of the input tag. But iOS ignores that, presumably for a cleaner UI that doesn't pop up the touch keyboard when navigating to a page. Here is a page that demonstrates the autofocus property. Before HTML5 you would call element.focus() in the window.onload event. However focus() calls are not supported on iOS except during the handler of an onclick event.
Note: this answer is old and may not be relevant to newer versions out there...
It comes as no help to you but the last poster in this thread wrote that its a bug of the webkit engine.
I can't tell if its a verified bug or not...
Last post from way back machine (as original seems to not work):
I am developing my app in pure XHTML MP / Ecmascript MP / WCSS. So
using native platform browser control api is really not an option for
me. Yes the behaviour u mention is the same as mine. I searched his
topic in the bugzilla at webkit.org and found that this indeed is a
reported bug. focus() to a text box does highlight the element but
does not provide a carat in it for the user to start entering text.
Using a timer as mentioned by "peppe#peppe.net" does not help either.
This behaviour is common across platforms (s60,iphone,android) which
use the webkit engine.
So as of now i dont see a solution to this problem.
Hope this helps
I have a similar issue, only my issue is that the focus will not occur on a 'touchend' event.
http://jsfiddle.net/milosdakic/FNVm5/
The following code will work in Chrome/Safari etc. but will fail on Mobile Safari. The only way to get it to work is to make the event on 'click', but seeing as the code is made for an iOS device, it would benefit for it to work with touch events.
It seems to be a bug with the Webkit engine.
If you are setting focus with from a click event, you need to preventDefault otherwise the click events default action will set focus on the clicked item.
A bit late maybe but for future person maybe. In our webapp running on iOS iPad (6 and more recent), we do it with a set interval:
startFocusOnTextField: function() {
this.intervalIDForTextFieldFocus = window.setInterval(function() {
document.getElementById(page.textInputFieldObj.id).focus();
}, 150);
},
Which is called on page load (jQuery mobile environment)
This is a workround:
setTimeout(function(){
input.focus();
},500);//milliseconds