IE8 in Windows 7 RC: Reliability and Telemetry
With the “final” release of IE8 for Windows Vista and other versions of Windows in several languages, we’ve been focused on finishing IE8 in Windows 7. We’ll blog soon about the updates in IE8 in the Windows 7 Release Candidate around the Windows 7-specific features, like tabs in the taskbar, jump list, and touch. Today’s post is about reliability and telemetry.
As in Win7, an important goal in IE8 was increasing reliability. For example, IE8 isolates crashing tabs from each other. If you’re listening to music in one tab, and the site you’re using in another tab crashes, IE8 isolates the crashed tab so the music doesn’t stop playing. We also pay very close attention to the data that users opt-in to sending Microsoft about their experience. We use that telemetry to adjust the product after release. We described some examples in another post during the Windows 7 Beta.
Delayed responsiveness (or a “hang”) or non-responsiveness (or a “hard hang”) are just as frustrating to users. For the Win7 RC, we wanted to get much, much better telemetry about browser responsiveness “in the real world.” There’s a challenge in having software detect non-responsiveness in itself, kind of like asking a classroom “anyone not here please speak up.”
For the Win7 RC, we added functionality to IE8 that lowers the threshold for identifying delayed responsiveness that might be a hang. Basically, IE’s frame uses a timer, and if the tab doesn’t respond within a given interval of time, the frame gives the user the choice to recover the page, close the page, or wait for the tab to respond. If the tab responds on its own, IE takes down these choices.
A tab might become non-responsive like this for different reasons. The webpage in the tab might use a plug-in that is very busy pulling down a lot of video information from a slow server and then processing it. The webpage might be on an intranet (e.g. http://salarydata) and different authentication mechanisms are negotiating, slowly, what the user is allowed to see. Sometimes, it's an issue with IE. Better telemetry here is crucial in figuring out what we, as engineers, do differently here.
Whatever the underlying reason, the challenge here is how sensitive to make this timer. Too long a timer (for example, 10 minutes), and impatient users might not give it a chance to appear. Too short a timer (for example, one millisecond), and this dialog may appear and disappear a lot during regular browsing. Again, the goal was to get information about real world browsing to improve IE’s responsiveness and reliability.
Based on the initial, Microsoft-internal, data after putting this in the product, we thought the experience was unobtrusive and overall better for users because it provides more information to improve the product. As more data has started to come in from external Win7 users, we’ve seen an increase in reports. We’re watching the data very closely to understand how well this works for the larger set of users. If we see data that makes us think this is not a good experience, then we'll release (as we have before) an update to address it.
While we continue to track the telemetry, if you are debugging IE either with the IE Developer Tools or a debugger, and you attempt to interact with the IE window, there is a chance that you will see this dialog. Although this will not impact your debugging it may be more convenient to turn this dialog off. Or if you’re running Win7 RC and are seeing this prompt more than you should or would want to, you can turn it off by changing the following registry key:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main!HangResistance, DWORD, 0
Thanks,
IE Team
P.S. People who downloaded Win7 RC "early" may be running without a Compatibilty View list because the list for the Win7 RC is still working its way through the deployment system. Depending on the sites you visit, you may or may not notice its absence. It will be available soon.
