javascript函数& quot; createCallback& quot;在Firefox中使用addClass/removeClass时被调用& gt; 50次 [英] javascript function "createCallback" called >50 times when I use addClass/removeClass in Firefox

问题描述

我正在使用ASP.NET 2.0中的Web应用程序，其中涉及几个 GridView 元素.当用户单击网格中的某一行时，该行需要通过更改颜色来显示其选择.每行都设置了属性以标识其记录类型和唯一ID:

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>

我通过每行调用一个函数的javascript onclick 处理程序来完成选择:

I accomplish the selection through a javascript onclick handler on each row that calls a function that:

• 从先前选择的行中删除 selected 类
• 将 selected 类添加到新的选定行
• 使用新选择的唯一ID更新隐藏字段的值，以便服务器端代码可以知道单击按钮(查看，删除等)时要对哪个元素执行操作.

这些网格之一中现在有700多个记录.在Firefox 3.6中，此网格上的选择操作非常慢(大约两秒钟)；在其他浏览器(甚至是IE 7和8)中，这也不是问题.我将 console.log 语句放在选择函数的开头和结尾，在Firebug中，它们在延迟结束时很快显示，这表明不是选择函数使事情变慢了.我在Firebug中使用了探查器，它说，在ASP.NET生成的"ScriptResource"脚本文件之一中定义的" createCallback "占用了绝大多数时间.什么是 createCallback ?为什么在Firefox 3.6中它看起来这么慢?是FF中的错误，还是我可以解决的问题?

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?

更新:我当然是使用jQuery从行中添加/删除类.我一直在使用jQuery 1.5.2和jQueryUI 1.8.11，但是我已更新到最新版本(当前为1.6.2和1.8.14)，但无济于事.我尝试在 createCallback 中放置一个断点，以查看它在哪里被调用，当它中断时，从我对 removeClass 的调用的调用堆栈中向下停了几帧.这是Firebug中的堆栈外观:

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()-在ScriptResource.axd中吗?……

createCallback() - in ScriptResource.axd?......

尽可能修剪:trim?function(text =")-在jQuery

removeClass(value ="selectedRow")-在jQuery中

removeClass(classNames ="selectedRow"，speed = undefined，easing = undefined，callback = undefined)-在jQueryUI中

removeClass(classNames="selectedRow", speed=undefined, easing=undefined, callback=undefined) - in jQueryUI

selectionFunction()-在我的.aspx页面中

selectionFunction() - in my .aspx page

onclick

我不明白为什么jQuery会触发这样的ASP.NET生成的函数.

I don't understand why jQuery is triggering an ASP.NET generated function like this.

更新2 :更多的调查提供了更多的细节.似乎当我使用 addClass / removeClass 时，这个"createCallback"函数被称为A LOT，并且在Firefox 3.6和Firefox 5中都发生了.我发现了相同的函数在Chrome中插入一个断点，并且根本没有调用它，因此这似乎是Firefox.我在有问题的函数/行上放置了一个断点，并选择了一行，断点得到的次数为 57次.只有前两个让我调用了 removeClass 和 addClass ；其余的在调用栈中有几次 createCallback ，有时也有 BeginRequestEventArgs .我注意到，当我将鼠标悬停在页面(选项卡)上的其他jQueryUI内容上时，当jQuery使用 addClass 和 removeClass 时，它也会被调用.但是为什么当我处理tr元素时为什么会被调用这么多次?

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 :每当我在任何网格中选择一行时，即使其中只有6行， createCallback 都会被调用相同的次数..但是在那种情况下，这不是性能问题，探查器显示它仅占用大约30％的执行时间，而当我在较大的表上探查选择时，它至少占了80％的执行时间.因此，当 createCallback 在页面上可见的更多内容的上下文中使用时，效果似乎会更差.但是，看起来jQuery似乎不应引起对 createCallback 的调用，尤其是因为在Firebug的脚本搜索中，我根本无法对其进行任何引用.而且似乎只能在Firefox中调用！

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!

还要注意，所有这些网格都在同一页面上，但是一次只能看到一个网格，因为我使用的是jQueryUI选项卡.

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.

更新4 :我设法按要求在jsFiddle上进行了类似的配置.请参见此处.在Firebug中，找到 createCallback 并设置一个断点(在脚本中单击处理程序的下面，它以 Function .__ typeName ="Function"; Function .__ class = true; Function.createCallback开头=函数(b，a)并重新加载页面.我收到了很多调用.

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.

推荐答案

我对ASP的了解很少，但听起来您的问题纯粹是客户端.

I have very little knowledge of ASP however it sounds like your problem is purely client side.

声明每一行的"onclick"事件不是处理被单击的行的最明智的方法.尤其是当您进入要谈论的行数时(约700 +).

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+).

更好的方法是将click事件处理程序添加到表中，并确定发生事件时单击的内容.我编写了一个应用程序，其中正在处理类似的尺寸表，但看不到单击时遇到的滞后现象.可能还有其他因素导致您的点击事件变慢，但是我仍然建议在任何情况下都应执行以下内容:

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
            // ....

        }
    });
}

可以在此处找到推荐该方法的倡导者(以及其他一些方便的jQuery技巧)的好文章:

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

还值得注意的是，如果您的表在页面加载后已动态添加行，则考虑使用 .live()而不是 .click().

Also worth noting that if your table has rows added dynamically after the page is loaded then consider using .live() instead of .click().

更新@ 2011年7月28日，上午9点
更仔细地查看了源代码之后，我认为所谓的"createCallback"调用是一个红色鲱鱼.原始jsFiddle源代码中包含"createCallback"函数的行实际上是一个很长的javascript字符串(约90,000个字符).我认为"createCallback"是该字符串中的第一个函数的事实误导了Firebug的分析器.剖析原始页面的负载时，有2261个调用，正如您所说，"createCallback"似乎有很多

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"

我通过 http://jsbeautifier.org/使其可读并重新添加到jsFiddle页面.您可以在这里看到它: http://fiddle.jshell.net/KvpmE/1/show/.现在，当您配置此页面的负载时，您将看到相似数量的呼叫(2267-不确定其他6个发生了什么！)，但重要的是，没有一个呼叫"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".

尽管如此，我仍然无法提供任何解决方案，因为从本质上讲，我无法重新创建您的原始问题，即单击行时Firefox 3.6中存在2秒的延迟.

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?

您能否尝试看看是否可以在更新的jsFiddle页面中重新创建问题?

Could you try and see whether you can re-create the problem within the updated jsFiddle page?

还尝试将已缩小的JS添加到页面中，以查看它是否有助于您跟踪单击行时的实际调用函数，从而了解发生滞后的位置.

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.

这篇关于javascript函数& quot; createCallback& quot;在Firefox中使用addClass/removeClass时被调用& gt; 50次的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！