 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Internet Explorer / General Topics / August 2007IE7.0 + css behaviour = 100% cpu usage
Our site makes use of CSS + behaviours to enhance the user experience yet with IE7.0 it makes it unusable as the browser uses 100% for a considerable time after loading the page, on my old laptop I left it for several minutes and it still remained at 100% making the machine usable. Removing all code from the .htc files but maintaing their references in the CSS reduces this time period but its will sit at 100% for 10 -> 30 seconds depending on the amount of behaviours in the CSS. Obviously this is a fairly serious issue but without removing all behaviours I cant see a work around as even blank .htc files dont work so its not an issue with the jscript itself more with the generic use of: behaviour: url( 'file.htc' ) > Our site makes use of CSS + behaviours to enhance the user experience yet > with IE7.0 link to your site, please? Unfortunately its an internal site. I'm currently working on creating a simple test case but it seems there is more required than I first thought. If I load one of the problem pages on its own I dont see the problem but displayed in context as part of a frame set I do. Whats even stranger is changing the contents of the frames around the problem frame also has an effect on the duration of the high CPU load. Ok I've created a basic test which shows the 100% problem in action. It seems to be the combination of 4 factors: * a frameset * loading one of the frames in the frameset * form elements, in this case buttons * css behaviours All 4 together ensure 100% cpu load for an extended period after the page has loaded. Removing any one and it doesnt seem to be a problem. The most strange one of these is the page on its own out of the frameset. This I dont understand how it could make a difference but it does. How to reproduce: * Load the following URL in IE7: http://clanservers.multiplay.co.uk/dropzone/ie7/ * Right click reload any one of the frames You will notice when you reload the frame the CPU spikes to 100% and stays there for some time even after the page has fully loaded. Note: If you want to reproduce this locally you will need to ensure your webserver is setup correctly with the mime type for .htc files. Steven Hartland schrieb am Tue, 24 Oct 2006 10:13:02 -0700: > How to reproduce: > * Load the following URL in IE7: > http://clanservers.multiplay.co.uk/dropzone/ie7/ > * Right click reload any one of the frames no repro I refreshed them one-by-one, I refreshed the whole page. No problems. Yes, IE7 spikes up, to something between 10 - 35%. That's all. It's really a spike of less than a second. I compared the behavior with IE6 and I forgot to log the CPU utilization of IE6, but I noticed that IE6 seems to be slower at refreshing. It shows "Downloading x items from" for a few seconds and you can see that count down from something like 20 to 1. So, IE7 seems to be faster than IE6 for that page. I think there's something on your machine which causes this (add-on or security program). Did you test with other machines? Kai  SignatureHelpsites about Windows: http://www.mvps.org IE repair script: http://iefaq.info I've had it confirmed / reported by every user that has IE7 here and I can produce it every single time here on clean Vista RC1 with IE7 as well. Have you altered your settings at all maybe a security setting which disables .htc's or behaviours? Machine spec here in case its a factor: P4 2.5Ghz 2GB RAM Spike time after load 10 seconds. On an old laptop here P3 450Mhz 348MB RAM is spikes for ages never bothered timing as it just makes the machine unusable. In comparison on my machine I can bearly even see a reload register in process explorer in IE 6. Steven Hartland schrieb am Tue, 24 Oct 2006 13:36:02 -0700: > I've had it confirmed / reported by every user that has IE7 here and I can > produce it every single time here on clean Vista RC1 with IE7 as well. > > Have you altered your settings at all maybe a security setting which > disables .htc's or behaviours? I'm using the default, whatever that is. It's indeed possible that behaviors are switched off by default in the Internet zone, I can't check at the moment. I'll check on that later. > Machine spec here in case its a factor: > P4 2.5Ghz 2GB RAM I tested it on a machine that is supposed to be slower or the same. Kai SignatureHelpsites about Windows: http://www.mvps.org IE repair script: http://iefaq.info Steven, just to let you know we have made this some isolation in our application as well. We have noticed that for us it seems to be just HTML HTCs but out C++ compiled HTCs do not cause this spike. We have seen it on XP/IE7 as well as Vista which also matches your isolation. Not sure if this is of any interest to you but another of our senior developers wrote a little test application in VB.NET and put a MS internet browser control on there with very little code. None of this behavior exists in the test application which lead us to believe that the issue exists within the IE7 wrapper program around the browser control and not in that control itself. Any thoughts? > I've had it confirmed / reported by every user that has IE7 here and I can > produce it every single time here on clean Vista RC1 with IE7 as well. [quoted text clipped - 11 lines] > In comparison on my machine I can bearly even see a reload register in > process explorer in IE 6. Steven Hartland schrieb am Tue, 24 Oct 2006 13:36:02 -0700: > Machine spec here in case its a factor: > P4 2.5Ghz 2GB RAM > > Spike time after load 10 seconds. I put your site in Trusted Sites, so that behaviors may run and checked again. I can reproduce your issue partly, but I cannot see any problem with it. The refresh happens instantly, the "Downloading x items" (one for each button) runs very quickly thru (in about a second, so you can barely read it, while it takes some 5 seconds or more in IE6). IE spikes up, this lasts for about 3-5 seconds. It may reach 90% or so for a fraction of a second, I haven't seen that. Mostly I see something like 30-70% during these 3-5 seconds. That's if I refresh one window. If I refresh the whole page at once it's only for one second and IE reaches something like 70-90% in this one second. Don't know why there is that difference. Maybe the frames then don't get refreshed. So what you see is obviously caused by IE7 being able to process those items much faster than IE6 did. That this needs more CPU power makes sense to me. Anyway, I can't see any ill effects from that. I loaded an application which takes as much CPU as it can while running and then revisited the test. There was no difference. The refresh happens instantly, the spike takes for about 3 - 4 seconds, CPU utililization is about the same. No problems at all. This is on my laptop with a 1.5 Mobile Celeron. Kai SignatureHelpsites about Windows: http://www.mvps.org IE repair script: http://iefaq.info Greetings, I work for Dundas Software (http://www.dundas.com), and our sample framework that we include with our product makes use of frames. As such, we have noticed this problem. When security permissions are changed to Intranet (from Internet), the problem goes away. As well, we have a Internet page that uses frames for documenation located: http://support.dundas.com/OnlineDocumentation/WebChart2003/webframe.html This page shows IE7 having 100% CPU usage if you navigate around a bit (click on some tabs, or navigate through some content). On Dual Core machines it's harder to reproduce, as the CPU will go to around 60% on both cores. However, if you quickly and continously click on items on the left side (i.e. keep loading up different articles) you will see it hit 100%. We've reproduced this on Windows XP as well as Vista with IE7 release. Sincerely, Terrence I was confronted to this problem in several cases too. What happens essentially is that on a pure CSS layout, if you happen to use CSS behaviors OR use Javascript to dynamically modify the CSS of a block-level element inside a block-type container, IE7 cycles constantly trying to compute the container's new size; this will stop only if the behaviours manage to 'settle', or if the bottom of the container reaches the window's coordinates. Example: <html><head>...</head> <body style="display:block; width=100%; height=100%; overflow:hidden"> <div style="display:block; position:absolute; top: 30px; bottom:30px; left:30px; right:30px; overflow:auto"> [some content] </div> </body> This code will create a 'pseudo frame' made of pure CSS and HTML; if the content actually goes past the available display size (bottom of the window, not viewable content) and contains block-type elements which change sizes (due to :hover giving it a new size, or Javascript switching a display type from 'none' to 'block', or whatever), the IE7 will start eating CPU time, the scroll bar will keep resizing and if any inputs is in the page, its cursor will blink erratically. One solution I've found is in fact reminiscent of the 'Holly hack': give the container a min-height (even if it's a bogus one), and IE7 will stop goofing up. You don't need to include it in a conditional comment, however it is W3C-approved syntax, ignored by IE6 and correctly used by other browsers. Mitch 74 > Our site makes use of CSS + behaviours to enhance the user experience yet > with IE7.0 it makes it unusable as the browser uses 100% for a considerable [quoted text clipped - 18 lines] > > http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=40d3 46e2-1230-4247-87e8-c11da5620121&dg=microsoft.public.internetexplorer.general |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.