Submitted by Andrew on 1 September 2009 - 8:04pm
A while ago I wrote about an issue with CPU spiking in Internet Explorer 7, recently I encountered another instance of this that required a different fix. To recap, we have a rich-client drag-drop interface across two scrolling panes. You can drag and drop within the main pane on the left (a nested list with 'sections' and 'items') and you can also drag things from a pane on the right onto the pane on the left. A read-only display of this (without the drag/drop and right-hand pane can he seen here for reference. Last time, we had a CPU spike causing slow juddering drag/drop when there were were only about 7 or 8 items in the left hadn pane. This got progressively worse as you dragged more items onto the list. After trying various things from Steve Souders' excellent blog and other Googling it ended up with selectively switching elemts of the screen off until I could narrrow it down to see what was causing the problem. It turned out to require a few CSS 'min-height's being set on a couple of attributes but I'm not 100% sure why. I'm guessing it could be some manifestation of the IE 'hasLayout' problem and the min-height could have been the equivilent to the Holly Hack to coax the IE rendering engine into working properly. This time however the same symptoms manifested themselves but a different cause and different solution was found. More selective disabling of page elements/events and head-scratching later this one turned out to be caused by an absolute positioned button in the top-right of the left-hand scrolling pane. There was no need for this to be absolutely positioned so I just tweaked the CSS again to float it to the right of the list title and, hey-presto, IE7 CPU spike goes away and performance returns to normal. It's these kind of things that give IE the reputation it has with web developers.... :-) Love it or hate it, it certainly gives you some interesting issues to sort out.
Andrew, We recently
Andrew,
We recently encountered the exact same problem (flickering cursor at first and then a 50% CPU load on a duo core CPU = 100% CPU load on one core) and had a hard time finding what was causing the browser to act like this. Many attempts resulted in different conclusions, rather frustrating since none was 100% satisfying.
On a virtual machine with XP SP3 and Internet Explorer 7.0.5730.13 this website loaded like expected, but on a borrowed laptop with Vista SP1 and Internet Explorer 7.0.6001.18000 the bug did occur.
Since absolutely positioned elements need an absolutely or relatively positioned parent, we set the positioning of a few element types like div, p and ul to relative. Eventually we found out that this rather innocent declaration made IE7 choke.
By resetting the positioning of div and ul elements to static (div , ul {position: static}) the problem seemed solved. The site off course did not display correctly, but after redefining the stylesheets here and there it did look like intended.
The solution works for us, but we are afraid only for the moment since we are not positive of hitting the source...
Gérard Talbot's test case at http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/InfiniteLoopIE7.html (WARNING: this link might make your IE7 hang!) kept occupying the CPU's of the two test machines for respectively 10 and 7 percent.
A few days of work down the drain! :-)
Off topic: do you know where to download specific version numbers of IE for testing purposes?
Thanks for your article, it was really hard to find resources on this and some other victims.
Kind regards,
Laurens Meurs
(Rotterdam, the Netherland)
Andrew, Infinite reflow
Andrew,
Infinite reflow causing cpu activity to be maximized (hang bugs) are rather rare but they happen. They are usually treated more seriously (and they should!) than ordinary CSS layout bugs. They lead non-computer-savvy people to believe that their browser and/or their computer is/are slow, not performant.
If you could provide a link (or links) where such problems can be seen, examined, then that would help. It would point out the precise minimal conditions of such bugs. You see, IE 7 is going to be around for quite some time on the web.
For now, I have mentioned your 2 blog entries ("Internet Explorer strikes again" and "More IE7 CPU spiking") in my IE 7 bugs webpage.
best regards, Gérard Talbot