Ok, something we have been struggling with for months and drove many of us at KWizCom a bit crazy…

It is hard to explain, so I’ll try my best:

In our internal portal, we are using SharePoint 2010.

In our current bug tracking list, we use a SharePoint list similar to the issue tracking, every time to click on a new item or Edit item – the page loads quickly enough, but it is stuck and not responding for up to 10 seconds sometimes.

After 10 seconds, the page completes loading, rich texts load their toolbar, and the ribbon starts working.

We have over 4000 items in that list, and the problem just becomes more and more of an issue as the list grows.

After a lot of trial and error, I finally managed to pin point the code that makes the browser stuck:

It is a javascript file called “groupeditempicker.js”, and more specifically, a function called “GipInitializeGroup”.

After a little research, I realized this code is a part of the SharePoint out of the box multi-Lookup column picker (the left-right-boxes like we call it), which was looking up items from the current list as related issues.

Once I converted this lookup into our Cascading Lookup with “edit on demand” flag, which was designed to work on large list lookups – the problem was solved immediately.

Not sure how many people out there will encounter this issue, and from them how many will find this post – bug if you did, leave me a comment! I am curious to know if it was just us.

Happy SharePointing,

Shai.

Edit: A link to KWizCom cascading lookup product. This product can show multi - lookup as a grid control with paging and checkboxes, and supports a mode we call "edit by request" which means if you edit the item - this field will display the view mode of the current value. If you want to modify it, you have to click on the edit button to change it into edit mode. This feature is very useful for huge lookup lists that you do not modify every time. Cascading lookup page