IE8 and Reliability

[NewsBot]

Developing technologies that work reliably on their own and as part of the computing ecosystem is core to our mission and is an important part of our commitment to Trustworthy Computing. Our customers and partners expect technologies and services they can depend on anytime, anywhere, and on any device. We focus on constant improvements to the dependability of our technologies and services.

 

For Internet Explorer, reliability means that the browser should always start quickly, perform well, connect to the Internet, and show Web sites without crashing or hanging. Most users want their browser to work, recover smoothly after a crash, and display the Web correctly. Users are not as concerned with what causes the problem, whether that be a poorly functioning add-on or poorly performing website. As part of our ongoing commitment to improve reliability, we have done a great deal of work in IE8 to make the browser more robust in all of these areas: performance, recovery and display. In particular I will discuss:

 

• Loosely-Coupled IE: An architectural feature that helps isolate different parts of the browser from each other for smoother browsing performance.
  
• Automatic Crash Recovery: A feature that is designed to get users back to browsing as quickly as possible after a crash.
  
• Windows Error Reporting: A way for our customers to provide us with information to improve the reliability of Internet Explorer.
  

 

Loosely-Coupled IE

 

One of our most significant investments is in a feature called Loosely-Coupled IE (“LCIE”), which is an architectural attribute that helps isolate different parts of the browser from each other, most notably, the frames from the tabs. LCIE is the foundation that we have built a few of our features on including Automatic Crash Recovery of which I expand on below.

 

If you haven’t already read about what we started in Beta 1, I would encourage you to read my first post which covers how we isolated the frame window, which roughly corresponds to the “chrome”, from the tabs by putting them in their own separate processes so that a tab can now crash without bringing down the rest of your browser. Visually, this separation would look like the following, with the frame area highlighted and the tab area dimmed:

 

http://ieblog.members.winisp.net/images/IE8.Frame.2.png

 

Building on Beta 1, we have continued to develop LCIE in IE8 Beta 2 to further improve reliability and performance.

 

For Beta 2, we added the following changes:

 

Frame Process Merging

 

To help improve startup performance, we have reduced the number of processes that we start. Instead of firing up two processes every time you launch the browser (one for the frame and one for your tabs), we now only fire up one frame process the first time you launch IE. Subsequent launches will only start a new tab process or make a new tab in an existing tab process.

 

For users that are accustomed to browsing websites in multiple “sessions”, for example if you want to log in to multiple email sites simultaneously, you can specify the “-nomerge” command line option to disable this feature.

 

More tab processes

 

It turns out that the vast majority of all IE sessions contain three or fewer tabs. Accordingly, in Beta 2 we try to give users three efficient tab processes. This is contingent on the user’s computer capabilities, but the more capable a computer is, the more processes we will use, up to a point. Adding more processes gives users much better isolation in the event of a failure. If each tab is in its own process, websites are completely isolated from each other.

 

Virtual tabs

 

We have also added the internal capability to “hot swap” the process from underneath a tab. Previously, Protected Mode worked on a per-process basis. For example, say you add a website to your trusted sites in IE7. If that site links to another site that is not in your trusted sites, it will cause you to switch browser windows when you click the link.

 

We improved this in IE8 Beta 1 with LCIE when we split the frame from the tabs. With the split we can create a new tab in the same window and switch you to that tab as opposed to being “punted” to a new window.

 

Virtual tabs lets you navigate across Protected Mode in the same tab since we just switch the process under the tab to the correct integrity level. This is really just “UI-sugar” – virtual tabs do not impact security or protected mode in any way, other than to make it more convenient to transition between protected mode on/off.

 

LCIE's capability of isolating different parts of the browser coupled with more tab processes and virtual tabs will improve the performance and overall reliability of Internet Explorer.

 

Automatic Crash Recovery

 

In the event of a crash, Automatic Crash Recovery is designed to get you back to browsing as quickly as possible. It uses LCIE’s tab isolation to help localize the failure to your tab. If you experienced a crash in Beta 1, you may have noticed this bubble:

 

http://ieblog.members.winisp.net/images/IE8.Tab.Recovery.2.png

This is the “tab recovery experience” – the failure has been confined to your tab. Your browser never goes away and we get you back to the site pretty quickly.

 

What’s happening behind the scenes is that we are keeping track of an array of information about your tab. In Beta 1, the following data about each tab was stored:

 

• Current URI
  
• The travel log (your back/forward history)
  
• Tab order
  
• Which tab was active
  

When you crash, we tear down the old tab process, create a new tab process and recover the stored data back into the tab. For many website this works well; however, there are other websites, such as sites with web forms, or sites that you need to login to, that we didn’t recover successfully.

 

In Beta 2, we improved this further by adding:

 

Session cookies

 

 

 

Session cookies are often used for authenticating the user to a website. Session cookies are temporary cookies that only persist for the lifetime of your browsing session. When you login to a website, they usually give you a session cookie that contains a unique token that identifies you while you are logged in. As you navigate around the website, IE sends your session cookie to the site, and the site can examine this token and determine that you are authenticated. Unlike persistent cookies, they are not written and retained on your hard disk.

 

In IE8 Beta 2, we recover your session cookies too and still do not write them to disk! We store copies of them in the frame process. When your tab crashes, we just copy them back from the frame into the tab, and the user is automatically logged back into the site they were using (i.e. webmail, blog sites, social sites).

 

Note that session cookie recover only takes place for tab crashes. If the whole browser crashes, the session cookies are lost, however we do expect that the overwhelming majority of crashes to be isolated to the tabs, as most crashes are caused by malfunctioning add-ons, which are now isolated to a tab process.

 

Form data

 

We can now recover your form data. If you typed information, such as an email, blog post, comments, into an HTML form, we can now recover that information.

 

Leveraging LCIE’s tab isolation allows Automatic Crash Recovery to quickly restore the user to their browsing session without having to log back in to their sites or re-enter new data into forms. Combined, LCIE and Automatic Crash Recovery provide a really innovative and graceful way to recovery from crashes.

 

Windows Error Reporting (aka Watson)

 

In the event of a crash or a hang, you may have received a choice to “send information to Microsoft”. You may be wondering what we do with this information.

 

The short answer is that we look at it every day. We take each report seriously because this data is extremely important to us. Not only can we determine what is causing issues, in aggregate, but we can determine the specific issues that are affecting the most people, and actually fix them.

 

If IE crashes or hangs and you choose to send information, Windows Error Reporting does some work to collect information about the state of the program when it crashes or hangs. We can see what add-ons are loaded and what IE was doing when it crashed. To the coders in the audience, it sends a call stack along with a memory dump. If you’re writing an application for Windows, or an Internet Explorer add-on, you can get Watson data about your own application and use it to improve quality.

 

Windows Error Reporting is smart enough to collect similar problems into “buckets”, which are usually lots of instances of the same underlying problem. If the problem lies in IE code and it is encountered frequently, we fix it. In IE8, we recognize that the most important failures that we can fix are ones that are out there happening on users’ machines. We have even committed to fixing the top 50% of all Watson hits in IE (including issues that may have carried over from IE7).

 

Microsoft goes to great lengths to protect privacy when customers submit error reports. When an error occurs, a report is generated with the minimum amount of data needed to check for a solution. This report does not contain any personal information and customers are asked before any information is sent back to Microsoft. Microsoft also does not track error reports back to an individual — unless that individual chooses to track an error report to find out if a solution has been found for the error. Even then, Microsoft developers working with the data cannot identify the customer and will request further information only if additional contact is needed to solve the problem.

 

Get Ready for Beta 2

 

LCIE, Automatic Crash Recovery and a good deal of bug fixing has helped make IE8 Beta 2 a browser you can depend on. When IE8 Beta 2 is released, I encourage you to check it out!

 

Andy Zeigler

Program Manager

Reliability and Privacy

 

http://blogs.msdn.com/aggbug.aspx?PostID=8773324

 

More...