admin/build/menu-customize/navigation takes a long time to load in IE7

Just tried this on my box which has IE7 on it and no issue at all. This is with a refresh from CVS that I just did. Are you running XP or Vista. (I'm on Vista).

No problem here. Are you sure you're using the most updated version of IE 7? That page is using some javascripts to move the menu-items up and down; "ajax" style. Try using the latest javascript files from CVS:
/drupal/misc/jquery.js
/drupal/misc/drupal.js
/drupal/misc/tabledrag.js
/drupal/misc/tableheader.js

Have just tried it on my XP box. It seems to hang for approx 15 secs and then renders the page correctly. The issue seems to be that all of the javascripts look like this

 <script type="text/javascript" src="/misc/jquery.js?o"></script>

Firefox also throws an error in the console for the system css.

Confirmed, causes IE7 to freeze for a few seconds and then come back to life. And don't even try to drag the administration menu— this will cause it to freeze again and take up to 30 seconds to come back to life. It seems to occur on whichever menu administration page has the "administer" item on it— if the administer item is moved to primary links, primary links becomes the one that freezes. Maybe this suggests that IE7 doesn't deal well with a lot of menu items? Perhaps the tabledrag js overloads it somehow (not that that's very hard...)

I'm not seeing this bug with Vista RC1 Refresh and IE7 7.0.6001.17128. Why do I feel some frustrating times ahead for this thread...

I think the first thing in order is to confirm whether this bug with IE7 is on both XP and Vista or just XP. I seem to recall some differences in what/how javascript is handled in IE7 depending on whether the OS is XP or Vista.

#7: Confirming, I'm on XP.

Using IE7 on XP, I also got the long delay when first loading the page. I did not experience any delays rearranging the menus, including the Administer menu.

Does it help to disable javascript?

1. From the Tools menu, choose Internet Options... .
2. Click the Security tab.
3. Click Custom Level... .
4. Scroll to the "Scripting" section of the list. Click Disable or Enable.
5. Close and restart your browser.

Extra step information for #10:

2b. Select the Internet zone
4. Scroll to the "Scripting" section of the list. Set Active Scripting = Enabled or Disabled.

@greggles: Disabling javascript immediately fixes the issue. Loading the page shows no delays and it gracefully degrades to showing the weights for the menu items.

I have a similar problem with FF on OSX.

I tried to clean up my navigation menu, FF froze and popped up a message box stating that the script has stopped responding, and offering me the choice to continue, debug or stop the script. By continuing, I would receive the message again before the script would finally end correctly.

I disabled JS, and performed all the actions without drag 'n drop.

With the recent release of jQuery 1.2.2, there are some performance improvements - these may have a positive effect.

I will apply the jQuery 1.2.2 patch and see what happens.

Paddy.

Probably worth checking this against rc1, or with tableheader.js hacked out - I'm guessing it's another side effect of the changes to that. I definitely tested the menu page drag and drop when it went in, so this feels like a new bug.

Yes, I'm experiencing the same problem here with Vista x64 and IE7 7.0.6000.16575. We obviously really built a killer script :)

No problem with disabled JavaScript, neither in Firefox 2.0.0.11 and Opera (9.24 and 9.25).

OK with 7.0.5730.11 it's taking about 3-4 seconds for me (a bit sluggish, but acceptable), and FF2 is fine. Without tableheader.js it's only a second or so, it's one of the longer tables in core, so wondering if it's the cloning that's taking time (although I thought we only cloned the header now).

For me (FF2, 500MHz Pentium, Linux) it takes about 30 seconds, which is awful, but I already learned to stop complaining. JavaScript is slow. Google Maps is no better with many dots. Seems to be somehow 'normal' nowadays. :-/

JirkaRybka: can you check whether this is primarily due to tabledrag.js or tableheader.js?

For the folks who can reproduce this, it would be helpful if you could try out using different versions of core to figure out when this regression was introduced.

The best way I know to do this is to use a cvs checkout for your installation and then in the root of it you run:

cvs up -D "01/17/2008"

That will update your code to what was in CVS on a specific date. The 17 is for the day of the month. So, start on the 17th, test for the problem (since it is JS, be sure to clear the browser cache), and keep stepping back in time until the problem goes away. This will pinpoint it to the one day where the change happened which makes it much easier to find a solution.

Subscribing

For what it's worth, this issue does not occur with IE6 on XP. Response is slower and clumsier than in Firefox, but does not impact usability as dramatically as reported on IE7. Which I am unable to test, so unfortunately I can't help pinpoint the CVS commit that caused this.

I was able to do a quick check against RC1 and IE7 on XP did not exhibit the same behavior. RC2 exhibits the behavior. So it's definitely something between those two. I don't have time right now to track through all of the commits to see where it broke. If no one else does, I'll work on it later today.

Hmm, I am using XP service pack 2, IE 7.0.5730.11, and and a fresh out cvs Drupal 6, and I have not been able to replicate this issue.

My apologies, the long time which I remember from another testing (and mentioned in the #16 quick comment) was apparently only due to big amount of menu items (>200) on my site (I might call it usability issue still, but unrelated here). With a fresh install, the page is quite snappy on my FF2/Linux, even on the 500MHz machine, so I must say that the problem doesn't reproduce for me, most probably. Dragging the Administer menu item around takes only just 10 seconds delay, which is acceptably snappy in terms of what's common on that machine.

But however, my experience from the past say: The highly relevant information here is:
- Browser version
- Time (delay) on site load, and on dragging a big menu subpart (Administer)
And also:
- Size of menu / dragged subpart (items)
- Hardware speed
Only then the provided info will make a sensible comparison IMO.

Running 7.0.5730.13 on XP pro(sp2) within VMWare on Leopard. MacBook Pro C2D 2.2Ghz, 512MB 384MB of RAM dedicated to XP.

Initial load has a delay of about 4-5 seconds but I think that's to be expected with all the table rows being processed for drag & drop. After that, no further delays. Drap & drop works without delays.

Everyone, please test with Garland to rule out custom themes with their own js embedded. This includes .htc files attached through style sheets.

If everyone tested with a fresh install, that will help narrow down the issue.

It would help to distinguish between tabledrag.js and tableheader.js, first renaming one and then the other to know which of them affects more the performance.

There are 2 things here.

tabledrag.js does take it's time with IE7 on it's own especially when dragging a huge group, e.g. "Administer" menu along with its children.

tableheader.js takes up cpu time on initial load, when the document length changes (vertical scrollable area) or when the window is resized. This is to calculate the floating headers cell widths and overall width so it matches up with the table.

Ideally tableheader.js should eat up noticeable amounts of cpu time only when there are a lot of tables with lots of cells and one of the three events or changes mentioned occurs.

I'm guessing here but something about the initial drag of the rows is triggering the header calculation since the document length changes with the fading in of the text notification of:

"* Changes made in this table will not be saved until the form is submitted."

That plus the large amount of dragable rows is making IE7 stall. I tested again and noticed the initial drag causing a 3 second delay. After that it's fine.

Why the great delay for some of us here? Dunno but it might be related to this.

Ok, if we are just talking about the page taking a while to initially load, I am seeing that. It takes about 6 seconds to show up on my Pentium D 2.8Ghz box with 2GB of RAM. But I wouldn't call that freezing. And I don't think this one is really critical.

Desktop, AMD 64, 3gig ram. I get 3-4 second page loads tops. The tracker and search take longer than this on my live site (and used to take 30 seconds on drupal.org at one point), so I agree it's not critical and am taking it down a notch. With both tableheader.js and tabledrag.js, big tables are going to take a long time to process - only way to deal with that is either make them optional or remove one, neither is likely at this late stage.

By VeryMisunderstood's description I think it is critical. Could you open up tableheader.js and empty out all the code? Just to rule out the interaction with the two scripts. Each of the two scripts on its own will have a cpu hit to varying degrees but together it might be too much or IE.

And do you have any browser extensions installed?

Could you test with this file?

http://cvs.drupal.org/viewvc.py/drupal/drupal/misc/tabledrag.js?revision...

That's the version before the big changes related to CCK: http://drupal.org/node/200370

I don't think this is ready to be closed quite yet. Other people have confirmed the long load times.

Since so many have posted, I'll summarize what I've seen so far:

XP Pro SP2
IE 7 7.0.5730.13
Intel Core Duo T7200 (2GHz)
2GB RAM

All D6 installations are completlely default installations. No contrib modules have been installed. No additional core optional modules have been activated.

Tested against:

• RC1 - No speed issue; initial page load is ~2-3 seconds
• RC2 - Initial page load takes between 20-30 seconds; no speed issues observed when moving menus
• HEAD (as of this morning) - Initial page load takes between 20-30 seconds; no speed issues observed when moving menus

This seems like a major performance issue. True, it doesn't break the site, but for a browser that IIRC has 20% share right now to have this issue, it could generate a lot of support requests. If this is something we can't or won't fix, then it should be documented and pointed out to admins so they know what to expect.

I have not had a chance to go back and try the various suggestions for figuring out which script, or which version of each script introduced the performance issue. Unlike the OP, this is not a browser cache issue for me. I'm well acquainted with clearing the cache to perform this testing (and thanks to everyone on all the .js issues for reminding us to do so).

I don't know if this helps, but I have just downloaded the latest nightly build of drupal-6.x-dev.

drupad-6.x-dev

the page (admin/build/menu-customize/navigation) loads almost immediately. The page remains un-responsive for approx. 3 to 5 seconds after which all the drag 'n drop code is applied to the entire table and functional.

drupal-6.0-rc2

the page (admin/build/menu-customize/navigation) takes approx. 30 seconds to load. The browser remains unresponsive for the entire time.

I am running

• Dual 2 GHz G5 with 2 GB RAM

Paddy.

Here are my tests results for several combinations of tabledrag / tableheader.
WinXP, IE7.0.5730, P4 2,66GHz, 1Gb Ram

Measured times are between clicking the link and being actually able to do something on the new page (scrolling down, for instance).

disabling both tabledrag and tableheader : 7 sec

Files from current HEAD
- tabledrag.js + tableheader.js : 19 s (thats +12 s overhead)
- tabledrag only : 8 s (+1 s)
- tableheader only : 13 s (+6 s)

Individual overheads don't add up to the total overhead, so it looks like a nasty conbination...
Not sure what to do with that, but it looks like tabledrag bahavior is applied first, then tableheader.

Swapping tabledrag with the version pointed in #34 (pre-CCK changes - http://cvs.drupal.org/viewvc.py/drupal/drupal/misc/tabledrag.js?revision...) does not really change the timings above.

Swapping tableheader with the version before http://drupal.org/node/194590 (http://cvs.drupal.org/viewvc.py/drupal/drupal/misc/tableheader.js?revisi...) lowers the values by approx 3 secs.

FF3 timings consistently stay around 8 sec.

One solution might be to add a circular progress widget (like the one in the autocomplete, but bigger and with the screen greyed out). This gives the users feedback that their site is working to give them the ultimate admin experience but it might take a little while to get there.

A little more investigation with firebuglite shows that the tableheader's tracker() function can be quite slow.

Called on page load (sometimes twice, not sure why), each call takes about 3-4 sec
Called on each scroll event, takes 3-4s for the first step, 0 for the next steps
Called on each window resize event, takes 3-4 sec on each step

Above timings are on IE7 with the setup decribed in #41.

The current code in tableheader's tracker() could be optimized a bit (we re-run $ selectors that could be saved before the loop), but this doesn't bring significant improvements.

more profiling point the issue to :
e.vLength = $(e.table).height();
takes ~100 ms in FF3, ~1500 ms in IE7

$(e.table).width()
takes ~100ms in FF3, ~1500 ms in IE7

$('th', e.table).eq(cellCount).width();
performed once per cell in the header
takes 1 ms in FF3, 47 ms in IE7 - that's 47 times more, but not *that* much of an impact, you don't get tables with 10s of columns.

And there you get your overall 3-4 seconds :-(
JS / jquery gurus welcome to take it from there...

replacing those height() and width() calls with .clientWidth, .clientHeight properties does seem to work, and reduces execution time to a snap.
I don't know a thing about crossbrowser implications, though.

Thanks yched, I'll try to optimize. I'm no js guru though so anyone with more ideas please post it.

It seems a lot faster now –in IE7. Here are a few tests. If you want to check yourself, replace the below function in drupal.js. The timer tests all scripts attached to the page applied through drupal.behaviors.

Drupal.attachBehaviors = function(context) {
  startTime=new Date().getTime();
  context = context || document;
  if (Drupal.jsEnabled) {
    // Execute all of them.
    jQuery.each(Drupal.behaviors, function() {
      this(context);
    });
  }
  endTime=new Date().getTime();
  alert('Elapsed time: '+((endTime-startTime)/1000)+' seconds.');
};

All versions on the Mac side except IE7 which is running under a VM.

IE7
before: 3.906 sec
after: 1.032 sec !!

Safari 3
before: .365 sec
after: .342 sec

Safari 2
Couldn't test. Timer wasn't working but it feels about the same.

FireFox 2
before: 1.388 sec
after: 1.139 sec

Opera 9.25
about 2 seconds. Each load varied +/- .5 seconds. Hard to determine differences.

Each were measured after 3 refreshes to clear caching. Tested on the menu admin page.

For everyone who experienced the freezing of 20 secs. or more. Please test this out throughly. tableheader.js had numerous followup patches. I hope this will be the last one for a while.

There were no rendering differences on the tested browsers.

IE7 had it's cell widths misaligned. It was checking for a NULL before due to parseInt but I removed it. Now it returns 'auto' so it checks for that. Applies to ie7 only. Same performance wise.

I keep saying this but here it is again.. Just one more. :)

Simplified a bit more. Some of the math involved to track the visibility and horizontal tracking moved into an area that isn't recalculated constantly on scroll. The cell calculation is grouped in the same area so XX.resizeWidths = true; doesn't have to be passed around. This should shave off a few clock cycles when scrolling.

Thanks dvessel !

A few remarks :

- Your patch uses .clientHeight for every browser (e.vLength = e.table.clientHeight - 100;).
Is there a known reason why we couldn't use .clientWidth for all browsers all the same (for cellWidth) ?

- The $('th', e.table) selector is recomputed in each iteration of the $('th', e).each(function() { } loop. It could be extracted out in a var before the loop (as I wrote in #44, this doesn't buy us much, but well...)

- The cellCount variable is not needed, you can get it as the first param of the "each" function : $('th', e).each(function(index) { } (index will have the same value than the current cellCount)

- Probably nitpicking : the new place for the hardcoded '4' and '100' values make them more intriguing. Took me a few minutes to realize they were already in the code in a different spot. Maybe we should document where they come from ?

Is there a known reason why we couldn't use .clientWidth for all browsers all the same (for cellWidth) ?

I tried but it's not returning the right numbers causing the headers to get all misaligned. Doesn't seem to cause a performance problem though.

- The $('th', e.table) selector is recomputed in each iteration of the $('th', e).each(function() { } loop. It could be extracted out in a var before the loop...
- The cellCount variable is not needed...

Oh, didn't know that. Something like this?

      // Resize header and its cell widths.
      var parentCell = $('th', e.table);
      $('th', e).each(function(index) {
        var cellWidth = parentCell.eq(index).css('width');
        // Exception for IE7.
        if (cellWidth == 'auto') {
          var cellWidth = parentCell.get(index).clientWidth +'px';
        }
        $(this).css('width', cellWidth);
      });

done..

- Probably nitpicking : the new place for the hardcoded '4' and '100' values make them more intriguing. Took me a few minutes to realize they were already in the code in a different spot. Maybe we should document where they come from ?

You mean why it's there? I'll just leave that alone. It's not hard to figure out and I don't want to get all wordy about what it does even though that would be a good thing. Unless you want to, feel free. :)

Works perfectly on windows FF3, IE7, Safari3. Opera shows slightly misaligned header cells, but that was already the case with current HEAD.
Execution time in IE7 is back in line with other browsers.

Minor : "parentCells" would be more accurate than "parentCell" (singular), but that should probably not hold the patch back.

'4' and '100' : well I, for one, don't understand why these values are here, so I can't propose any additional comment :-)

Great, thanks for the review!

The - 100 is just an offset for where the header disappears so the header doesn't obscure the last 2 rows or so while the table is scrolled up and beyond the window. -4 isn't needed but it was there and it causes no harm. It basically does the same but from the top of the table.

Everyone else experiencing the freeze, time to test it now. Thanks.

Re-tested with the patch from #52. IE 7 dropped down to ~2 seconds initial page load time. There was still no appreciable delay moving menus around, and the sticky headers looked great.

A big thanks to dvessel for all the work on this patch!

+1 RTBC.

Tested #52 on my FF2/Linux (Pentium III, 500MHz). Nothing broken, speed a little better (seems like about 10% gain on both page load and drag action, but no exact measurement done - page initialization with real data (a lot of menu items, full page with pager present) about 23->20 seconds, dragging the Administer item about 18->17 seconds. So modern hardware should be somewhere below 5 secs.)

Rendering with Garland fine, with my custom theme (non-zero table borders) I got 2px misalignment, but that's easily solved by defining a 1px margin on table.sticky-header (looks better than before, in the end, now without previous 1px misalignments on cell borders). So this doesn't count as a bug.

RTBC, agreed.

Committed. Thanks for the extensive testing, highly appreciated!

W00t! thanks.