Please read my blog's comment policy here.
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:
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.
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.
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!
also debug your web apps by running IE 10 desktop in noAddons mode or
Internet Options>Advanced tab>uncheck "Enable third-party browser extensions"... close and restart IE for the changes to take affect.
also check your Encoding settings and accessibility settings for a user Stylesheet, "Ignore font styles specified on web pages" and "Ignore font sizes specified on web pages"
if comparing rendering in different web browsers ensure that they are all using the same default font family and size...
Thanks for the information given.
I am not able to find cookies folder for IE 10 on Windows 8. where is it or where are the cookies stored?
@Avi: Desktop IE's cookies haven't moved; hit Win+R and type shell:cookies to see the MediumIL cookies, and open the Low subfolder to see the Protected Mode cookies. Cookies for Internet Explorer when running in non-Desktop mode can be found under %USERPROFILE%\AppData\Local\Packages\windows_ie_ac_001\AC\INetCookies\ although it remains unsupported to try to access the cookie files directly; use the WinINET enumeration APIs instead.
@Eric: Thank you for your prompt reply.
I am not able to retreive the cookies using FindFirstUrlCache Entry on windows 8 IE 10.
what can be the reason? It is working on windows 7 IE 9.
What can be the reason. and which api will be useful in this case?
The msdn forums page is a big ol' FAIL for me, can you please repost this to this IE forum and try to get any insight back to firstname.lastname@example.org? My title of this post was to be "Two questions about "pure SVG document" in IE9." I tell ya there are sure some usability flaws in making your way around MSDN. Thank you Eric!!
I am adapting a server-hosted XSLT-based SVG document generator, so that it works in IE9. My project has always worked great in Firefox, but I am having a number of issues with IE9. It is not feasible to re-host what I am doing so that it arrives at the browser as an HTML5 document, or SVG inline or embedded in XHTML. There are a number of difficult / impossible issues for this latter approach that I can't solve yet remain browser-neutral.
B. Is there a way to guarantee that the IE9 browser receiving the file is in the correct mode to render SVG. In our company (I think?) the default install of IE is some kind of compatibility mode so that IE8-genre pages will load correctly. There is a little gem of a meta tag you can supply via an XHTML document, in the <head> tag, saying "meta http-equiv='X-UA-Compatible' content='IE=9'/>" which forces the issue. Inconveniently, there is no equivalent of that in a pure SVG document. Can you suggest a way to ensure IE9 be configured to support pure SVG documents.
@Dave Porter -
B. You can send an HTTP header instead of including a <meta>.
Does that work?
(Try adding it using Fiddler2 if you cannot do it using the server, just to see if it resolves your issue and maybe also the first issue)