I have a Javascript mobile app that had an initial problem of touch down resulting in refreshing of the page. To counteract that, I added a ontouchmove attribute on my div tag where in the javascript I stop propagation (event.stopPropagation())
Context of the screen :
Asks a simple question, with 4 radio button options, and 2 buttons. The two buttons are being cut off after I've stopping the propagation. Confused how the bubbling of parent tags are impacting my buttons being cutoff.
Share the code so that everyone can better understand the problem.
From your statement above I could infer that some event which was vital for your screen has also stopped because of your stopPropagation call.
stop propagation should be the last resort, rather you can add your event to a specific component or add class to all components for which you need to listen to the event so as to avoid bubbling on the whole screen.
Related
In an effort to add favoriting to a application menu, I'm working on getting onMouseEnter events to fire only on the element that is currently hovered. The problem is that due to these items being nested, onMouseEnter will fire on both the child element and the onMouseEnter of the parent element will also fire.
Ie:
HTML Nesting
The ideal behavior would be this:
Ideal Behavior
But the actual behavior is this:
Actual Behavior
I have already tried stopPropogation, but the problem is that there is a separate event listener on each of the menu items (both the L1 and the L2 have their own on mouse enter listeners). As such, capturing the event at the L2 level doesn't stop the event from firing at the L1 level.
Does anyone know of a way to only trigger the L2 event? Ideally, we wanted to be able to keep hover state specific to each item (ie don't have to have pass handlers for "setIsChildElementHovered"), but open to any ideas people have.
Did you try to add the event only on the child element ? If you have some snippets code might to answer your question. thanks :)
I'm working with legacy HTML pages written ~10 years ago. That being said, it should be explicitly known that refactoring old code is not only NOT time effective, but also a risky endeavor.
A legacy webpage has many buttons which activate JavaScript event(s) using the onClick="myFunction()" tag. I've been tasked with interfacing a JavaScript file (which uses jQuery) into these legacy webpages. I've added the JavaScript file in question and jQuery 1.9.1 source and attached them to the legacy HTML pages prior to the closing body tag, ex:
<script src="jquery-1.9.1.min.js"></script>
This JavaScript source file (which uses jQuery) activates a mousedown event on the buttons with the attached class "getStats", ex:
$(document).on('mousedown', '.getStats', function (event) {
//Stuff
});
However, when the jQuery activates, it does NOT perform the redirect the button is supposed to do through the HTML onClick event.
I can't find any information online on how the HTML onClick and jQuery mousedown event timings happen to understand whether or not I'm encountering a race condition. Both the HTML onClick redirect and jQuery mousedown events need to happen, and I can't just simply go back and edit all the legacy HTML onClick events to be done in jQuery either as that would take months of work.
Sample jsFiddle:
https://jsfiddle.net/koa2hsbp/
The jQuery works right off the bat. If you comment out the jQuery mousedown function, then the HTML onClick works. But I have to make it to where both parts activate (preferably jQuery mousedown prior to HTML onClick), without changing the HTML's functionality. (Again, changing the legacy code is a costly endeavor in and of itself.)
Some explanation about events:
mousedown - triggered immediately after mouse button pushed down while focusing element.
mouseup - triggered immediately after mouse button goes up while focusing element
click - triggered when you have consecutive mousedown+mouse up on the same element.
So in your example - you push mouse down and this immediately triggers code which produce alert. Then you release mouse button, but web paged is focused on alert, not on our element as alert window by nature blocks everything else and interrupt javascript. Since there is no mouseup event - there is no click event as well, so legacy code is not invoked.
Try following to prove I am right - push mouse down and hold it. Then click enter button - this will remove alert. Then release mouse button while on top of element. This will trigger click.
Unfortunately it is hard to mix mousedown click and alert in same example. Consider moving jQuery handler to click if you need alerts. That of cause will invoke jQuery after legacy handler.
I have jquery, bootstrap included in a page I'm writing. It's a complex page. The problem I'm having is with Internet Explorer not seeing mousedown event. Chrome and FF both see the event just fine but not IE.
I wrote a test page with the event and it worked just fine in IE. So my question is...
Is there a way through the developer tools to determine what is cancelling an event?
I have a suspicion that one of the many .js files I've included is cancelling the mousedown event and IE isn't seeing it anymore. Chrome and FF does though. So I'm not 100% that it's being cancelled but it's my only guess I can come up with.
Code is really irrelevant since it's all of jquery and bootstrap. However, I am playing with divs that are draggable and resizeable. That's why I need to use jquery. The bootstrap is used because I also have a wysiwyg editor on the page.
Please don't recommend click. I need mousedown. When the mouse is down the border around the draggable and resizeable div turns red and I have some code that selects that div to capture top, left, width, and height as it's being moved and resized.
If click was selected as the event, the user would have to click the div box first then click and hold to move it. That's not a user friendly interface.
Any help is greatly appreciated.
What do you exactly mean as cancel, .preventDefault() or .stopPropagation? If we are talking about preventDefault - you should still be able to add event listener to parent container and then see your event object - it might have some data to traceback. Alternative would to override jQuery .on method and see who actually subscribes to the event.
After little more thinking - add another listener BEFORE the malicious one, to do that insert document-ready handler with event binding right after jquery loading code. In your new mousedown handler try to override problematic method of the event.
UPDATE:
you should try to check all events attached to your element one by one. To do that - check this post jQuery find events handlers registered with an object
In short - try using jQuery._data( elem, "events" ); to see attached event listeners and inspect their code in your code base. After you find the reason it will be much easier to reach the desired functionality. Before that it is just a guesswork.
Using jQuery, I often like to use mousedown and mouseup events in conjunction for pushable buttons.
However, in every case I've used the mouseup event, binding the click event instead seemed to produce identical results.
Is there any substantial difference between the two methods below?
// Method 1
$('.myButton').bind('click', callback);
// Method 2
$('.myButton').bind('mouseup', callback);
Please note I'm seeking a technical explanation on the differences between using both methods. This has no relation to the question that has been flagged as a dupe: Differentiate click vs mousedown/mouseup
With a mouseup event, you can click somewhere else on the screen, hold down the click button, and move the pointer to your mouseup element, and then release the mouse pointer.
A click event requires the mousedown and mouseup event to happen on that element.
The normal expectation is that a click requires both the mousedown and mouseup event, so I'd recommend the click event.
From the possible duplicate, it appears that mouseup and mousedown events can also be caused by mouse buttons other than the left click button. Which is very different from what a generic user would expect.
My understanding is that "click" hides lots of complexities (such as making sure that mousedown/up occur on the same element, cancelling with ESC/right click). Using "click" over "mousedown/up" should be preferred.
One scenario where "click" does not seem to work when app updates content very often in such a way that underlying DOM elements get replaced. In this case "click" will not be triggered and it might result in poor customer experience.
I think Mouse Down and Mouse Up events give you further control over the click event. It divides the click event into two more events so that more details can be coded for each event. Click event restricts the mouse click and force you to code both the events in the same function.
You can understand this restriction if you ever try to make your own dragging behavior.
Dragging needs a mouse-down event to start a drag behavior. You cannot do it with click event. And since you need a separate mouse-down event. The requirement of a separate mouse-up event becomes obvious.
Once the dragging starts ( you have not yet release the mouse button) you need the object to change position as per the cursor position. This too needs to be coded only in mouse-down event.
However you can use click event too if we could change the way how people drag the objects. For example click-1 starts the drag and click-2 stops the drag and puts the object on another position. But there are two problems I see:
It does not look natural. As in the real world we are in habit of
pressing the object and dragging it.
It can be process intensive to move heavy graphics just by clicking and mouse-move.
I would like to add to the other answers that click event works on touch-enabled devices while mouseup / mousedown do not (obviously because there's no "mouse")
Note that there's a 300ms delay on touch devices with the click event.
The biggest difference that affects the way I code is: the click event on an a HTML tag is responsible for changing the URL. In contrast, the mousedown and mouseup events will not acheive this
Is it considered 'good practice' to stop JavaScript event propagation - does it benefit performance in any way?
I'm wondering if there is benefit outside of layout purposes where you stop propagation so you don't trigger multiple events accidentially.
It entirely depends on the DOM complexity and the actions taken in each event that is triggered.
You would stop propagating events mainly not because of complexity but because of unwanted actions not to take place.
For eg: Consider a situation where you have a show hide div and when you click on the div it should opne and if you click anywhere else in the document it should close.
So you would wire an onclick event handler to the document as well as the div. So you have to stop propagating the event when clicked on the div so that the document click handler won't be invoked. Thats a situation where you use stop event propagtion.
Only when it is necessary to the program logic, such as to prevent form submission or another DOM element's action being triggered. Unless you have a seriously complex DOM tree, there will not be any serious performance hit.