Does anyone know of crossbrowser equivalent of explicitOriginalTarget event parameter? This parameter is Mozilla specific and it gives me the element that caused the blur. Let's say i have a text input and a link on my page. Text input has the focus. If I click on the link, text input's blur event gives me the link element in Firefox via explicitOriginalTarget parameter.
I am extending Autocompleter.Base's onBlur method to not hide the search results when search field loses focus to given elements. By default, onBlur method hides if search-field loses focus to any element.
Autocompleter.Base.prototype.onBlur = Autocompleter.Base.prototype.onBlur.wrap(
function(origfunc, ev) {
var newTargetElement = (ev.explicitOriginalTarget.nodeType == 3 ? ev.explicitOriginalTarget.parentNode: ev.explicitOriginalTarget); // FIX: This works only in firefox because of event's explicitOriginalTarget property
var callOriginalFunction = true;
for (i = 0; i < obj.options.validEventElements.length; i++) {
if ($(obj.options.validEventElements[i])) {
if (newTargetElement.descendantOf($(obj.options.validEventElements[i])) == true || newTargetElement == $(obj.options.validEventElements[i])) {
callOriginalFunction = false;
break;
}
}
}
if (callOriginalFunction) {
return origFunc(ev);
}
}
);
new Ajax.Autocompleter("search-field", "search-results", 'getresults.php', { validEventElements: ['search-field','result-count'] });
Thanks.
There is no equivalent to explicitOriginalTarget in any of the other than Gecko-based browsers. In Gecko this is an internal property and it is not supposed to be used by an application developer (maybe by XBL binding writers).
2015 update... you can use event.relatedTarget on Chrome. Such a basic thing, hopefully the other browsers will follow...
The rough equivalent for Mozilla's .explicitOriginalTarget in IE is document.activeElement. I say rough equivalent because it will sometimes return a slightly different level in the DOM node tree depending on your circumstance, but it's still a useful tool. Unfortunately I'm still looking for a Google Chrome equivalent.
IE srcElement does not contain the same element as FF explicitOriginalTarget. It's easy to see this: if you have a button field with onClick action and a text field with onChange action, change the text field and move the cursor directly to the button and click it. At that point the IE srcElement will be the text field, but the explicitOriginalTarget will be the button field. For IE, you can get the x,y coordinates of the mouse click from the event.x and event.y properties.
Unfortunately, the Chrome browser provides neither the explicitOriginalTarget nor the mouse coordinates for the click. You are left to your own devices to figure out where the onChange event was fired from. To do this, judicious use of mousemove and mouseout events can provide mouse tracking which can then be inspected in the onChange handler.
Looks like it is more designed for extension writers than for Web design...
I would watch the blur/focus events on both targets (or potential targets) and share their information.
The exact implementation might depend on the purpose, actually.
For IE you can use srcElement, and forced it.
if( !selectTag.explicitOriginalTarget )
selectTag.explicitOriginalTarget = selectTag.srcElement;
In case of form submit events, you can use the submitter property in all modern browser (as of 2022).
let form = document.querySelector("form");
form.addEventListener("submit", (event) => {
let submitter = event.submitter; //either a form input or a submit button
});
Related
How to write conditions for an automatic mouse click in the UI when we press any key on the keyboard.
I'm Working on the Accessibility Part ->
My Scenario is we are having banner which is displayed when the page loads initially. for that until we close that banner the focus should be inside that banner.
I have tried the onKeyDown event. when we trigger the onKeyDown event by using e.preventDefault() the focus is hidden. I need to get that focus again when I click any key on the keyboard.
Thanks in Advance.
handleTab = (e) => {
let tabKey = false
if (e.keyCode === 9) {
e.preventDefault()
tabKey = true
}
if(tabKey) {
# here I need an automatic browser click event. so that when I hit the tab key it will go inside of that banner
}
onKeyDown = {this.handleTab()}
Try to use tabindex property to prevent tab navigation outside the banner.
<input type="text" tabIndex="-1"/>
I created small demo to test: https://codepen.io/mich_life/pen/vYRMpqe
This is what the MDN documentation has to say about keyCode:
Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
key which is a textual representation of the pressed key should be used instead & has been supported since Internet Explorer 9.
Since you haven't specified, if the banner is inside or outside your component, I am going by outside.
handleTab=(evt)=> {
if(evt.key == 'Tab') {
evt.preventDefault();
document.getElementById('banner').focus();
}
}
If it's rendered inside your component, use a ref instead.
onpointermove event is not firing up for textbox in IE11 in window 8.1 phone. onpointerup and onpointerdown event is firing up properly but not onpointermove.
Here is the fiddle to reproduce the issue,
http://jsfiddle.net/ph0v7reu/6/
document.getElementById("test").onpointerup = function handle1(event){
var result = document.getElementById("result");
result.value = event.type;
return true;
};
document.getElementById("test").onpointermove = function handle2(event){
var result = document.getElementById("result");
result.value = event.type;
return true;
};
document.getElementById("test").onpointerdown = function handle3(event){
var result = document.getElementById("result");
result.value = event.type;
return true;
};
You're not seeing pointermove events because the move is being interpreted as a pan gesture. Use the touch-action property to disable panning on the element and you should start to receive pointermove events instead.
input { touch-action: none; }
For more, you can see a recent talk I gave on this: https://www.youtube.com/watch?v=l8upftEWslM#t=1136
Relevant part of the standard for this: http://www.w3.org/TR/pointerevents/#declaring-candidate-regions-for-default-touch-behaviors
Use the non-prefixed lowercase name, pointermove, which is better for standards compliance and future compatibility
So your code should be:
document.getElementById("test").pointermove = function handle2(event){
It seems mobile versions of IE10 and IE11 have a lot of bugs when some ediitable area gets focus.
Under editable area are meant: <textarea>, <input type="text"> or similar, and div with contentEditable attribute.
IE10 has a bug, that when the editable area gets focus, any element with registered msPointerDown event handler does not get fired.
This can be at least partially workarounded, since msPointerMove is fired, so at least you can assume by checking isPrimary on msPointerMove event that first finger has touched the area. Any additional touches are processed correctly with msPointerDown event.
Now IE11, same issue... It processes pointerdown correctly during focus, but does not fire pointermove. This can be partially worked around by replacing pointermove by a touchmove event, at least with latest IE11 upgrade that began to support touch events (even if absolutely full crap implementation of TouchEvent).
I believe the day will never come when the IE programmers begin to write good software. Unfortunally there is no one good alternate browser for Microsoft Mobile systems.
Haven't post in quite a while.
Anyway I was searching about my subject and I got this.
$(window).keyup(function(e) {
if (e.which === 8) {
$('.ilol'). fadeOut();
}
});
It's working perfectly fine. But when I change the window to a class or id it doesn't respond anymore.
There's not a lot of detail about the type of element you are trying to attach this event handler to, but the jQuery documentation explains that form elements (e.g. input) are a safe bet because they are able to be focused across most browsers:
The keyup event is sent to an element when the user releases a key on
the keyboard. It can be attached to any element, but the event is only
sent to the element that has the focus. Focusable elements can vary
between browsers, but form elements can always get focus so are
reasonable candidates for this event type.
http://api.jquery.com/keyup/
It may also be a selector issue. Make sure that your selector is working properly by pasting it in your browser's JavaScript console and see if it returns any elements.
Make sure you are binding event in ready function.
$(document).ready(function(){
$('.someClassName').keypress(function(e) {
if (e.keyCode === 8) {
$('.ilol'). fadeOut();
}
});
});
After some testing this is what worked best for me. The 40 key in this example is the down arrow key.
$(document).keydown(function(e)
{
if(e.keyCode == 40){
$('.ilol').fadeOut('fast');
}
});
With buttons, I can call the click() method on them to have a click generated. DIVs however don't have this method on all browsers. Yet I can attach click event listeners to them (by either setting .onclick="..." or adding an event listener).
Is there any way for me to "synthesize" a click on such an element programmatically, but without using jQuery? Ideally this will not be dependent on a specific way of the listeners being registered (so simply calling eval(div.onclick) will not work for me), and work in all modern browsers.
(For the curious, I need this for automated testing, not tricking users.)
I recently wrote a function to do just this into my library, it can be found in the GitHub repository here.
It is completely cross browser and triggers the specified event on the elements returned by the selector engine. I am sure you will be able to extract the code you need from it.
If not, here is what you need. Replace element with, well, the element. And type with the type of event, in this case, click.
// Check for createEventObject
if(document.createEventObject){
// Trigger for Internet Explorer
trigger = document.createEventObject();
element.fireEvent('on' + type, trigger);
}
else {
// Trigger for the good browsers
trigger = document.createEvent('HTMLEvents');
trigger.initEvent(type, true, true);
element.dispatchEvent(trigger);
}
Here is an example implementation.
function simulateEvent(element, type) {
// Check for createEventObject
if(document.createEventObject){
// Trigger for Internet Explorer
trigger = document.createEventObject();
element.fireEvent('on' + type, trigger);
}
else {
// Trigger for the good browsers
trigger = document.createEvent('HTMLEvents');
trigger.initEvent(type, true, true);
element.dispatchEvent(trigger);
}
}
If your browser is DOM compatible you can use the dispatchEvent(evt) method of the DIV element.
For more see the dom w3c spec.
I met one troublesome web page whose structure is complicated. If one DIV is clicked by mouse, everything is OK. However, if it is focus-ed by javascript(i.e. divElement.focus). The layout turns to messy. This only happens in IE7/8.
So, is there any difference between click-to-focus and focus-by-javascript in IE?
Firing a Javascript focus event does not fire a click event. Without seeing the relevant code, I'm led to guess that some click handler is in place that is not being called in the case where you fire a focus event.
You might try, instead, firing a click:
var clickEvent;
if(document.createEvent) {
clickEvent = document.createEvent('click');
clickEvent.initMouseEvent('click');
divElement.dispatchEvent(clickEvent);
} else {
// Semi-pseudocode for IE, not tested, consult documentation if it fails
clickEvent = document.createEventObject();
divElement.fireEvent('onclick');
}
Or if you're into the jQuery thing:
$(divElement).click();
There's similar solutions for Prototype as well (search for Event.simulate).
The definition of the Focus action is to bring the input (keyboard or mouse) to a certain element, usually an input field. When an element gains focus, an OnFocus event is fired. When it loses focus, an OnBlur event is fired.
What you usually get by clicking is the OnClick event, which is not necessarily related to the above two.
This only happens in IE7/8.
Hmm, then I'm sure it's an IE related bug. Not surprising. If there is legitimate Javascript events involved, then they should fire uniformly across all browsers.