100% CPU in IE7 (desktop) when in a iframe #1422

Closed
siromega opened this Issue Apr 11, 2011 · 4 comments

Projects

None yet

3 participants

@siromega

I've been able to replicate a issue with Alpha 4.1 (and 4.0) that will cause 100% processor utilization in IE7 when it is run inside a iframe. The CPU usage spikes when the page is loaded, however occasionally I've got the page to load but whenever an action occured (click on element) the CPU usage would spike and render the browser unusable. A very basic sample follows...

** Warning: this will crash your IE7 browser, so be sure you don't have any other IE7 windows open that you want to keep around **

<iframe style="width:250px;height:100%;" src="http://jquerymobile.com/demos/1.0a4.1/">&lt;/iframe>

The iFrame issue does not affect Google Chrome 10 or FF4.

@siromega

Based on my preliminary, non-uber-js-coder spelunking through the source with the Visual Studio debugger, it appears its a resize event that is causing this problem. Presumably, there are some resize events getting called, and then whatever code is executing is resizing something, causing the event to be fired again (and on forever).

@siromega

You can also reproduce the problem by going to the demo page above in IE7 and resize the browser until it is less than 320px wide. It appears it doesn't necessarily need the iframe (though that might be a separate issue).

@johnbender

Anthony,

We've seen something akin to this in the test suite actually, I've added it of my list of IE "weirdnesses" to address. Thanks for submitting the issue!

@johnbender johnbender was assigned Apr 12, 2011
@siromega siromega added a commit to siromega/jquery-mobile that referenced this issue Apr 21, 2011
@siromega siromega Fixed for the first issue in #1422 - IE7 locks up in infinite JS resi…
…ze events.


The fix is to change how the detectResolutionBreakpoints function adds and removes classes from $html. The problem is that removing and adding those class names triggers the resize event again, resulting in infinite resize events. The solution is to come up with a new way to change the class names - by copying them off $html, adding and removing them locally in a variable, then checking to see if the class names have changed and applying the changed className string. Note that this would not be thread safe (any changes to $html.className would be lost if it were made between the read and the write) but since JS isn't threaded so we don't have to worry about that.
dafc6fd
@siromega

OK, after more research, the fix above addresses the issue. The iframe wasn't the issue, it was just the small width of the window. I've finally got around to making my app work inside the iframe (yeah!).

Once the small width issue is fixed, this ticket can be closed.

@scottjehl scottjehl pushed a commit that closed this issue Jun 18, 2011
scottjehl Added new throttledresize special event, including unit tests. This e…
…vent prevents browsers from running continuous callbacks on resize, which we use internally for orientationchange in browsers like IE. It still ensures that a held event will execute after the timeout, so logic that depends on the final conditions after a resize is complete will still execute properly. This improves performance noticeably, and... Fixes #1496. Fixes #1848. Fixes #1422.

The included tests pass most of the time, but they need improvements as they will occasionally fail due to faulty timing in the tests themselves, as far as I can tell (the code tests out fine in our functional demos).
8c6164d
@scottjehl scottjehl closed this in 8c6164d Jun 18, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment