Does slideToggle have some kind of bug? - javascript

I made a slideToggle panel using jquery here you can see. But I guess I have found a bug. When you took and leave your mouse on it(on the div that has hover function) for a few times, the bug appears.
How can I fix this bug ?
thanks..
EDIT
I have just found this:
http://stackoverflow.com/questions/5266683/slidedown-and-slideup-looping-bug-in-firefox
That's what I was looking for.
Thanks..

add the .stop() method to prevent the animation from queuing. i.e. $("#will_slideDown").stop(true, true).slideToggle("normal");

What you are referring to is NOT any sort of a bug, not specific to any browser either.
In fact when you register a handler for a particular event, the handler by itself won't be capable of handling immediate firing of the event and therefore you'll end up with queuing of the fired events.
To stop such behavior, simply use jQuery's is() method with the filter :animated and return false in the handler.
if($('#will_slideDown').is(':animated')){
return false;
}
JSFiddle

Related

jQuery .click() is clicking, but it shouldn´t

while testing my JavaScript I have the following problem:
$('#idOfMyElement').click();
is executed. But I want to verfiy with my test, that is is not executed, because it has the following CSS:
<span style="cursor: not-allowed; pointer-events: none;" id="idOfMyElement"></span>
I debugged it and it is sure, that when the .click() is executed, it has DEFINITELY the mentioned CSS-attributes. In my normal program it works (means that the click doesn´t work), but in my test the click works, even if it shouldn´t.
I have no clou, what might be the problem.
Thanks for your help!
Looks like in your test you are triggering the event programmatically by using $('#idOfMyElement').click();; in that case it is not bound by the CSS mouse rules, and thus the click handlers will get executed.
You need to check the mouse pointer rules before triggering the click event in your test suite.
Prevent the default click event using jQuery:
$('#idOfMyElement').on('click', function(e) {
e.preventDefault(); });
* UPDATE *
Now that I know what you're trying to do, I highly recommend using javascript over CSS for this because CSS does not work the way you're trying to use it – Javascript does. Instead of using CSS attributes, use Javascript variables.
When you want the element to be clickable,
$('#idOfMyElement').prop('disabled', false);
When it should be unclickable,
$('#idOfMyElement').prop('disabled', true);
The browser takes care of the cursor without needing CSS, and click events should react appropriately. Hope that was helpful!
Pointer events only respond correctly to a real pointer event. If you trigger click() function it fires in all times that you make it. Just add a condition reading if pointer events is active or replace it by a disabled attribute

Excessive Use of jQuery's preventDefault() and stopPropagation()

I was recently in a discussion with a work colleague about some differences in our coding practices, where I raised an issue about his excessive use of the two above mentioned methods in his event handlers. Specifically, they all look like this...
$('span.whatever').on('click', function(e) {
e.preventDefault();
e.stopPropagation();
/* do things */
});
He has made the claim that this is a good practice with no foreseeable blowback, and will improve cross-platform support while reducing unexpected issues down the road.
My question to you guys: If he's right, why hasn't the jQuery team implemented this behavior globally applied to all event handlers? In effect, my assumption is that he's wrong simply because the methods are available for independent use, but who knows... Your insight is much appreciated.
--
Update: I did a simple speed test, and there is a little drag caused by these two function, but nothing terribly noticeable. Still, among other things, a good reason to be deliberate in their use I think.
$('span.whatever').on('click', function(e) {
var start = new Date();
for (i = 0; i < 999999; i++) {
e.preventDefault();
e.stopPropagation();
}
console.log( new Date() - start );
});
The above logged ~9.5 seconds as is, and ~2.5 seconds when I took the function calls out of the loop.
I don't do the same thing as your colleague (pushing the 2 calls on EVERY event handler), but I do have the same practice of using these calls explicitely rather than a "return false;", and I believe that has made my life easier.
When I started with Jquery, I figured if I need to both stop propagation, and prevent default, I should just "return false", which I kind of did all over the place.
$('a.whatever').on('click', function(e) {
do_stuff();
return false;
});
But there was 2 problems I enventually encountered:
if do_stuff() has any critical error causing an exception, "return false;" will never be reached!!! The error will eventually be "nicely" swallowed by jquery; your event will bubble, and let the browser execute the default action. If you are in a single page app and a link was clicked, for all you know the page navigated away, and the entire app state went down the toilet (I've been there before).
I was too lenient with my return false: in many cases, I just needed a preventdefault(). "return false" was killing event bubbling and sometimes hindered my ability to perform another action higher up the dom hierarchy (or made some other plugin/libs I was using not work properly)
So I now prefer to be explicit. I litterally never use "return false;" any more. If I have an event handler that must either not propagate or not execute default, I deliberatly put that in my function FIRST, before any processing code. Whatever happens during event handling should NOT affect the fact that I do NOT want the default action to run, and/or event to not bubble.
And yes, that being said, I am also mindful of using just one of the 2 when required (or none at all in some cases). I do not just add both preventDefault() and stopPropagation() for no reason. Everywhere I manipulate an event in a handler, it is part of a conscious case-by-case decision.
It would be a problem if the element is part of a menu and the click event was supposed to bubble out and tell the menu to close itself too.
Or if a menu was open elsewhere and clicking outside the menu was supposed to bubble up to the body where an event handler would close the menu. But the element having stopped the bubble, prevents the menu from closing.
<div id="wrapper">
<div id="header">header
<div id="footer">footer
<div id="content">click this!!!</div>
</div>
</div>
</div>
$("#wrapper div").click(function(){
console.log( $(this) )
});
Please try clicked to div and show console...
And now added
$("#wrapper div").click(function(e){
e.stopPropagation()
})

Strange behavior of performing mouseover over a textarea in Chrome

I have a strange problem I can't wrap my head against. It is present only in Chrome. The library I'm using is Prototype 1.6.
Basically, I have two elements wrapped into a container element. First of the two children elements is visible, the second one is hidden. Inside the hidden element I have a textarea element. When I mousover the container element, the first child should hide, second one should show itself. When I mouseout, the behavior should be opposite. You can see it here, along with the bug :)
http://jsfiddle.net/gmM9m/2
For some reason, in Chrome when I mouseover the textarea, the elements start blinking because they constantly turn themselves on and off. Does anyone have any idea what causes this behavior and how can I circumvent it?
Thank you!
Luka
The closest I've gotten is adding the event to the callback function for the mouseout and making sure that it's coming from the element you want. It seems kind of hackish, but perhaps it's a bug in Chrome. I'm seeing it as well, but wong2 does not seem to be seeing it.
See my revision, still a slight stutter on initial mouseover.
http://jsfiddle.net/gmM9m/10/
I just run into similar problem and solved it with using jquery "mouseenter" and "mouseleave" event
see http://api.jquery.com/mouseenter/
This works for me.(I'm not familar with JQuery's observe method, so I use JavaScript's addEventListener instead)
$('container').addEventListener("mouseover", function(event){
$('front').hide();
$('back').show();
event.stopPropagation();
}, false);
$('container').addEventListener("mouseout", function(event){
$('front').show();
$('back').hide();
event.stopPropagation();
}, false);
The point is stopPropagation. Run it here: http://jsfiddle.net/RDXzR/

Jquery help with mouse events, events not unbinding

Any ideas why this doesn't work, or how to make it work? I want to remove the "onmouseover" and "onmouseout" events so they are basically disabled and at the same time change the background color. Then when the user clicks on another element I want to reassign the mouse events back to the element. Right now the onmouse events don't get disabled at all, the background doesn't change, etc.
Here's how I call the function:
Here's the function:
$(document).ready(function(){
$(".maximize").toggle(
function(){
$("#property_bg").unbind("onmouseover");
$("#property_bg").unbind("onmouseout");
$("#property_bg").toggleClass("body_bgcolor");
},
function() {
$("#property_bg").bind("onmouseover", function() {
swap_class("property_bg","body_bgcolor")} );
});
});
Thanks for the help.
Remove the "on" from the event names. Then it'll work.
on your events, take out the 'on'... just mouseover or mouseout...
I found out the real problem in the following two threads for anyone who comes along with a similar problem I will add them here:
How do I unbind "hover" in jQuery?
Why this unbind doesn't work?
The problem was solved by not hard coding the mouse events in the HTML, but rather binding them in the document.ready 1st. In order to "unbind" and event, the event has to be "binded" by jquery.
Also, "mouseover" didn't work for some reason I couldn't figure out, but when I put "mouseenter" and "mouseleave" as suggested in one of the posts above it worked. I've never heard of "mouseenter" or "mouseleave", but ... it works now.
Good luck!

JQuery .click() event troubles

Here's a snippet of my code:
$(".item").click(function () {
alert("clicked!");
});
And I have (hypothetically; in actuality it's far more complicated) the following on my page:
<img src="1.jpg" />
However, when I click the image, I do not get an alert.
What is my mistake?
Is your selector actually matching anything? Try using the jQuery debug plugin (http://jquery.glyphix.com/) and doing this:
$(".item").debug().click(function() {
alert("clicked!");
});
.debug() will log whatever is matched to the Firebug console (you are using firebug, right? :-) ) without "breaking the chain" so you can use it inline like this.
If that turns out correctly, there may be some issue with the browser navigating to "#" before it can show your alert. Try using the .preventDefault() method on the event object to prevent this behavior:
$(".item").click(function(evt) {
evt.preventDefault();
alert("clicked!");
});
First question - are you adding the element to be clicked dynamically? If it is,
you should use the live event since that will take care dynamically created elements.
http://docs.jquery.com/Events/live#typefn
Use bind.
$(".item").bind("click", function(e) { ... });
modifying the selector?
$(".item > img")
I had this problem recently after adding a context menu jquery plugin. The pluging was binding to the click event of the body and then unbinding click event - it seemed to remove all bindings to click event for all elements. Maybe a suggestion to turn off plugins or check you're not unbinding click for a parent element yourself.
The code you have posted is correct, so I suspect there's something else going on that you haven't considered.
Firstly, if there was an error somewhere (even not in that exact bit of code) that might cause it to stop working. Put an alert just after this line to check that it runs.
Check that no other elements are catching the event and stopping it from propagating. This has bitten me before in the past... If there's anything else handling a click which has stopPropagation() or return false in it, that might be the problem.
One thing I've found (though only with links going elsewhere) is that adding return false; in may help, if it's just firing the anchor off instead of evaluating the alert. I can't really say why this would be the case, but that's a solution I found to a similar problem recently.

Categories

Resources