Is there a way to disable/set to false the onMouseUp event in javascript so that when a button is clicked it fires on mousedown by default?
Aside from the fact that onmousedown happens before onmouseup, you can't prevent an event from happening. You can however prevent default behavior of an event by executing "preventDefault()" on the event object itself.
No.
To be honest, I very much suspect there's a better way of achieving what you're after. I suspect if you update your question with some more surrounding information you'll get some good advice. :-)
Related
I have a situation where an anchor fires the 'click' event before the input, which loses the focus and fires the 'focusout' event.
To be clear, I write something in the input and then I click the anchor. I'm expecting the 'focusout' event to be written to console first and then the 'click' event.
I'm not able to reproduce this in a dummy app like in the code below, it only reproduces in the web app I'm working on, which I can't share here.
click me
<input type="text" id="t">
<script>
document.querySelector("#a").addEventListener('click', function(e) {
console.log('click');
});
document.querySelector("#t").addEventListener('focusout', function(e) {
console.log('focusout');
});
</script>
Any idea how could it be possible for anchor to fire the 'click' event first before the input firing 'focusout' event?
I'm pretty dazzled how it's actually possible... I can't see how in the world, even if I wanted to, be able to make the 'click' fire first. I checked several times the event object in watcher in Chrome dev tools and I can't see anything peculiar
I'm using latest Chrome on Windows 10
The change event doesn't fire until the input loses focus. You can use onkeypress instead.
Ironically enough, it seems like jQuery .focusout / .click conflict has the exact opposite problem as you. From what I'm reading around the web it seems like the general concesus is that the HTML specification doesn't actually specify the order of events and it is up to the browser to implement however they see fit. However, in your case I would certainly expect focusout to happen first, tho clearly it isn't. Have you tried "onblur" instead?
I found it! This is one of those things which doesn't let you sleep well.
The issue was somewhere else, in some library, there is a mousedown handler on the anchor with a e.preventDefault():
http://jsfiddle.net/vynd7kgj/
This sucks. I don't know if I should cry or laugh.
Why would you want to do something like this?
Is there a way to completely apply stopImmediatePropagation() across the board? Since I thought it was annoying to do that in each tap event handler, let say.
I commented in this question as an FYI:
Stop jQuery Mobile swipe event double bubbling
Can you do something like:
$(document).on('click', function(event){
event.stopImmediatePropogation();
});
The only solution is to do event.stopImmediatePropogation(); on each handler function. It's a hassle.
I have a fairly large html page and I've noticed that my click-to-show/hide process appears a little retarded.
I've also discovered that if I use "mouseenter" in place of "click", the response is almost instantaneous (as opposed to 2 seconds when I use "click").
$("button.showhide").click(function() { $("#"+$(this).attr("id")+"-1").toggle() });
versus
$("button.showhide").mouseenter(function() { $("#"+$(this).attr("id")+"-1").toggle() });
Is there any way to make the click event as fast as the mouseenter event?
Thanks.
Edit:
Does the following help in explaining this behaviour?
(There's no mention of a "javascript event" for mouseenter.)
.click()
Bind an event handler to the "click" JavaScript event, or trigger that event on an element.
.mousedown()
Bind an event handler to the "mousedown" JavaScript event, or trigger that event on an element.
.mouseenter()
Bind an event handler to be fired when the mouse enters an element, or trigger that handler on an element.
You should use a delegate to trigger your events(from jQuery 1.7 use on method for events binding) :
$("button").on('click','.showhide',function(){/*...*/});
You could improve the speed of the event handling, but that depends on the html markup.
For instance, if all of your showhide buttons are grouped in a certain div, and some other buttons are in other scattered all over the body, you should use something like this :
$("button-container-selector").on('click','button.showhide',function(){/*...*/});
I think that the time to process
function() { $("#"+$(this).attr("id")+"-1").toggle();
is exactly the same in the two cases, it's just that mouseenter triggers much earlier than click and so you think it's faster.
The only thing i could think of is that you have realy a lot of click handlers, but i think you really nead a lot to slow down things
EDIT - Try doing
$('body').on("click", "button.showhide", function() { $("#"+$(this).attr("id")+"-1").toggle());
By reading all previous answers, and the behaviour explained in the question, I think that there might have been a key piece of information missing. Was your test was happening in a tablet or a touch-enabled device by any chance?
Some touch-enabled browsers or devices will slow down click events to allow for a delay, so the user can start a gesture instead of issuing a click. This would explain why, in your case, "mousedown" or "click" are slower than "mouseenter", which in a touch device happens as soon as you touch the element being monitored.
If this is the case, what I would do to improve responsiveness and be compatible in different types of devices, is binding both "mousedown" and "touchstart" (compatible with touch-enabled devices) to the code that must execute after the mouse press (or screen touch).
In your case:
$("button.showhide").bind('touchstart mousedown', function() {
$("#"+$(this).attr("id")+"-1").toggle()
});
I hope this helps.
I have a certain situation I want to clarify for myself, and I would be glad if anyone has any experience with this issue and is willing to explain it to me.
I have a textarea that has a change event handler:
textarea.bind('change', function(event){
// do something
});
Hypothetically, what if I have some sort of a click event handler that catches all user clicks:
$(document).bind('click', function(event){
event.preventDefault();
});
Will this handler also cancel blur and change events for a textarea if a user clicks out of it with his mouse? And if it will, how can I prevent this from happening?
Update: Thank you for your answers, I can not say that I tried it, but I have a similar situation and I am trying to rule out possibilities why change is not firing on my textarea. In my case there is a change handler that doesn't work if I click on an area in which all click events are prevented by default and replaced with custom behaviour.
No, it will only prevent the default browser behavior for the 'click' event.
No, it won't.
Hypothetically, what if you just tried it? (answer: it won't, as stated just before me)
If you don't want users to be able to leave a inputfield (which sounds like strange user interaction to me), you might be able to just set focus after a blur/change event - perhaps you would need a small timeout to let the event finish first. I would not recommend it, but it's always worth a try.
in javascript, when I receive a focus event, how can I work out which element has lost focus? I'm trying to avoid having to put an onblur event handler on all elements within my web page.
#pbrodka: the target/srcElement property would refer to the element with focus for onfocus events
offhand I can't see a way to get this short of onblur, or if the set of objects you care about all have focus methods you could store a reference to that object instead. It's also possible event bubbling could get you out of jail
this all feels like a bit of a code smell though - perhaps you need to describe the problem in more detail
Difficult this. You cannot use event delegation to find out which control last produced a blur as focus/blur do not bubble up. There have been some attempts to 'fix' this but they are buggy and not resiliant cross browser.
Could I ask you why do you need this information as maybe there is an alternative solution.
Unfortunately, the onblur event doesn't bubble, otherwise you could have handled it at the window level to always know when an element lost focus.
As things are, I do believe it will be hard to do without, as you say, adding an onblur event handler to all elements (a truly nasty solution ;-).
It is possible to delegate the focus and blur events, if you follow PPK's advice, here:
http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html
The most simple solution is to write a function that walks all forms and then all elements within the form and installs an onblur handler for each (which will probably call some global function). This handler will get an event and this event will contain the info you seek.
This way, you just have to call this method once in body.onload and it will work no matter how complex your document is.
The only drawback is that you will need to call it if you dynamically add forms to your current document. In this case, you must make sure not to install the handler again (or you will get spurious duplicate events).