We considered a variety of approaches and built a couple prototypes, and the solution we settled on was to essentially push a large part of what you see in IE6 into a tab. We built a new frame to host the browsers and wrote a bunch of internal plumbing to manage them and cache state. This is a bit of a simplification; the address bar and so on won’t be part of the tab of course, but 3rd party toolbars and Browser Helper Objects (BHOs) are because they are tied to a single browser and sometimes make deep assumptions about how they are hosted.

The address bar, back and forward buttons, and similar controls are still part of the frame. This required significant changes to the way these components interact with the browser. The old model was that they were directly connected to a single browser, frequently probing (sometimes deeply) through the object model to find out what type of content was being hosted and what capabilities were supported. They communicated directly to these objects and interfaces within the browser and cached pointers for performance and convenience. We untangled the communication so that the controls could flexibly target any tab and eliminated assumptions that were no longer valid. Similarly, we hooked them up to use the cached state for each tab because they can no longer sink the browser’s events directly.

One design decision worth calling out is that our current implementation is fully multithreaded. Each tab is on a separate thread, and the frame is also on its own thread. This has some impact on the overall footprint of IE, but we believe this will allow IE7 to feel faster and provide an overall better user experience. Internally this creates some additional complexity as we have to deal with a lot of cross-thread communication, but it also gives us a way to do things we wouldn’t otherwise be able to do with a single-threaded approach.