Emulating the “non-Desktop Experience” in the Desktop Experience
The new full-screen “fast and fluid” experience of IE10 on Windows 8 offers many improvements over Internet Explorer 10 on the Desktop (ranging from UX to Security), but one thing it lacks is the F12 Developer Tools, used by web developers to debug web pages.
While you can use Visual Studio to debug pages, sometimes, debugging with the lightweight F12 Developer Tools on the Desktop can be simpler. However, what if your bug doesn’t repro in the Desktop experience?
In many cases, you can emulate the non-Desktop experience on the Desktop by making simple configuration changes:
- Enable Enhanced Protected Mode by clicking Tools > Internet Options > Advanced and ticking the Enhanced Protected Mode checkbox in the Security section near the bottom of the list.
- Enable ActiveX Filtering (Tools > ActiveX Filtering)
- Press F11 to put the IE Window in full-screen mode
With these configuration changes in place, you can continue to use the F12 Developer Tools while emulating the non-Desktop experience.
Note that one limit to the quality of the emulation is that the ActiveX Filtering feature will filter out Adobe Flash content from all sites. Such content is permitted in the non-Desktop experience only when your site is on the CV List or the DebugDomain registry key is set.
Debugging Local Content
Web Developers often test pages or sites on their local systems before it is deployed to production. In some cases, there are side-effects to debugging local content that developers should be aware of.
- When debugging against a dotless hostname (e.g. http://localhost) the content will typically be in the Local Intranet zone. By default, this means:
- Security settings (e.g. File download, ActiveX behavior, cookie controls, popup blocker) will be different.
- The site will run outside of Protected Mode or Enhanced Protected Mode, which means that extensions will run with fewer restrictions and cookies and other storage will be “partitioned” from Internet Zone storage.
- If the hostname is merely dotless and isn’t localhost, the page will run in Compatibility View by default
- Requests from “Windows 8 Apps” and IE running in Enhanced Protected will be blocked due to AppContainer Network Isolation
- The content will typically be subject to the Local Machine Lockdown
- The IE8/IE9 XMLHTTPRequest object is not able to send requests (fixed in IE10)
- The IE8+ XDomainRequest object is not able to send requests
- Storage with domain-based security policy (e.g., HTML5 Storage, IndexedDB) is disabled
- If the content runs inside Enhanced Protected Mode, subdownloads may fail if they lack a Mark-of-the-Web.
For scenario #1, you can disable the Local Intranet Zone by clicking Tools > Internet Options > Security > Local Intranet > Sites and unchecking all of the boxes. Of course, this will also mean that your content runs inside Enhanced Protected Mode, which can cause the problems listed in scenario #2.
To help address scenario #2, Fiddler4 includes a tool called the EnableLoopback Utility which can be used even when Fiddler isn’t running. It’s simply a graphical version of the CheckNetIsolation.exe command line tool which is used to exempt specific AppContainers from loopback restrictions.
If you’re having issues in scenario #3, you can consider using IIS Express or Fiddler’s AutoResponder tab to serve your local pages from a local web server.
I hope that this post is useful. If you encounter any other “gotchas” or have other tips for local debugging, please sound off in the comments below!