I just spent a while tracking this down, so I thought I would post it
here in case anyone is searching the archives in the future.

I use blockUI to block containers while they are getting loaded via
ajax. I found that in many cases, the call to block was going very
slow - sometimes taking 5 seconds just to put up the block message!

What I traced it down to is blockUI attaching events to every <a> and
<input> within the blocked element. In my case, I had a tree structure
with hundreds or thousands of nodes, each with an anchor in them. The
binding of 5 events to every element caused the unbearable lag.

My application is an internal webapp, and I didn't need this
functionality. So I made the change below in the page where it was a
problem and now the interface responds much quicker. I would recommend
making this an option in blockUI, perhaps documenting it as a caveat,
or maybe even consider not doing this kind of action by default.

// Matt - 2007-11-12
// The "bind" call in BlockUI is extremely inefficient when there are
large numbers of anchors or inputs within the
// blocked element. We're going to over-write it here because we don't
even care about the functionality it is
// trying to add.
    // bind/unbind the handler
    $.blockUI.impl.bind = function(b, el) {
        var full = el == window;
        // don't bother unbinding if there is nothing to unbind
        if (!b && (full && !this.pageBlock || !full && !el.$blocked))
return;
        if (!full) el.$blocked = b;
//        var $e = full ? $() : $(el).find('a,:input');
//        $.each(['mousedown','mouseup','keydown','keypress','click'],
function(i,o) {
//            $e[b?'bind':'unbind'](o, $.blockUI.impl.handler);
//        });
    }


Matt Kruse

Reply via email to