I'm having trouble recreating the issue in jsbin without giving away project-specific details (I'm using JSON from an API), but I'm running into an issue that I can't seem to get around, and would really appreciate any help or insight.
I start with the following markup:
I have a blank unordered list.
<ul id="results-list">
<!-- it is blank for now, and will be populated via jQuery -->
</ul>
And also an input.
When that input has been submitted, I run some code to populate #results-list with data, based on a JSON response. All's well. In that population of the data, I embed links that go nowhere, to make it like a sidebar navigation (user clicks on a link, and the main content area's content changes accordingly). This works fine the first time around.
Then, I've got an anonymous function running inside of .live() for clicking on those links in #results-list.
$("#results-list a").live('click', function(){
// populate the main content area with the correct information.
});
Okay, so that works just perfectly the first time around. Once the user changes what's in the input, and resubmits the form, all of the items in the main content area change accordingly, but there are two of them. If they resubmit the form again, there are three. And so on.
So, the main content stuff is duplicated X times, with X being the number of times the form has been submitted.
I realize this is a somewhat vague question, but I wanted to see if anyone had any pointers as to what may be going on? This is all happening within a normal $.getJSON method call.
Any ideas?
If you call the live function after each post, jQuery will just keep adding event handlers to the DOM, so the handler will get called multiple times. To get round this, either just call the live function once, or if you have to set up event handlers after each post use unbind and then a bind function (i.e. bind or something more specific like click).
Related
I have built a pretty simple WordPress blog however nearing the final stages I have run into a small problem that I cannot figure out for the life of me!
The site is http://lincsbusiness.co/, its running an ajax request so when you get the the bottom on the page its calls the next issues from the next page. Pretty simple.
However, if you follow these step you will be able to see the problem that I am talking about.
Refresh the home page
Expand the first issue, so you can see the sub headlines
Scroll to the bottom and till you get to issue 12
Try and expand that, and you will notice that the expansion bounces.
I am using the jQuery call back feature so after the AJAX request has finished it allows the jQuery to keep working.
And to stop having duplicate piece of jQuery for one before the event and one after, I have given the first four issue in the list unique identifiers, which are different to the one in the callback.
Here is the code I am using
jQuery(document.body).on('click', '.before-load', function(event) {
jQuery(this).closest('.thepost').find('.thepost-entry').slideToggle('slow');
});
And I use another piece, which is identical but just uses the '.after-load' class, just so I can separate them.
If you can replicate the issue and see whats going on, and have a potential fix. that would seriously save me my sanity.
Thanks
I have a feeling this is because you are re-adding the listener for the click each time you expand the page, so probably every time you load more posts, the next post you click bounces +1 times.
I'd recommend stopping any other jQuery execution, removing the 'click' handler, then letting the ajax call expand the page...and then re-adding the 'click' handler to each post.
I have a pretty complex system with a few AJAX calls which render different templates into other templates in PHP.
One of these templates is a edit form for my entity. This form is rendered hidden into my website until a button was clicked, which will then fire a jQuery toggle() to switch out a part of my site for this edit form.
This works fine until the user is using the jQuery UI slider on my site.
What happens if the user navigates within the slider is that parts of my site will be reloaded with AJAX.
When the button for the toggle() then will be clicked the animation goes of as often as the slider was used (so if the slider was used 4 times the toggle will animate an switch out the 2 elements 4 times).
I debugged through it and couldn't find the mistake, i can't provide a jsFiddle which could rebuild the situation nor can i give access to the site. The click function will be fired only once, so i really can't explain why this is happening.
To mention is that i have 3 buttons which will trigger this event:
#poi_edit_ajax will be shown when the slider was used in the template which will be rendered per AJAX.
#poi_edit_first will be shown by first access to the site and nothing has been reloaded per AJAX.
#poi_edit_last will be shown so the user can come back from the edit view
The Javascript is the following:
$("#poi_edit_ajax").click(function(){
$(".toggle_edit").toggle('slow');
});
$("#poi_edit_first").click(function(){
$(".toggle_edit").toggle('slow');
});
$("#poi_edit_last").click(function(){
$(".toggle_edit").toggle('slow');
});
I don't think that somebody can give me a solution with just this information, but that's everything i can provide now, so my Question now is simply if it is possible to tell the toggle() function from jQuery to only run the animation ONCE PER CLICK.
I don't think that jQuery one() can be used for this, because so the click event could only be used once per pagevisit.
EDIT
According to the comment, i tried out if multiple event handlers will be registered within the AJAX calls, which is true.
The code to fix this is simple:
$("#comment_first").unbind("click").click(function(){
$('.toggle_information').toggle('slow');
});
$("#comment_last").unbind("click").click(function(){
$('.toggle_information').toggle('slow');
});
$("#comment_ajax").unbind("click").click(function(){
$('.toggle_information').toggle('slow');
});
I just need to unbind the Lister before bind it again, else they're gonna stuck and multiple Listeners will react to the click event!
You are probably binding the Click event multiple times (by loading javascript through the AJAX calls). Make sure you bind the Click handler (which triggers the toggle()) only once.
Take a look at this answer: https://stackoverflow.com/a/969011
A (slightly modified) quote from that answer, for quick reference:
function alertEvent() { alert("test"); }
$(".ajax").bind("click", alertEvent);
//When you want to ensure it won't happen twice...
$(".ajax").unbind("click", alertEvent);
$(".ajax").bind("click", alertEvent);
This method will only remove the event you specify
I'm working on a web app in ASP.NET 2.0 that involves several GridView elements. When users click one of the rows in a grid, that row needs to show its selection by changing color. Each row has attributes set to identify its record type and unique ID:
<tr data-elementType='myType' data-myID='12' onclick='selectionFunction();'></tr>
I accomplish the selection through a javascript onclick handler on each row that calls a function that:
Removes the selected class from the previously selected row
Adds the selected class to the new selected row
Updates the value of a hidden field with the new selected unique ID so server-side code can know which element to perform an action on when a button is clicked (view, delete, etc).
One of these grids now has just over 700 records in it. In Firefox 3.6, the selection operation on this grid is horribly slow (about two seconds); in other browsers (even IE 7 and 8) it's not a problem. I put console.log statements at the start and end of the selection function, and in Firebug they show up very fast at the end of the delay, suggesting that it's not the selection function that is slowing things down. I used the profiler in Firebug and it says that "createCallback", which is defined in one of the "ScriptResource" script files generated by ASP.NET, is taking the huge majority of the time. What is createCallback and why does it seem to be so slow in Firefox 3.6? Is it a bug in FF, or is it a problem I can solve?
UPDATE: I am, of course, using jQuery to add/remove classes from the rows. I've been working with jQuery 1.5.2 and jQueryUI 1.8.11, but I updated to the latest (1.6.2 and 1.8.14 currently) to no avail. I tried putting a breakpoint in createCallback to see where it's getting called, and when it breaks there it's several frames down in the call stack from my call to removeClass. Here is what the stack looks like in Firebug:
createCallback() - in ScriptResource.axd?......
wherever possible trim: trim ? function(text=" ") - in jQuery
removeClass(value="selectedRow") - in jQuery
removeClass(classNames="selectedRow", speed=undefined, easing=undefined, callback=undefined) - in jQueryUI
selectionFunction() - in my .aspx page
onclick
I don't understand why jQuery is triggering an ASP.NET generated function like this.
UPDATE 2: some more investigation has provided some more detail. It seems that this "createCallback" function is getting called A LOT when I use addClass/removeClass, and it's happening in both Firefox 3.6 and Firefox 5. I found the same function in Chrome and put a breakpoint on it, and it's not getting called at all, so this seems to be a Firefox thing. I put a breakpoint on the function/line in question and selected a row, and the breakpoint got it 57 times. Only the first two involved me calling removeClass and addClass; the rest had createCallback several times in the callstack, and sometimes BeginRequestEventArgs too. I've noticed it getting called also when I mouseover other jQueryUI stuff on the page (tabs), when jQuery uses addClass and removeClass. But why is it getting called so many times when I do work on tr elements?
I'm changing the title and tags to reflect the real issue.
UPDATE 3: createCallback is getting called about the same number of times whenever I select a row in any of the grids, even if it only has 6 rows in it. But in that case it's not a performance problem, and the profiler shows it only taking about 30% of the execution time, while it's at least 80% when I profile selection on the larger table. So createCallback seems to perform worse when it's used in the context of more stuff visible on the page. But it still seems like jQuery shouldn't cause a call to createCallback, especially since I couldn't fine any references at all to it in Firebug's script search. And it appears to only get called in Firefox!
Note also that all of these grids are on the same page, but only one is visible at once, because I'm using jQueryUI tabs.
UPDATE 4: I managed to get something similar up on jsFiddle as requested. See here. In Firebug, find createCallback and set a breakpoint (just below my click handler in the script, where it begins with Function.__typeName = "Function"; Function.__class = true; Function.createCallback = function (b, a) and reload the page. I get a lot of calls to it.
I have very little knowledge of ASP however it sounds like your problem is purely client side.
Declaring on "onclick" event for each row is not the most sensible way to handle the rows being clicked. Especially when you get into the quantity of rows you're talking about (~700+).
A better way would be to add a click event handler to the table and figure out what is clicked when it happens. I have written an application where a similar size table is being handled and we're not seeing anything like the lag you're experiencing upon click. there may well be other factors causing your click events to slow down however I would still suggest something along the following lines is worth implementing in any case:
$(function(){
var rowSelectedClass = 'rowSelectedClass';
$('#myTableID').click(function(e){
if(e.target.nodeName === 'TD'){
var $tr = $(e.target).parent();
$('tr.' + rowSelectedClass).removeClass(rowSelectedClass);
$tr.addClass(rowSelectedClass);
// ....
// Do whatever else you want to do when the row is clicked
// ....
}
});
}
A good article to take a look at which advocates this method (and a few other handy jQuery tips) can be found here: http://www.artzstudio.com/2009/04/jquery-performance-rules/#leverage-event-delegation
Also worth noting that if your table has rows added dynamically after the page is loaded then consider using .live() instead of .click().
UPDATE # July 28th 2011 9AM
Having taken a look at the source more closely, I think the supposed calls to "createCallback" are a red herring. The line within your original jsFiddle source which contains the "createCallback" function is actually a really long string (~90,000 characters) of javascript. I think the fact that "createCallback" is the first function within that string is misleading Firebug's profiler. When you profile your original page's load, there are 2261 calls and as you said, there appear to be lots to "createCallback"
I've "beautified" (hate that phrase) this long JS string via http://jsbeautifier.org/ to make it readable and re-added it to a jsFiddle page. You can see it here: http://fiddle.jshell.net/KvpmE/1/show/. Now when you profile this page's load you'll see a similar number of calls (2267 - not sure what happened to the other 6!) but importantly not a single one to "createCallback".
I still can't offer any solution though because essentially I've been unable to re-create your original issue which was that there was a 2 second lag in Firefox 3.6 when clicking a row.
Is this still the problem you're having?
Could you try and see whether you can re-create the problem within the updated jsFiddle page?
Also try and add the de-minified JS to your page to see if it helps you track down the actual functions being called when the row is clicked and therefore where the lag is taking place.
Mr. Jefferson,
It really sounds to me like you're actually performing a postback without knowing it. Have you set a breakpoint on the server side yet to see if something is inadvertently firing your update panel? It really sounds like some kind of postback is happening that is requiring a reload of dependant scripts.
I say this because 1) the problem you're having makes absolutely no sense - you're 100% on the money with JQuery and the ASP.NET Client Framework not even knowing they're neighbors in this case, and 2) the BeginRequestEventArgs instantiation sounds like the PageRequestManager thinks it should be doing something in response to your triggers... You could also try breaking out Fiddler and just doing a quick sanity check to make sure some update panel of yours isn't firing. There should be no HTTP traffic during the ops you're describing.
Sorry if this is an absolutely useless post for you, but with all of the work you've gone through to troubleshoot the client side it can't hurt to set a server side breakpoint just to do a quick sanity check / occam's razor...
Good luck - happy coding.
B
Function.createCallback is used a lot internally by Ajax Toolkit and maybe its being called within your code unintentionally too http://msdn.microsoft.com/en-us/library/dd409287.aspx.
Since this is browser dependent, I would check code paths that are executed based on a specific browser.
Another clue to look for is if you're having any Ajaxtoolkit components for the grid or its individual rows as that would explain the increase in number of calls with the increase in rows.
There is also Type.createCallback function (http://msdn.microsoft.com/en-us/library/bb397568.aspx) so if you have any Type related code or methods, I would check those.
I understand that it's possible (and I have done it) to return javascript and jQuery code (which of course is javascript... hehe) when doing a jQuery ajax request and running it once it reaches the browser.
What I'm wondering is if I return data, let's say a form, that I present in a dialogcontainer. What should I delete myself once that container is closed by the user and what does jQuery understand by itself to delete.
My idea is to build a page that require very little page reloads and once a user clicks on a button I present them with a form or some other content fetched from the server. Alongside that content the javascript required by that content should also be retrieved. But if the dialog is closet I don't want tons of javascript to be left eating memory. Any way around that?
You could unbind the click event that does the ajax call. If nothing is going to change if they open the dialog again, then this should be fine. While you unbind it you could then change it more a toggle type of thing (Show/Hide), since the javascript and HTML should already be set now.
But it really depends on what you are trying to do. The ajax call will only happen once they click it. It's not going to continually refresh unless you want to. So there should be nothing in the background running except for binding events like click, which is ok.
I've tried so many different possibilities to achieve what I feel like should be a simple code execution. I am loading DOM objects from the server via .load(). One of the loaded items is an input text box with a date in it. I want to load the jdpicker (a plugin datepicker) when I click on the input box. Due to the behavior of .live() and .delegate(), even when I use .die() or .undelegate() respectively, I can't get the popup datepicker to behave normally. It either pops up, allows me to click one object in the window and then immediately closes (I cannot navigate through the months, years without the window closing), or the window pops up and every subsequent click re-executes the code producing multiple instances of the datepicker.
I've tried different combinations of .live(), .delegate(), .one() with no luck. I've tested the datepicker in the main window and know that it works fine there. I could post code, but am not sure which of the ten different attempts I've made would be the best example. I can show my latest attempt.
Does anyone have a suitable example for this? Thanks!
Update
I've edited the code to read as follows:
$("#edit-entry").load("/edit/", { id:id }, function(){
$('.jdpicker').one('click', function(){
$(this).jdPicker();
});
});
This is hinging on becoming the complete answer. The datepicker is no longer calling multiple instances, which is good, but I still can't navigate it's controls (month, year selection). If I click the next month, it will load and close. The next time I click it, it re-opens on the next month. So, it does work, but is certainly not desirable. Any suggestions?
You just can't do that with "live" or "delegate". The fact of the matter is that you'll need to apply your plugin initialization explicitly after ".load()" succeeds.
edit — the change you've made is probably not going to work. Here's your code in English:
"Fetch content from the URL '/edit/' and deposit it into the element with id 'edit-entry'. When that content has been received, then bind a one-time event handler to the "click" function of all elements with class 'jdpicker'. In that event handler, set up the 'jdPicker' functionality for the element."
Instead, what you should be doing is just calling the jdPicker setup directly instead of setting it up so that the user has to click on the elements first.
$("#edit-entry").load("/edit/", { id:id }, function(){
$('.jdpicker').each(function(){
$(this).jdPicker();
});
});