I’m definitely against wasting system resources, as it seems like the new IE7 tab format is going to do with each tab running it’s on thread process.

What I’m curious about though is the effect this type of tab will have on individual tab’s behaviours. Many times in Netcaptor when I am browsing a website that has intensive Flash, a java applet (eww I know), or loads up some other plugin or dhtml, the entire browser will ‘freeze’ until it’s done loading.

If one of those items mentioned has a bug and crashes, all other open windows go with it.

Will having separate thread processes for each tab prevent this? If one crashed, would the others continue normally? Would they be able to continue loading independently without ‘freezing’ the other tab pages?

If this is the case, I’m not sure that having the threads be separate is a bad thing at all… I’d be curious to know your thoughts on how much actual memory will be wasted by having each process thread individualized.

Also, one related feature request for NC8 Maxthon has a feature where when your browser crashes it remembers the pages you had open and re-opens them at last startup. Could be handy, unless it keeps opening the page that crashed it of course!

Thanks for reading,
-Kevin

Adam and I know each other a little bit. For other readers - I’m the dev manager for the IE feature team that owns tabbed browsing in IE7.

We researched several other approaches, and we ultimately preferred the multiple thread, toolbar-per-tab as the right balance of appcompat and stability vs. memory use. Remember that we’re retrofitting multiple tabs into a browser that wasn’t designed that way, and we want it to work out-of-the-box with 3rd party toolbars that weren’t designed to work with tabs.

Our testing showed that if we went with a single thread for all tabs in a window, we would encounter many more UI stalls and jerkiness – too many things both in our code and common 3rd party code block on various things like network activity. So the foreground tab scrolling would stall for a moment, or the whole frame would hang for several seconds while a background tab loaded some docobject, and the like. Not good.

We looked at other approaches for implementing toolbars that weren’t instance-per-tab, but they all had much bigger appcompat issues. Ultimately we felt we needed this approach for the best possible appcompat. Even so, some toolbars won’t work with IE7 and will need to be fixed. But we hope the fixes will be minor.

We certainly didn’t do it this way to save time. Back when we were deciding the implementation, the thread-per-tab approach was estimated to be significantly more expensive than any other approach we considered.

Obviously third party toolbars that handle many top level windows well will work well with IE7’s tabs, and ones that don’t handle lots of windows won’t handle lots of tabs any better.

As for UI space, yes, third party toolbars are currently located below the tabs and can’t be moved above them. Another tradeoff.

Yuck. I don’t use IE, but this seems to be a good reason for users of IE7 to either:
1) Switch to an IE shell
2) Switch to a new browser (Firefox/Opera/etc.)

I find it really odd you would do this, seems like a really bad UI design, when MS is usually good at creating usefull UI’s.