We Keep Coding

.focus() doesn't work on chrome mobile when not activated with click. Workaround?

I've come across some strange functionality on chrome, mobile.
When I try to focus on an element on chrome, it doesn't work when you try to just load the input, getItById and do .focus(). However, if you wrap it in an event listener attached to a button, and click the button with your mouse, it works fine.
So, I tried to trick it by seeing if you could call btn.click(), but that doesn't activate the .focus()
Have a go below: On mobile, chrome (at least for iOS), load the page. You should get an alert 'Clicked', but it won't focus on the input. Then, try clicking on the button. You will get both the alert AND the focus works.
I found this interesting and wanted to see if people knew of a workaround.
Link here - jsfiddle
const btn = document.getElementById('button')
btn.addEventListener('click', () => {
alert('clicked')
const input = document.getElementById('input')
input.focus()
})
btn.click()
<input id="input" type="text">
<button id="button">Button</button>
Edit
Another thing I've noticed, is that if you put your phone go to sleep, and open it again, the focus() works without the click.
Edit 2 - added link for mobile

Why does this happen?
Because mobile devices usually need to change the screen dimensions when a keyboard is shown, they come with some restrictions on when a focus event can be triggered. This is intentionally limited browser behavior on touch devices to guarantee a good UX and avoid performance issues of resizing the browser window ( = potentially very expensive style recalculation).
There's some cross browser differences in how far these restrictions go, and some browsers have bugs on top of that.
But in general they all require an actual user interaction to have happened not too long before the focus is programmatically triggered. Using btn.click() is not the same as an actual touch event, and so the browser will ignore it seeing there was no recent touch event.
On a tracking issue on this behavior for Webkit, Apple provides a motivation:
We (Apple) like the current behavior and do not want programmatic focus to bring up the keyboard when you do not have a hardware keyboard attached and the programmatic focus was not invoked in response to a user gesture. Why you may ask...because auto bringing up the software keyboard can be seen as annoying and a distraction to a user (not for your customers, but for everyone not using your app) given that:
We bring up the keyboard, which takes up valuable real estate on screen.
When we intent to bring up the software keyboard we zoom and scroll the page to give a pleasing input experience (or at least we hope it is pleasing; file bugs if not).
This similar issue with the autoplay attribute, which also requires a gesture (or page load) to have happened recently enough, could be helpful in understanding the kind of problem.
How to work around these limitations?
Most of the time
Likely you don't need to, as most code that would trigger focus is running as a response to a user action and will be allowed to trigger focus. I didn't find data yet on how big the window of time is, but I guess it's big enough that in regular cases it's not a problem (unless you set timeouts of course).
A possible problem for those cases is the script would run so long that the event is already considered too long ago. In fact that's what happened in the related autoplay issue, where the code would request some network resource, and only after the response would trigger the video to play. Depending on the speed of the network/device the video would sometimes auto play, and sometimes not.
Technically the same could happen with an input that is only focused after a network delay making it not show the keyboard. As long as your code doesn't do any network requests you won't have this kind of problem.
On page load
This is definitely not a "fix" for the problem, but you can do a best effort to manage focus on page load by using the attribute specifically made for it. This still won't make a keyboard appear when it otherwise wouldn't.
The autofocus attribute is at least partially supported on all browsers.
Perhaps just calling focus() directly in a script on page load works, but again there's a chance that this code runs too long after the page started being displayed, especially on slower devices. This probably also happens when adding HTML with the autofocus attribute programmatically (e.g. React). If the initial HTML contains the autofocus attribute on the right element that shouldn't occur.

There is deinfitely something weird happening here.
It seems "part" of the DOM thinks that the input element is in focus initially, but chrome does not complete the focusing. For exmaple, if the background is set with:
document.activeElement.style.backgroundColor = "pink";
Then the input element's background is pink. So, some part of chrome's DOM thinks the input element is in focus.
Initially, in my case, the input element is rendered by chrome in its default non-focus styling.
The alert() seems to be interfering with the process. In my case, taking the alert out had the effect of changing the styling of the input element from non-focus styling to in-focus styling, but the cursor did not appear in the input element, nor did the pop up keyboard appear.
By:
removing the alert
wrapping the click inside a function
calling that function on load
fixed the problem in my case. Initially now the element is in-focus styled, the cursor appears in the element's box, and the keyboard pops up.
The solution to the posting by #HJo, January 2019, is to replace:
btn.click();
with:
function load() { btn.click(); }
remove the alert(),
and make the body tag as:
<body onload="load()">
#Peter. If this does not fix your problem too, can you please provide minimal code for your context.

const event = new Event('tap');
const btn = document.getElementById('button')
const input = document.getElementById('input')
btn.addEventListener('click', () => {
prompt('clicked')
input.focus();
})
window.onload = function(){
btn.dispatchEvent(event);
}
}
The code above works when the website tab is just opened, but not on reload for some reason. I tested it on an Ipad and Iphone so hopefully it works well on your end too.
Here's a link to a repl:
https://r.hackinggo306.repl.co
Edit: This seems to be the closest I can get, but also acknowledge the fact that mobile devices might be deliberately preventing this. (It would be annoying if a website looped this.)

On the mobile, you will need to use touchstart event instead of click event.
You can find it here. Hope this helps.

I think, this problem can occur, because of the your JavaScript script is executed before the DOM is Mounted.
so you can do different things,
One Thing
add defer keyword to script tag. Basically it does is, that script is only run after the DOM is mounted. See
Second Thing
Wrap window.onload event with your input focus functionality.
<script type="text/javascript">
window.onload = function () {
const btn = document.getElementById('button');
const input = document.getElementById('input')
input.focus()
}
</script>
window.onload event is only fired when the DOM is finishing mounting.so that may be your JavaScript script run before the input element is mounting.so add onload event to your code.see this

browser back button single click into double click using javascript

I'm using id in every page to scroll the page to some fixed rate whenever the user is redirecting to another page in my website.
My problem is, user needs to double click the browser's back button to redirect the page to previous page, Thus I need to set double click the back button of a browser whenever the user made a single click the browser back button ..
Thank you

Short answer:
document.onmouseover = function() {
//User's mouse is inside the page.
window.innerDocClick = true;
}
document.onmouseleave = function() {
//User's mouse has left the page.
window.innerDocClick = false;
}
window.onhashchange = function() {
if (!window.innerDocClick) {
//Browser back button was clicked
window.history.go(-2);
}
}
Explanation:
The window.history object contains the URLs that the user has visited in the browser. The window.history.go(x) function is used to make the browser go to the relative page in history (so in this case -2 to go back 2 pages).
For detecting when the back button in the browser was pressed, I did a quick search and found the solution to this question here about "How to Detect Browser Back Button event - Cross Browser". The accepted answer has a very full and detailed approach to this which I used to get the above snippet, which you should definitely read.
A quick overview of what the above snippet does, is that it uses 2 events to detect whether the user's mouse is within the page document or not. If it is not in the page document, then this means that the user is not going to be clicking on any in-page elements such as hyperlinks etc. which could also be changing the URL. The 'onhashchange' event detects when the location hash changes, and then checks if the user's mouse is within the document, and if not then executes the double back button.
Please note: this method does not cover if the user presses the backspace key (or any other hotkey). The accepted answer does cover a method of doing this using jQuery, which looks as if it could be modified to work in vanilla JavaScript if jQuery is not wanted.
This method also probably does not cover devices such as iPads or other tablets and mobile devices as they do not have mouse events. Furthermore, swipe events on a mac's trackpad will most likely not be covered. Not having these devices, it is impossible for me to test them.

MSPointerDown event only fires on a long tap, not a quick tap

I'm editing the top nav of a site to work on IE10/Windows8 tablets like the Surface Pro. In the initial iteration, I just added aria-haspopup="true" to the hover elements and it worked pretty well -- one tap to show the hidden menu, a second tap shows the :hover effect, a third tap to navigate to the URL. But, the client wanted the second tap to navigate to the URL instead (you know, like it would work on pretty much ANY OTHER DEVICE other than a Windows one, lol), so I popped a JQuery script in there to hopefully just navigate to the destination like it's supposed to.
Here's the URL: http://www.urlgone.com/3a55ce/
I'm pretty close to having it work, but the weirdest thing is happening. If you tap the item, it goes into its hover state (white text) rather than clicking through. But if you hold your tap for a little bit longer, it works! What on earth is going on? This is my code:
$(document).ready(function(){
if (window.navigator.msPointerEnabled) {
$('#nav a').on("MSPointerDown", function(event){
window.location = $(this).attr('href');
return false;
})
}
});
The client has confirmed that it's doing this on his Surface tablet, and I'm surprisingly able to replicate the problem in a Virtual Windows 8 environment running Microsoft Windows Simulator.
Any ideas? I've been reading through the MS documentation here http://msdn.microsoft.com/en-us/library/ie/hh673557(v=vs.85).aspx but from what I understand, MSPointerDown is the umbrella event, and should cover any of the other gestured listed there -- MSGestureTap, MSGestureHold etc. I'm not even sure what I would console.log to find out the different between the ineffective "tap" and the effective "longer tap"...

Phonegap-(Android/iphone) Image gallery with multiple images is giving problems?

I have made an image gallery in HTML5, JavaScript and CSS by using jQuery mobile. IE Phonegap platform ok.
The images are coming dynamically and are loaded in it, like this:
http://torontographic.com/wordpress/mouseSwipe/mouseSwipe.html
Above mouseSwipe Slider:
TYPE: 'mouseSwipe'
HORIZ: true
plugin available at
torontographic.wordpress.com
The problem coming with it is that I cannot click on the image and go to next page, because two events are occurring together.
The second problem is that I cannot swipe the page up down, from the place where gallery is placed, except the other area where gallery is not present.
To make it more clear, I am making news application in which I have added 5 - 10 gallery like Pulse news application.

I'm a little confused about some of the details of the issue, but I hate to see this question go completely unanswered in case someone else has this issue.
This plugin (mouseSwipe) overrides the default dragging functionality for mobile devices. Whereas normally devices would scroll the page on the mouse starting event, this plugin overrides that behavior to detect click movement across an element. Since it interrupts that functionality, dragging the opposite direction (for scrolling) is also broken. If the plugin were still being maintained by the owner (it doesn't appear to be), it could be updated to fix this issue, or emit events that could be used to manually create the functionality you're wanting.
I assume this is also what is giving you trouble for clicking to go to the specified page.
If you want my honest opinion, I would choose a different library, perhaps one that focuses solely on the swipability of mobile devices, and then handle desktop functionality separately (though, if you're using PhoneGap, it's likely you aren't even publishing this to a web platform for desktops). If it's going to be on the web, you can use modernizr (or the like) to figure out if the device supports touch input, and then implement something like the following:
http://labs.rampinteractive.co.uk/touchSwipe/demos/Image_gallery_example.html
For devices that do not support touch, you could fall back to button/arrow-based navigation (after all, as a desktop user, I do not expect to be able to drag it back and forth with the mouse).

In the file http://torontographic.com/wordpress/mouseSwipe/jquery.mouseSwipe.js onmousedown function has the code below. This will stop the event from the default behaviour and in cases stop captured/bubbled. You may want to look at these or the way event are being handled by the libraries.
e.preventDefault()
Here is more on how to stop JQuery propagation and regular behaviour.
event.preventDefault() vs. return false
What is event bubbling and capturing?

The reason you cannot swipe up and down is likely due to that the "swipe" event is hogging the "movestart" or "move" event.
I ran into a similar problem once when using this plugin:
http://stephband.info/jquery.event.swipe/
Their solution as pointed on on their website was to call the preventDefault method on the event to keep it from blocking as seen here.
jQuery('.mydiv')
.on('movestart', function(e) {
// If the movestart is heading off in an upwards or downwards
// direction, prevent it so that the browser scrolls normally.
if ((e.distX > e.distY && e.distX < -e.distY) ||
(e.distX < e.distY && e.distX > -e.distY)) {
e.preventDefault();
}
});
I have no experience with jQuery mobile, but i would reckon the problems are similar.

Disabling middle click scrolling with javascript

Background: I am creating a table reminiscent of whenisgood.net, in that it has click-n-drag toggling for table elements. I want to call different types of toggling code when the left, middle, and right mouse buttons activate a mousedown event.
By using JQuery, I'm off to a good start.
$(".togglable").bind("contextmenu", function() {return false;});
$(".togglable").bind("mousedown", function(e){
e.preventDefault();
toggle(this, e);
});
In the toggle() function I can use e.which to determine what button was clicked.
The punchline: I used e.preventDefault() hoping that it would stop the middle click default behavior of scrolling. It didn't. What can I do to stop the scroll action from activating?
See also "Triggering onclick event using middle click"

Middle-click can be disabled with Javascript, but only in IE, WebKit, and Konquerer. Firefox requires a config file edit. It's 2017 and firefox 50 supports this.

This is an old question...but if I'm understanding it properly, you want to disable scrolling via the middle mouse button click.
Nowadays, you can do this with a single line of vanilla JS:
document.body.onmousedown = function(e) { if (e.button === 1) return false; }

Currently, my solution is this: (more jquery!)
$(".togglable").wrap(
"<a href='javascript:void(0);'
onclick='return false;'></a>"
);
By wrapping it in a link (via jquery wrap), browsers think it's a link and don't scroll on middle click, even if you drag your mouse around. With this setup, and my situation, there are a couple (minor) gotchas.
Firefox will open a new tab when you middle click, but only if you don't drag. Opera will open a new tab when you middle click, drag or not. That's why I used href='javascript:void(0);' instead of just href='#'--so that the client's browser wouldn't load a whole page, just a blank page with a strange url.
But this solution works like a charm on Chrome and Safari. It works well with IE8, except that now when I left-click-n-drag, it changes the pointer to a "can't do that" symbol, since it thinks I want to drag the link somewhere. Untested on older versions of IE.

It is a bit old thread already, but I've tried hard to circumvent this in Firefox (I'm still using 3.6) and I'll share my findings, maybe someone will find it helpful.
Check that if you create an empty HTML file (or a small document with couple of paragraphs) and load it in Firefox, middle click scrollbar does not appear. This is because <body>'s width and height are smaller than window size. If you put a lot of <br>'s, this is not the case and scrollbar appears on middle click.
Google managed to prevent middle click scroller to appear in Google Maps in Firefox by making sure (through JS) that <body> size is always less than window size, plus additionally putting
<body style="overflow:hidden;">.
This is hardly achievable in general case, but sometimes might be useful.