John Hrvatin

Hi folks,

I just posted the HTML5 version of the slides at http://ie.microsoft.com/testdrive/HTML5/BUILDwhatsnew/. 

Thanks!

We chose CTRL+E to match the same shortcut for moving focus to the search box in IE and FF, but mapping to CTRL+F since it functions as inline find would also make sense. 

When we started on the tools we realized we couldn't finish every feature we wanted (as usual) and had to prioritize.  Turns out networking monitoring is actually rather difficult to do with the current networking stack (wininet.dll) and the solutions offered by apps like Fiddler and Nikhil's Web Dev Helper were complicated to build and we couldn't consume them directly without taking a dependency on .NET.  We also knew that other solutions existed (like Fiddler and Nikhil's tool) so when we had to prioritize network monitoring against a feature like JavaScript profiling, we chose profiling.  It would clearly be helpful to have part of the built-in tools, though.

Oh, and the reboot...

I hear ya...I worked on setup in IE7 and it kills me.  Sadly, it's much more difficult than expected.  The core issue is that you can't update files while they're in use.  Windows has developed some technologies like hot-patching that update code on the fly by inserting jump statements in the right places, but that only works on changes within one function, in one file, etc., etc., and we obviously make much larger changes in a new release of IE.  If that core problem is solved in Windows, every application's life gets better.

Some apps work around it by telling you what processes to close to avoid a reboot.  We tried this but critical system processes depend on parts of the networking stack that IE updates so you'd get a prompt that says "please exist csrss.exe" and if you made it task manager and did so you'd get the ominous "your system will restart in n seconds" countdown.

Hopefully that explains why it's not simple to do, but I agree that doesn't mean it's not a problem we shouldn't solve.

Hi Chris,

We open the tools undocked because we found most people prefer to use them that way.  It's also required when debugging JavaScript because a breakpoint will hang IE's UI thread and if the tools were docked, they'd also hang.  For people who prefer them docked, we do remember the docked/undocked state so you don't have to dock them every time.

Great question about refreshing the page...

By default, script debugging is disabled for IE because the extra debug information IE keeps around increases memory footprint and affects performance and there's no need for most users to take that hit.  So if script debugging is disabled and you want to debug, IE needs to reload the page so it can build and maintain the debug information it needs.  We added the prompt in case people are in the middle of scenario and want to save state or data before refreshing.  We also only turn on script debugging for that process so you don't get prompts to debug while you're reading news or booking a flight.  Supporting per-process debugging is another IE8 improvement and one that Visual Studio 2008 also takes advantage of.

To avoid the refresh, you can enabled script debugging by unchecking Tools->Internet Options->Advanced->"Disable script debugging (Internet Explorer)".  This enables script debugging for all IE processes and prevents the refresh, but you'll take the performance and memory hit and get prompted to debug each time you encounter a script error. 

Thanks!

John [MSFT]