|
Simon, we'll take a look at this and aim to have a fix for the next release.
I took a look at this and was able to reproduce fairly easily.
Tested on IE6. We've tried a few other JS trees (extjs for example) and they don't seam to crash the browser, even with a largish number of items. We'll take a look to see how they are manipulating the DOM and see what we can do about it.
Hi,
I also encounter the 100% CPU problem with IE (6 and 7) when the tasklist macro is displayed on a page. Regards, I can confirm that the tree control freezes IE 6 (XP) at about 300 pages, with the browser noticeably sluggish after about 100 child pages expanded underneath a single parent.
The control in the Location section of the Edit Page screen is also affected. As this is a major blocker for us, I've spent a little time looking at the script. How about using asynchronous timers instead of loops to load and update? jQuery's Treeview seems to work quite well by parsing the DOM tree, so another idea would be preloading to a hidden container. We have fixed this so that it no longer hangs. However, due to IE slowness (it's js engine is much slower than other browsers) it is still quite sluggish with 1000+ nodes when doing a drag/drop.
Reopening because Safari 3.1.2 hangs when viewing tree view irrespective of number of pages in space
Safari bug fixed for 2.10 rc2
Tree view now works as expected on Safari 3.1.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Thanks, Simon.