I need to detect mouseup event after mousedown on the document.
I have tried to add an event listener to document and document.documentElement with no success.
I need possibly a cross platform solution without jquery.
Notes: problem appears on not all browsers using alert().
http://jsfiddle.net/0f7vrzh7/8/
document.documentElement.addEventListener('mousedown', function(){
alert('mousedown');
});
document.documentElement.addEventListener('mouseup', function(e){
alert('mouseup')
});
In certain browsers the first alert would stop the second event. It works even with alert in IE11 for example. In the browsers where you experience this issue the alert box blocks the UI before the mouseup event is processed or propagated to the element you have the event handler attached to. Change to console.log() statements in your event handlers and the events are fired as you expect them to. Updated fiddle.
it's yours alert block the mouseup event. try with
document.documentElement.addEventListener('mousedown', function(){
document.getElementById("test").style.backgroundColor = "#ff0";
});
document.documentElement.addEventListener('mouseup', function(e){
alert('mouseup')
});
http://jsfiddle.net/0f7vrzh7/16/
Related
I've been having trouble getting stopPropagation to work for my dataview. Basically the issue is as follows;
Select node in the dataview, this fires the select, selectionchange events
Selected node has an image with an onClick event, this creates a report in a pop up window.
When image is clicked I call stopPropagation to prevent the event being bubbled up to the dataview which would cause the deselect, selectionchange events to be fired.
stopPropagation only seems to work in Firefox for me. Chrome and IE it seems to have no effect as the node is deselected and the unwanted events fired.
I've tried the following function on the onClick event
handleBubbleEvent: function(e) {
if (!e) {
var e = window.event;
}
e.cancelBubble = true;
e.returnValue = false;
if (e.stopPropagation) {
e.stopPropagation();
}
}
Have also seen stopImmediatePropagation, preventDefault, stopEvent but these also has had no effect
I am doing all this inside an Ext XTemplate
I'm wondering if this is an ExtJS 5 issue and the same code is working for an older version of ExtJS. I just can't seem to stop the click event bubbling back up to the dataview which then fires the deselect and selectionchange events.
Could it be that it is a timing/order issue. I use ExtJS's selectionchange event on the dataview whereas in the XTemplate I am using my own listener function? I see stuff online referencing capturing/bubbling of events and as I'm not a web developer I'm struggling on this.
UPDATE:
I'm now looking at events and capturing/bubbling, it seems the capturing is going up to the parent and calling the deselect, selectionchange then going down into the actual click handler at which point I then call stopPropagation but it is too late at this stage. Looking at creating my own listener for selectionchange with either target/delegate set so that it is only called when class != 'some class' and then a listener on 'some class' click to handle what I want and stopPropagation, if that makes any sense!
Try using a setTimeout on any dom manipulation triggered by the event.target element's event handler so that the event bubbling completes before any of the dom manipulation occurs.
I had the same issue with Chrome, and (like with you) Firefox worked. I discovered that Chrome seems to get confused if you modify the dom before the event bubbling completes.
In my case, I was adding two elements to the document.body (a canvas and a fieldset) and by the time chrome bubbled the event, the event.target was incorrect (it thought "BODY" was the event.target.tagName -- WRONG!). I wrapped the DOM manipulation portion in a setTimeout like this:
setTimeout(()=>
{
document.body.appendChild(canvas);
document.body.appendChild(fieldSet);
},0);
After this, chrome started reporting the correct element.target on the bubbled body click event. Maybe this same technique will help you get e.stopPropagation() to do its thing before the dom manipulation occurs.
I want to trigger a blur within a keypress. IE10 works differently from Chrome/FF. It appears that IE will finish the keydown handler before calling the blur handler, whereas Chrome and FF will trigger the blur handler right when the blur occurs and then go back to finish the keypress handler.
I'm wondering if this is a bug and if there is a good workaround in IE to work like Chrome and FF.
See the code below.
$(document).ready(function () {
document.getElementById("txtInput").addEventListener('blur',
function (event) {
console.log('blur');
});
document.getElementById("txtInput").addEventListener('keydown',
function (event) {
console.log('down 1');
document.getElementById("txtInput").blur();
console.log('down 2');
}
);
});
http://jsfiddle.net/244raf1u/
Output from Chrome:
down 1
blur
down 2
Output from IE
down 1
down 2
blur
Try this:
$(document).ready(function () {
$("#txtInput").blur(function (event) {
event.preventDefault();
console.log('blur');
});
$("#txtInput").keypress(function (event) {
console.log('down 1');
$(this).blur();
console.log('down 2');
});
});
Check out the changes I made in this updated fiddler here.
I had to change the way you were calling the blur() trigger, and then added a simple event.preventDefault() in the blur() handler to prevent a second firing in IE. It seems like IE was trying to move focus off of that input after running the keypress handler.
Also by using this notation: ($("#txtInput")[0]) you are actually referring to the original element object and not the jQuery object, which may be causing issues in IE where the other two are catching the error.
Hopefully this will help!
I found a couple solutions. First is to use the focusout instead of blur. Blur doesn't bubble, focusout does. Not sure why that matters, but the events are probably implemented differently. Unfortunately, that's not an option for me.
The other solution was to have two keydown handlers. The first triggers the blur and anything I want to happen before the blur. The 2nd handler does the processing after the blur, but I have to set a 50ms timeout because all keydown handling occurs before the blur handling.
I have an <input> element that can either have the focus set via code, or as the result of a mouse click.
If the user clicks on the input, then the click event handler will fire - all well and good. If the element receives the focus via some other way (e.g. via code) then I want to manually trigger the click event so that the handler will also fire.
I could do this:
$elem = $('input');
$elem
.on('focus', function() { $(this).trigger('click') })
.on('click', function() { alert('Clicked!') });
However, this will result in click handler being fired twice; once for the click event and once for the focus event.
Is there any way to selectively trigger the click handler only if the focus was not received as the result of a click event?
UPDATE
This is a very simplified version of my problem, so I can't do things like bind both handlers to the focus event etc. I'm trying to merge two third-party pieces of code.
The .trigger() function adds a property isTrigger in the event object to identify that the event was triggered by its usage. Although, it is not documented the property is still present in jQuery 1.8.3 but it seems to only be used internally.
Anyways, you can make use of the extraParameters parameter to add a custom property to the event object. For instance,
$(this).trigger('click', {
isTrigger: true
});
It will keep the compatibility with isTrigger even if it is gone in a future release.
After doing some more research it appears that there is no way of guaranteeing which event will fire first: click or focus. (There doesn't seem to be a standard that dictates the order of events.)
This means that when the focus event fires there's no way to determine if a click event will or will not be triggered by the browser shortly afterwards.
I managed to solve the issue by using setTimeout() to run a test about 100ms after the focus event fired to check if the click event had fired. The third-party code that I was using (bound to the click event) added an extra class to the <input>, so I was able to check for that.
You can tap into the mousedown event which fires before the focus event. When you click a focusable object the order of events is as follows... mousedown, focus, mouseup, click.
You could set a flag in the mousedown event and then check for it in the focus event to see if the focus came from a mouse click. Obviously make sure to clear the flag in the focus event handler. Every application is different, but tapping into the mousedown event allows you to figure out a solution.
Here is a JSFiddle demonstrating the order of events... http://jsfiddle.net/ek7v7/
$elem = $('input');
$elem
.on('focus', function() { alert("Focused!") })
Focus can be fired by focusing the input by using tab, clicking it, or by using .focus()
Is there a reason for on('click', ...)?
I want to run some code when two event handlers are both triggered.
I've tried it like this:
$('#box').mousedown(function(){
$(document).bind('mousemove',function(e){
// more code here
});
});
But the code even works when I trigger mousedown once and move my mouse after that. I only want to execute the code when my mouse is down and it's moving.
How can I achieve that?
I think the problem you are having is with your understanding of the way the event handlers work, once you have added an event handler it will listen out for its event.
So your code will add an event handler to listen for mousedown when the dom is ready, once it occurs it will add an event for mousemove - the document now has both event handlers registered so it will do stuff for both independently.
What you want to do, is remove the event handler for the mousemove on the mouseup event. That way the document now no longer listens to the mousemove event handler because its been removed.
$('#box').mousedown(function(){
$(document).bind('mousemove',function(e){
// Do something:
});
});
$(document).mouseup(function(){
$(document).unbind('mousemove');
});
Here is a simple example, so you can see whats happening it will add a message under the box.
Try giving this a shot? Have a global variable that indicates whether the mouse is down or not. When they mousedown on the #box element the global variable is set to true. When they mouseup it's set back to false. See a live example here.
$(document).ready(function(){
var mouseDown = false;
$("#box").mousedown(function(){
mouseDown = true;
});
$(document).mouseup(function(){
mouseDown = false;
});
$(document).mousemove(function(){
if (mouseDown){
//do your stuff here
}
});
});
Use the
event.stop()
or
event.die()
snippet before use the event.
Example:
$("#mybutton").unbind("click");
$("#mybutton").die();
$("#mybutton").click(function(){ alert("Hy mate!");});
I've noticed a strange behaviour of the live() function in jQuery:
normal
live
$('#normal').click(clickHandler);
$('#live').live('click', clickHandler);
function clickHandler() {
alert("Clicked");
return false;
}
That's fine and dandy until you right-click on the "live" link and it fires the handler, and then doesn't show the context menu. The event handler doesn't fire at all (as expected) on the "normal" link.
I've been able to work around it by changing the handler to this:
function clickHandler(e) {
if (e.button != 0) return true;
// normal handler code here
return false;
}
But that's really annoying to have to add that to all the event handlers. Is there any better way to have the event handlers only fire like regular click handlers?
It's a known issue:
It seems like Firefox does not fire a
click event for the element on a
right-click, although it fires a
mousedown and mouseup. However, it
does fire a click event on document! Since .live catches
events at the document level, it sees
the click event for the element even
though the element itself does not. If
you use an event like mouseup, both
the p element and the document
will see the event.
Your workaround is the best you can do for now. It appears to only affect Firefox (I believe it's actually a bug in Firefox, not jQuery per se).
See also this question asked yesterday.
I've found a solution - "fix" the the live() code itself.
In the unminified source of jQuery 1.3.2 around line 2989 there is a function called liveHandler(). Modify the code to add one line:
2989: function liveHandler(event) {
2990: if (event.type == 'click' && event.button != 0) return true;
This will stop the click events from firing on anything but the left-mouse button. If you particularly wanted, you could quite easy modify the code to allow for "rightclick" events too, but this works for me so it's staying at that.
You can actually rewrite it as:
function reattachEvents(){
$(element).unbind('click').click(function(){
//do something
});
}
and call it when you add a new dom element, it should have the expected result (no firing on the right click event).
This is an unfortunate consequence of how live is implemented. It's actually uses event bubbling so you're not binding to the anchor element's click event, you're binding to the document's click event.
I solved this by using mousedown events. In my situation the distinction between mousedown and click didn't matter.