I am working on a custom application for the iPad that runs as a homescreen app, but is made in all CSS/HTML/Javascript. (not using the SDK here)
I have run into an issue with a calculator I have built into my page not hiding the keyboard. No matter what I do, the keyboard stays up. I have searched this extensively and tried everything I can think of, but the keyboard stays up no matter what I do.
Explanation of what I have tried to hide the keyboard:
I have tried to blur all input fields to remove focus. I have tried setting focus onto non-text field items.
There were several threads on Stackoverflow from earlier this year/last year that suggested both of those options, but they do not appear to be working anymore.
To test further, I put a blank a href="#" on an img that was above the calculator, so that I could set focus on a non-entry and see if that would auto-minimize the keyboard. When I tap that item above the keyboard the focus changes and I am no longer in input mode, but the keyboard stays up.
Did Apple break this functionality with the latest update? If so, is there a work around?
Here is some example code that doesn't work:
$('input').blur(function(e) {
// Keyboard disappeared
window.scrollTo(0, 1);
});
That code successfully removes focus from the inputs, but the keyboard stays up. I have also attempted the inverse of that by just .focus ing on a non-text element. And additionally, as stated previously, I have straight-up just added a non-text element on the page and that still doesn't hide the keyboard.
Thanks so much for any help, and feel free to link/abuse me if I have mistakenly reposted. :)
you should be able to blur it just by using something like this
$('input').blur();
you should put this inside the function/procedure that happens when you want it to disappear, unless your looking to disable it completely?
document.activeElement.blur() inside a try catch block works for me. (Possibly you also need a setTimeout? I didn't need a timeout, and it is important to avoid timeouts wherever possible because they can easily cause nasty heisen-bugs!)
Also double check that you are not calling focus() somewhere within a mousedown or click event (which causes the keyboard to show). You can use a console.log(document.activeElement.tagName); or similar to help find what has current focus.
However if you don't find a solution then I am very interested in seeing how you get the keyboard to stay up... I have a use for that :-)
Related
I'm using the following jQuery plugin: http://willowsystems.github.io/jSignature/
I'm trying to do something very simple which is stopping page scrolling when the user's finger is inside a signature area (the page movement when writing a signature on the phone is excruciatingly bad to the point where you can't write your signature at all). I have tried the following which is not working in Firefox and I'm not sure why:
$('.signature').on('touchmove', function(e) {
e.preventDefault();
});
I have also tried this which isn't working either:
$(document).delegate('.signature', 'touchmove', false);
I've searched for hours and I can't seem to find anything that works. If anymore detail is required please let me know and I will happily append to the question.
Thank you very much for everyones help.
edit: I'm using the latest version of Firefox on the phone.
try to use the e.preventDefault() on the ontouchmove of the html element.
<div class="signature" ontouchmove="event.preventDefault();">
</div>
this example works for me:
http://jsbin.com/pulul/1/edit?html,css,output
Same problem in field on Android browser. Capturing signature gets dots instead of sig. So, testing in browser I see the focus is never lost from prior field when i click with mouse into jSignature. So, try something like this:
onblur="if(this.value.length>1) document.getElementById('CustomerSignature').focus()"
Welp, with that you'll see the onblur DOES NOT FIRE when you touch your jSignature but does fire when you touch your other fields. There ya go. Have not been able to reproduce the exact bug reported to me yet on the tablet; but I think the scroll is being sent to ANOTHER element.
So, fix is to force the focus to change to the jSignature. That's what I think.
For now, I fiddled around with the HTML so my last field is a select and use the onchange to set the focus to my jSig.
I've just reproduced the same error in tinyMCE fiddle.
here's the link : http://fiddle.tinymce.com/39daab
There are brief descriptions on the page...
following the steps will show you the error I run into...
I've been trying to solve this problem by my own, but I think I'm not able to.
I looked through tinyMCE documentation and bug report pages like a thousand of times,
but I couldn't get a hint for this.
It's really weird that IE can place focus, but can't cursor on input elements.
You can check the current focused element by selecting $('*:focus')...
focusing does work, but placing cursor doesn't.
Posting this in case it helps someone else who runs into this. I had a similar issue. It seems like IE9+ has a bug where if the focus is on a dom element that is removed, the focus event on other elements stops working.
In my case I was able to resolve it by doing an $('input').focus() before destroying the rich text editor (CKEditor).
Bug is outlined here:
Why can I sometimes not type into my <input> in IE?
and here:
http://bugs.jqueryui.com/ticket/9122
Another similar issue: on our web page we hide and show divs using a fast animation ( .slideDown(100) / .slideUp(100) ). The divs contain input boxes that randomly will fail to get focus on IE9, 10 and 11.
The input boxes show up, but the cursor doesn't change when you hover over them, nothing happens if you click on the input, it's like the input doesn't exist. Sometimes if you hit the tab key it will fix itself and you can focus and get a cursor in the input.
When we removed the animation, or increased the time (to e.g. .slideDown(500) ) it seemed like it started working - we couldn't reproduce the issue.
I reproduce the same problem with tinyMce 4.4.0 version.
window.focus() resolve the problem in iE11.
function closeTinyMce(){
tinymce.remove();
setTimeout(function(){
window.focus();
},10)
}
http://fiddle.tinymce.com/DWfaab/1
I have a really nasty problem with focus in Internet Explorer.
I have a textarea for inputting text. This textarea is not visible for the user and is only used to provide robust text input for a more advanced view.
As the textarea isn't visible and shouldn't be I use textarea.focus() in the JavaScript to activate text-input. This has worked fine until now where I get really weird results.
For the textinput I basically use this event plus an exact copy for onkeypress.
textarea.onkeyup = function (e) {
//textarea.value contains the full text
//Update the view with this value
};
The problem is that sometimes textarea.value is not updated. I can even see the button in e.keyCode on the keyup event above but the value isn't changed.
This seems to happen after I have clicked somewhere on the page, but this does not trigger a blur-event. I'm logging the onfocus- and onblur-events so I can see when the textarea loses focus but it doesn't. And i still receive the keyup/press/down events.
If I try to refocus the textarea with textarea.focus() the problem remains. A workaround I found though is to focus the window with window.focus() and right after call textarea.focus().
The problem with this is that focus is a really expensive operation in IE (no kidding) and since I cannot detect when this problem will happen I have to keep doing it with certain interval which seriously affects the performance of my application (involves animation etc).
I use the exact same code for other browsers and do not have this problem there.
Change the identifier to something less generic like "textAreaAdv", IE sometimes get confused with this word.
I have a series of select elements in a form on a mobile site. These select elements are inside a scrolling pane handled through JS and CSS3 transforms, so getting a touch/click/whatever event to register on the selects was enough of a pain in the first place. However, I'm now finding, on android only, that even though the selects are getting clicked, and are getting focus- they simply refuse to open. I'm 100% sure that the selects are getting their focus event (through debug), so honestly, I am completely stumped. Without the debug, there are no other focus/blur events on the selects. It works fine on iPhone... any ideas?
I've been banging my head against the wall with this same issue. It seems to be isolated to Android 2.1/2.2 (and maybe 2.0?). The selects work fine in Android 1.5/1.6. I even created a simple page that just changes the select's display style from none to block and the select still doesn't open consistently. Oddly, sometimes after page refresh it might work, then after another refresh it might be broken again. As you stated, focus and click/touch events do fire from the element, so I'm at a loss as to what the issue is.
Sometimes if I zoom the page I can get the select to open, but even then the value selected isn't represented in the select element on the page.
I submitted a bug report to the Android dev team, but even if it's fixed in future builds the problem will still exist in 2.1/2.2.
Anyone find a workaround for this yet?
//---- Update ------
If you use a webkit-transition to show/hide the element, attaching the following event to the element appears to fix the select inside of it:
.addEventListener("webkitTransitionEnd",function(e){
this.innerHTML = this.innerHTML;
},false);
I'm not entirely sure why this works, but re-writing the element to the DOM seems to help for some reason. Tested in Android 2.1/2.2 simulator, EVO4G and MyTouch.
I found the solution in this answer by a.meservy. Here is the answer, copied for everyone's convenience.
In this case the problem was actually caused by jQTouch. To fix it, just comment out these 4 lines in jqtouch.css
Under "body"
/*-webkit-perspective: 800;*/
/*-webkit-transform-style: preserve-3d;*/
Under "body > * "
/*-webkit-backface-visibility: hidden;*/
/*-webkit-transform: translate3d(0,0,0) rotate(0) scale(1);*/
I have the need to trigger the opening of the browser (IE, Firefox, Safari, etc) context-menu via javascript. The problem I am trying to solve, is when an overlaid element is right-clicked, the element below it shows its context menu. So if the top element is a label, when you right click, I need to show the context menu for the input element below.
I know how to keep the label's context menu from showing, but I don't know how to open a context menu arbitrarily.
Any help is appreciated!
Sorry to be the bearer of unfortunate news, but this is impossible to do with Javascript.
I don't want to frustrate you, quite the contrary, especially because you answered my own question :)
I don't think that a browser's contect menu is accessible via an ordinary script on a web page.
If what you are asking for was actually doable, then the browser makers would possibly consider this a bug and remove this behavior. Cross-browser, this behavior is very unlikely to be available today.
Why don't you capture mouse events, and whenever the mouse is directly in the area of the element below that you want to show the context menu for, push the covering element below, otherwise back on top?
That is one possiblity I could think of, basically revealing/exposing the hidden element depending on mouse position. Like cutting a hole into the overlay.
Or why don't you make the text field transparent and put the overlay below the text field entirely?
If this does not work out technically, then at least you have a point in filing bugs or enhancements against the targeted browsers.
BTW it looks like the context menu actually works if the user right-clicks directly at the position of the caret, so this might be another loophole for you to consider.
I have a possible solution that may suit your needs. It is not perfect yet, I have only done a few quick tests in a few browsers (Fox 3.6, IE7, IE8, Chrome 4, Safari 3 on xp) It will need to be tweaked and improved but its a start. Basically the idea is to remove the label on right-click mousedown so that the desired field is hit by the mouseup event and therefore fires up the context menu on the relevant field.
// Remove the contextmenu from "In-Field" Labels
base.$label.bind("contextmenu",function(e){
return false;
});
// Detect right click on "In-Field" label:
// hide label on mousedown so mouseup will target the field underneath.
base.$label.mousedown(function(e){
if ( e.which == 3 ){
var elLbl = $(this);
elLbl.hide();
var elFid = $(this).attr("for");
// bind blur event to replace the label when we are done.
$("#" + elFid ).bind("blur.infieldlabel",function(){
elLbl.show();
$("#" + elFid ).unbind("blur.infieldlabel");
});
return false;
}
});
The IE and Safari browsers experience a strange issue where you need to click in and out twice before the label will display again (something to do with event timing I think). You may be able to easily see why this is happening by looking at the code. Also noticed slight glitch sometimes in the fox after pasting into the field, on blur the label appeared for a split second when it should not. This should be a fairly simply thing to rectify if you decide to incorporate this method into your code.
You can make Your label/span element contenteditable="true" and handle any further actions with listeners. Making it contenteditable will enable normal, input-like contextmenu to show up on right click.
And if someone doesn't care for IE support:
pointer-events: none
Type the following in the console:
document.oncontextmenu = reEnable
That will print to the console the following:
reEnable()
{
return true;
}
Done, you can now use the context menu.