If press mouse button inside input element and drag out to the header before releasing in Chrome we will see header as click event target, but in Firefox we will see input field as event target. What the reason of this differences in event handling and how to implement Firefox behaviour in Chrome.
Also safari in this case doesn't dispatch event.
Interesting thing. This 'incorrect' behaviour can be reproduced in Chrome only if you start click event on input field and drag out to header. If you start from header and finish it on input field you will see expected event target (header).
Tried to do something with poitner-events and eventListener options, but no results.
I've created this simple example for checking this difference.
Here is example of layout where this case can be reproduced.
<div class="header" onclick="handleClick(event)">
<input type="text" class="input" onclick="handleClick(event)">
</div>
Related
See full code and play with it here: https://plnkr.co/edit/qJ7eiJewb0hmj8wF?open=lib%2Fscript.js&preview
Pseudo code:
<div parent focusable>
<iframe>
#document
<input textbox>
</iframe>
</div>
Click to focus to the textbox, then Shift+Tab
In Chrome: the focus is moved directly from the textbox to the parent
In Firefox: the focus is moved from the textbox to the iframe, you will have to Shift+Tab a second time to move the focus to the parent
Question: How to replicate the same behavior Shift+Tab of Chrome in Firefox?
I can replicate the behaviour of Tab of Chrome in Firefox but I'm unable to replicate the behaviour of Shift+Tab
because no focus event is fired when the focus moved to the iframe (in case of Shift+Tab).
Note: Paypal solved this problem in their payment forms:
https://codepen.io/braintree/pen/ZWPpPG
but I'm unable to find out where did they do the magic
I'm only adding a click event handler on my <button>.
document.getElementsByTagName("button")[0].addEventListener("click", event => {
event.preventDefault();
console.log("Click:", event);
});
<button>Press <kbd>Enter</kbd> on me</button>
(Demo link)
Nevertheless, when I tab to the button in Firefox, then press Enter, I see the click event being fired. However, I cannot see this behaviour documented anywhere. Is this standard behaviour, and can I count on it working in all browsers?
This is largely because lots of authors have historically written code using click events while forgetting to account for users who don't click (whether because they prefer to use a keyboard to navigate, have a disability which makes it hard to use a pointing device, or whatever other reason).
The behaviour is documented in the HTML specification:
Certain elements in HTML have an activation behavior, which means that the user can activate them. This triggers a sequence of events dependent on the activation mechanism, and normally culminating in a click event, as described below.
…
For accessibility, the keyboard’s Enter and Space keys are often used to trigger an element’s activation behavior.
It then goes on to explain the steps in detail.
Because for keyboard users (where a mouse is not available), when a button is in focus and you press Enter (possibly Space as well) it simulates a click event.
This is the browser's accessibility support which most, if not all, browsers provide.
This is documented in WCAG: SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons:
While onclick sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.
This is also stated in UIEVents /click section:
In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, as described in §3.5 Activation triggers and behavior.
The Activation trigggers paragraph states that:
User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus.
Which means that any of those triggers will dispatch the click event.
I've solved it by using div element with onClick listener instead. It seems that button element captures enter press for the accessibility purposes, like the guys above wrote.
I'm making a chat service, and I want to support mobile devices well.
On a screenshot below, there is an input field. It allows typing text, and to avoid issues like "if the text field is unfocused typing does nothing" it automatically gets focused when clicking outside of it - this does improve the experience on desktop computers. However, on devices with software keyboard, this causes on-screen keyboard to appear on mobile devices which is distracting.
Considering clicking anywhere focuses the text input, is it somehow possible to make on-screen keyboard only appear when the text field is pressed? Or alternatively, somehow detect devices with software keyboard enabled and disable this feature for them. Preferably without explicitly trying to detect mobile devices, touch screen or whatever as there exist touch screen devices with hardware keyboards.
This issue I was able to reproduce in Google Chrome and Opera Mobile on Android, and apparently it happens on iPhones, although I have no device to test it on.
Here is a rather simple example of an issue. If you touch the pink rectangle, it will cause touch keyboard to appear, which I don't want.
<input type=text id=f>
<div style="background: pink; height: 200px; width: 200px" onclick="f.focus()">
The short answer is that this is a built in function and you can't stop it, but there are a couple of options to consider.
1) use the onFocus event to immediately trigger the blur event to hide the keyboard again.
2) set readonly="true" on the element, later remove it and trigger the focus event.
3) create a fake input element with div's and css, when you want to trigger the keyboard focus on a hidden input field and copy out the value of the input on the keyup event as the user types.
Hope these suggestions were helpful to you.
If I got this right, you may also consider to change the logic of focusing the textfield when there is a click "anywhere". On touch-devices the touch events get dispatched first and you can cancel the click-handling (look for preventDefault(), return false; or stopPropagation() which should be called in you touch event handler).
You will need another event listener which handles the touch events outside the textfield, e.g. "touchstart".
If you want to keep the ui effect of a focused textfield, just add a css class "focused" to the textfield by script instead of using textfield:focused{} for your styles.
I use AngularJS 1.4.7
I have editable input. If we focus on input and after click outside of this input field, script will do function "save()" in ng-blur. Everything work correctly, but on iPhone 5/6 and iPad don't work (not execute anything in ng-blur). I don't know why, but I deduce that problem is in focus/touch action. Someone know where is the problem?
Fix ng-blur not working on empty space and most elements with iOS
Goal
In my app, we wanted to hide open menus or search results when clicking away from
the menu or search box.
Problem
iOS Safari does not blur properly when clicking away from the current element.
Note
You do not need a special directive. The problem is not with ng-blur, which works fine. The problem is that a blur event never occurs because of Apple's unusual design on iOS, regardless of whether you use ng-blur or a native DOM blur event.
Reason for Issue
Apple has designed mobile Safari to perform event bubbling differently than desktop browsers do. According to official Apple docs, if an element that is clicked has no click listener attached to it, then no click event is triggered. Without a click event, focus does not change and no blur event occurs, so the current element does not lose focus even though the user really did click elsewhere on the page.
The blur will only happen if the user clicked an element with a click event listener. Some elements like hyperlinks and inputs have "built-in" event listeners for click, and so will always register a click, causing blur to work.
Normally in desktop browsers, the click event is blindly fired whether there is a registered listener or not in the element's DOM hierarchy. That is why ng-blur works as expected in desktop browsers, even on "empty space".
Apple says that for iOS Safari they only dispatch the event if they find an element registered to listen for it.
Apple Docs - go to Figure 6-4
Apple's documentation makes it sound like they are looking for a registered event listener and handled on the target element, but that is not the case. I found the answers in the following article, and more importantly, one of the comments to it.
Quirksmode Article on iOS event delegation
First, observe that placing a listener on the document or body does not cause the click event to be dispatched on iOS Safari, if the target element has no click event listener and handler. It works in most browsers, but not on iOS.
It appears that Apple is checking the DOM hierarchy up to the <body> tag before dispatching the click event, but is not checking the <body> tag or above. Therefore, you need a click event listener attached to an element somewhere below the <body>.
Solution/Workaround
The solution then is very simple. All you need to do is to wrap all of the page content in a "master" container element just below the <body> element, and put the listener there instead of on the body or the document. It can even be an empty handler function. Apple is only checking to see if one is registered. The reason for wrapping all content is so that no matter where in the page the user clicks, the bubble-up process will eventually reach the master container.
If you do that, then ng-blur will work as expected in iOS, because the click event on empty space (an element with no click event listener) will pass the iOS check when it finds the parent container's click event listener and a click event will be dispatched normally, like it would be in any other browser.
Caution
This solution effectively causes iOS Safari to see a click event listener on every DOM element's hierarchy, tricking it into dispatching the click event on every element, just like a normal browser. I do not know if Apple has a performance reason they avoid this in iOS, or if it is just an aesthetic/developer type preference (see example). You will be changing the default iOS behavior in your app by using this workaround.
For example, iOS users may accidentally select text on your page that they did not mean too, and which would not normally occur without a click and hold gesture.
I don't know why that problem occurs.
but do one thing. create one small directive 'fake-blur' . then call your method in that directive
App.directive('fakeBlur', function(){
return {
restrict: 'A',
link: function(scope, element, attrs) {
element.blur(function(){
// call you function ex:
scope.save();
})
}
}
});
<input type="text" fake-blur/>
When clicking a link in google chrome the focus event fails to fire. All other browsers fire the focus event for links.
Link
I do not want to attach the event onmousedown, but onfocus.
Anyone have an idea for a workaround.
EDIT:
I would definitely consider this a bug because all other focusable elements trigger focus on click.
Even non focusable elements with a tabindex trigger focus on click in google chrome.
<div tabindex="-1" onfocus="console.log('focus')">div</div>
I can't attach to both click and focus because then onclick, other browsers would call the function twice. I can't detect this functionality because it requires user
interaction, and I won't do user agent string detection, because well its wrong.
Using this html:
Link
Is they any way to invalidate the second onmousedown call to prevent the function being called twice in non google browsers.
EDIT 2:
After some further testing <input type=radio> also fails to call focus in google chrome.
Why in the world is google chrome like this, while Opera, IE and firefox are all okay. What is crazy is that the mobile webkit browser even triggers focus on links when I tried it on my Android device.
That actually works just fine, except that the focus event isn't triggered simply by clicking on the link (try tabbing and you'll see the event firing). I don't think it's a bug, why not just safe guard and use both?
One work around you could do to avoid the double focus events from popping on the working browsers while still getting the focus event to pop on Chrome, is to on a click event check whether anything has focus on the page, and if not, then trigger the focus event.
With jQuery it could be done like this:
$('a').click(function(e){
if(!$('*:focus').length) $(this).trigger('focus');
});
example: http://jsfiddle.net/niklasvh/qmcUt/
You can use small hack:
Link