IE Compatibility List Pruning
Hi, I am Michael Benny, a tester on networking in Internet Explorer. During the Internet Explorer 8 development cycle I was responsible for verifying many of the pieces of Compatibility View. We have discussed earlier about how the Compatibility View feature works and the steps a site author can take to ensure the Compatibility View button never displays for IE8 users visiting your site. There is another scenario that we have not yet covered, if my site was already added by an End-user to their Compatibility View list before my site was updated, and now it’s ready, how would I get the site off of that user’s list? I wanted to share one particular feature that we haven’t blogged about before – the ability to “trim” domains from a user’s Compatibility View list.
As a quick refresher on Compatibility View, Internet Explorer 8 uses its most standards-compliant rendering behavior by default. This configuration may cause problems with websites that expect the older, less interoperable behavior from IE. As a site administrator, you have a number of tools at your disposal to ensure IE8 clients have a compatible experience with your website – taking advantage of the standards improvements in IE8 or using the X-UA-Compatible header to tell IE8 “display content as IE7 would have” being the two most common options site authors have requested.
End-users also have a way to mitigate compatibility issues they may encounter in the course of normal browsing on sites that do not have the X-UA-Compatible option explicitly set. They can choose to view a site in Compatibility View, an IE7 emulation mode, by toggling a button on the browser’s address bar. Internet Explorer 8 remembers Compatibility Button presses on a per-domain basis in order to provide a more seamless return-visit experience. These domains are stored in a registry location on the client at HKCU\Software\Microsoft\Internet Explorer\Browser Emulation.
When a site is in a user’s Compatibility View list, the default document rendering behavior will be set to IE7 Emulation mode and it will affect the User Agent String used to request pages. As a site admin, you are always in control of how your site is displayed. Using the X-UA-Compatible tag, you can override Compatibility View on the client and dictate the exact rendering mode your site should be displayed in. Site admins also have the option to deploy the X-UA-Compatible header for a large section of pages as an HTTP header (Example: IIS and Apache). You can take this one step further by using the X-UA-Compatible to also remove your domain’s entry from the user’s Compatibility View list. Here’s how…
For a domain to be trimmed, the End-user must first land on a page with the X-UA-Compatible Meta tag or HTTP Header. The presence of an IE8 <META> tag does indeed trigger the list clean-up process, but that’s not all there is to it. The next step is to look for a file called ‘IEStandards.xml’ placed at the domain root. IE will first make an HTTP HEAD request for this file looking for its presence. Absence of the file means that the domain remains in the user list. If the HEAD request is returned successfully, then IE will perform an HTTP GET request for the file. In the file, a tag called ‘IE8StandardsMode’ signals the list entry is really ready to be trimmed. Here is an example of the correct server configuration for ‘example.com’:
- Set the page X-UA-Compatible header set to a value indicating IE8 mode
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"> - Place a file at the root of the domain ‘example.com’
https://example.com/IEStandards.xml - The file should have a root XML element called IE8StandardsMode:
<IE8StandardsMode/>
Site admins should be aware that this affects all sub-domains. So if a user visits a page at ‘support.example.com’, which is configured as shown here, but there is another sub-domain like ‘mail.example.com’, which would still like to respect the user’s choice to put the site into Compatibility View, then the ‘mail’ sub-domain will use IE8 Standards mode rendering.
The entries on the Compatibility View list reflect an entire domain, example: ‘example.com’, rather than subdomains like ‘mail.example.com’ and ‘support.example.com’. IE must process the request to trim the domain entry from a source that represents the entire domain, otherwise side effects to subdomains may occur. As an example, suppose the entire ‘example.com’ domain is on the user’s Compatibility View list. Later, ‘support.example.com’ does great work to update their site to support IE8 and includes a HTTP header / <META> tag indicating that portion of the site is best viewed in IE8 Standards Mode. ‘example.com’ and ‘mail.example.com’ have still not been updated. If IE were to remove the entry for ‘example.com’ from the user’s list based solely on the presence of the HTTP header / <META> tag value found at ‘support.example.com’, the user could encounter a compatibility failure when they visit non-updated content at ‘example.com’ or ‘mail.example.com’. Checking for the ‘IE8StandardsMode’ file at the root domain level solves this case by requiring that someone “authoritative” for the domain signal list cleanup. That way, IE users can be assured of a consistent compatibility experience on the domain.
Getting the IEStandards.xml file follows a very similar model to how IE will request favorite icons for domains, but we wanted to address the issue of server overhead. To avoid IE8 making multiple and unnecessary requests to a server for this file on every page navigation with the X-UA-Compatible option set, there exists a 30 day timeout period since the last request. This 30 day timeout period is also set when a user adds a domain to their user list, so do not be alarmed if you still see IE8 Compatibility View requests after deploying the file to the domain root.
Thanks,
Michael Benny
IE Test
Update 6/4/09: Correcting a reference to IESettings.xml which should be IEStandards.xml
Comments
Anonymous
July 01, 2009
The comment has been removedAnonymous
July 01, 2009
@rusty Because IE7- behaviours are not buggy. MS was just sticking to their de facto standard for the sake of everyone.Anonymous
July 01, 2009
@Eden Same here, when I write code I don't have any bugs, they're features!Anonymous
July 01, 2009
For the sake of everyone? The children in Uganda, Lynx users?Anonymous
July 01, 2009
I'm pretty sure the file is called "IEStandards.xml", not "iestandards.xml". (The difference is very significant for anyone using e.g. Apache on Linux.) Later in this post you also mention "IESettings.xml", which probably should be "IEStandards.xml" too.Anonymous
July 02, 2009
The comment has been removedAnonymous
July 02, 2009
Many work/information for less result.Anonymous
July 02, 2009
It's great the IE8 Team has added this feature to use the X-UA-Compatible tag to remove one's domain entry from a user’s Compatibility View list. "If IE were to remove the entry for ‘example.com’ from the user’s list based solely on the presence of the HTTP header / <META> tag value found at ‘support.example.com’, the user could encounter a compatibility failure when they visit non-updated content at ‘example.com’ or ‘mail.example.com’. Checking for the ‘IE8StandardsMode’ file at the root domain level solves this case by requiring that someone “authoritative” for the domain signal list cleanup. That way, IE users can be assured of a consistent compatibility experience on the domain." Look at this scenario here: 'example.com' and 'support.example.com' are owned by different individuals and the owner of 'example.com' places an HTTP header / <META> tag after updating the site, while 'support.example.com' has not been updated. Won't users experience a compatibility issue when they visit the non-updated content at ‘support.example.com’? In this case does IE8 still view 'example.com' as “authoritative”? Or am I missing something here?Anonymous
July 02, 2009
The comment has been removedAnonymous
July 02, 2009
The comment has been removedAnonymous
July 02, 2009
The comment has been removedAnonymous
July 03, 2009
IE8 apparently has some bugs which M.S. has not ironed out that work correctly previous in IE versions. <p><strong>Bug issue:</strong> Transparent animated GIFs when repeated (repeat-x or repeat-y) in a background, the transparency fails and shows as a black cover.</p> <p><strong>Replicated sample:</strong> <br /> <br /> <br /> this bug is being replicated and displayed for the time being on <a href="http://www.ahacks.com/">www.ahacks.com</a></p>Anonymous
July 03, 2009
@Lenard, the problem is even more complicated when someone sells his/her sub-domain, support.example.com, and the new owner of the sold sub-domain moves it to another server. In this case, why should IE8 still give the owner of the domain, example.com, the "authority" to define how the sub-domain, support.example.com, should be viewed? In my opinion, IE8 needs to give "independence" to sub-domains.Anonymous
July 03, 2009
@Quality Directory As a site author you always have control over how your site is viewed by an visitor. If you set X-UA-Compatible to IE=EmulateIE7 on the subdomain with legacy apps, then that will override this setting. The purpose of this feature is to allow domains to clear themselves from a list that is stored locally on each users machine.Anonymous
July 04, 2009
@Michael Benny, Thanks for replying and enlightening me. One more question, please. After setting X-UA-Compatible to IE=EmulateIE7 on the sub-domain with legacy apps, the iestandards.xml should have a root XML element: <IE7StandardsMode/>. That's Am I right?Anonymous
July 04, 2009
@Quality Directory In IE8, the iestandards.xml will only interpret a root element with the value <IE8StandardsMode /> to remove a domain that is already on a visitor's Compatibility View list. But, even if the domain root has that available, setting the X-UA-Compatible to IE=EmulateIE7 will store force those documents to behave like IE7 (where we use doctype switching to determine using quirks mode or strict mode 'IE7') When applying this to the documents in an entire subdomain, I would recommend using a serverside HTTP header to ensure that legacy documents do not need to be updated, and that it is applied to all the documents there.Anonymous
July 05, 2009
How is it possible to Uninstall Internet explorer at Win. Vista?Anonymous
July 06, 2009
@arvids: You can uninstall IE8 to go back to IE7 by following the instructions here: www.enhanceie.com/ie/ie8.asp#uninstallAnonymous
July 06, 2009
@James, as far as I can tell, the X-UA-Compatible:IE=IE8 header does override the behavior where a document with a leading comment is kicked over to quirks mode.Anonymous
July 06, 2009
@eric, great news - thanks for clarifying... I think I got confused since document.documentMode returns "CSS1Compat", which to my mind sounds a bit bizarre when we're aiming for full CSS2.1 compatibility... Automatically assumed this meant we were still in quirks mode.Anonymous
July 06, 2009
@James: You're thinking of document.compatMode, which is a legacy property which has only two values: "BackCompat" and "CSS1Compat". http://msdn.microsoft.com/en-us/library/ms533687%28VS.85%29.aspx document.documentMode will return 5 (Quirks), 7 (IE7 Strict), or 8 (IE8 Standards). -EricAnonymous
July 06, 2009
When are you IE developers going to realise that your browser is fundamentally broken? Safari doesn't need a compatibility mode. Firefox doesn't need a compatibility mode. Opera doesn't need a compatibility mode. Chrome doesn't need a compatibility mode. Why? Because they all make a serious effort to support the web standards that have been put in place for a very good reason. We developers do not want to mess about with "compatibility mode". We want to write websites that work in all web browsers, so that we don't have to fill our web code with extra stuff just because Internet Explorer won't play nice. Once your browser passes the Acid3 test, then we'll talk.Anonymous
July 06, 2009
Compatability testing with iframes. Content hosted as a content area in a master page sizes correctly with IE 6, but any attempt to change the rendered size of an IFRAME fails in compatablity mode fails. the iframe hieght is about five lines of 10pt type regardless of settings. Are there any solutions to this?Anonymous
July 06, 2009
Neil, when are YOU going to realize that the web is "fundamentally broken"-- not the browser? Safari/Firefox/Opera/Chrome all have assorted problems rendering sites that were written (hacked together?) for IE6 and older (pre-standards/early-standards) browsers. For compatibility with those sites, users use IE, which is why it remains more popular than all competing browsers combined. It's not a coincidence. You should be praising the IE team for developing a new version of their browser with a default "Standards mode" that is compatible with those standards-compliant but somewhat-real-world-incompatible browsers. If IE8 didn't offer a "Compatibility mode" then the majority of the world that uses IE6+IE7 wouldn't upgrade, and users would stay on browsers that don't support standards as well and browsers that aren't as interoperable with those other browsers. btw: your suggestion that other browsers don't have "modes" is wrong-- look up "quirks mode" and "almost-standards" mode on wikipedia or the Mozilla Developer Center.Anonymous
July 06, 2009
I just want IE to fully support window.navigator.plugins and window.navigator.mimeTypes. If third party plugins and ActiveX objects are the weak link, let's make simple browser plugin detection more unobtrusive, instead of loading a potentially untrusted plugin and raising the fear level with in-your-face security warning popups.Anonymous
July 06, 2009
The comment has been removedAnonymous
July 06, 2009
The comment has been removedAnonymous
July 06, 2009
The comment has been removedAnonymous
July 06, 2009
The comment has been removedAnonymous
July 06, 2009
Gerard, I hope you'll agree with me that when one comes across as a whiny child, telling others what they may and may not say, they are far less effective in bringing about the changes they seek. Food for thought?Anonymous
July 06, 2009
@ahacks I checked your dynamic curtain demo with IE 8 when forced into web standards compliant rendering mode and, after a superficial examination, I'd say that there is a great probability that there is a bug in IE 8 in web standards compliant rendering mode. More time, closer examination would be required to be sure of that. It could require quite a bit of time to figure out what exactly is the bug (curtains.gif is an animated gif), then create a reduced testcase out of it since the page uses a table unneedlessly (curtains.gif is defined as a background image within a table cell), has no doctype declaration, uses deprecated elements and attributes. regards, GérardAnonymous
July 06, 2009
The comment has been removedAnonymous
July 06, 2009
P.S. does this feature also work with IE=edge? What would the XML file contain in such case? Also, how will this feature interact with IE9? Will it be possible to request proper IE8 behavior for IE8 and proper IE9 behavor for IE9? There are people that just want the sanest browser behavior available instead of enumerating the versions you have released. Please try to keep this in mind. Regards ChristianAnonymous
July 06, 2009
I just made a promotional video for IE 8... please check it out! http://www.brickfish.com/Pages/VideosSeries/VideoView.aspx?vid=8980_83053190&pid=332257&scid=465Anonymous
July 07, 2009
I am in compatibility View on a personal webpage and cannot locate a problem, error, or any mistake. Actually my opinion is solved and can move on to even more things.Anonymous
July 07, 2009
The comment has been removedAnonymous
July 07, 2009
My most of the themes of wordpress not compatible in Internet explore , what i can do to fix this problem.Anonymous
July 07, 2009
"How is it possible to Uninstall Internet explorer at Win. Vista?" ?????? msn:cagri_tekir@hotmail.comAnonymous
July 08, 2009
@koxp: You can uninstall IE8 to go back to IE7 by following the instructions here: www.enhanceie.com/ie/ie8.asp#uninstallAnonymous
July 08, 2009
I swapped the old webpage with the newer one as you suggested w/o and the needless table and proper DTD standards: http://www.ahacks.com I validated and placed the W3C kosher stamp of approval :-D , this should do away with all the naysayers. now if only the geniuses at MS would fix this bug!Anonymous
July 08, 2009
I second Christian's question: does it work with IE=edge?Anonymous
July 09, 2009
@Ian the web is "fundamentally broken"-- not the browser: It is a matter of perspective. As a web developper, I think both a brocken: IE (including IE8) is broken beacuse they still do not support a miminum of web standards. This forces web developpers to code pages that use non-standard IE-specific functions. For example, according the W3C, Javascript event can be attached by addEventListener. This function is not available in IE and a non-standard function attachEvent must be used. When IE had more than 80% of marketshare, some developpers didn't even bother and used only attachEvent. This problem has been here for years, and IE8 still does not support addEventListener! There is also a long list of standards (see Gérard's post), that IE8 does not support. This forces the use of non-standard IE-only solutions. Already Firefox 1.5 supported SVG, but still now one has to use VML for IE8. Currently the OpenLayers javascript library does not work in IE8 because of a VML problem. Indeed, one could say that OpenLayers is broken, but there wouldn't be this problem is IE would support SVG.Anonymous
July 09, 2009
Please disable all activex controls from the IE's Internet Zone, don't let IE to be attacked by a next 0-day flaw.Anonymous
July 09, 2009
The comment has been removedAnonymous
July 09, 2009
Alex, you're missing the point... the point is that if IE stopped supporting attachEvent(), then many websites would break. The IE team has to add standards support without breaking older sites, or the new versions of IE won't be adopted, meaning that standards are much slower to be adopted.Anonymous
July 09, 2009
@Mitch 74 and Christian Yes, this behavior will get triggered when using X-UA-Compatible IE=Edge or IE=IE8 as wellAnonymous
July 09, 2009
Michael Benny, it would help web designers out alot if you fixed the bug with IE8 listed here: http://en.wikipedia.org/wiki/Internet_Explorer_8#BugsAnonymous
July 09, 2009
Dear Michael thank you very much for the clarification. However, my main confusion is, that IEStandards.xml contains a version number in its "IE8StandardsMode"-tag. Which effect will this have when IE9 comes out? Will it - together with IE=edge - opt out of any future compatibility modes? Is there a way to explicitly specifiy edge-mode in the Xml-File too, so that it matches the declaration in the page, for example by writing something like: <IEEdgeStandardsMode /> I am trying to understand how this XML file (especially with IE=edge) would affect things, when IE9 or 10 or 11 comes out. Of course that is hard to tell, what these browsers will do but it would be important to know how you think this xml file will be extensible, if something like this should be needed again by future versions of IE. Or would there have to be new XML files for future IE versions, as soon as they require a similar switching mechanism? Having a version number in the root element of the XML file does not seem to make it very extensible and feels a little ad-hoc to me. Thanks & Regards ChristianAnonymous
July 10, 2009
The comment has been removedAnonymous
July 10, 2009
@Christian - you are correct about the opt-in to IE7 rendering comment. This was (as many have mentioned) an Epic Fail in terms of moving towards supporting open standards by default. I cringe every time I think about how this was brought up in discussions over and over yet the wrong choice was still made. Grrrr! I've got to go offline now... need to throw something very heavy and curse up a blue storm.Anonymous
July 11, 2009
@Ian: I know that IE would not suddenly drop attachEvent. But IE should support addEventListener in addition to attachEvent and depreciate the use of attachEvent. Having both functions (during a transition period) would not break a single web page. There should not be a problem supporting multiple APIs for tying events to HTML elements since all browser support at least 2 ways for defining events (addEventListener (or attachEvent) and the old-style onclick attributes). The addEventListener is a W3C recommendation since 2000! I just cannot understand why it takes so long for Microsoft to implement this basic function crucial for DHTML.Anonymous
July 11, 2009
The comment has been removedAnonymous
July 12, 2009
Hi, using ie8 it crash a lot sometimes it does not render well sometimes get too busy message sometimes it hang congrat ! u got an award to give me the most crashing browser !Anonymous
July 12, 2009
Good to see your guys are colaborating with the Office-97-Team to construct some beautiful diagrams there! ;)Anonymous
July 13, 2009
@Andrew: A significant majority of crashes and hangs are caused by buggy browser addons. See www.enhanceie.com/ie/troubleshoot.asp#crash As for complaints about rendering, it would be helpful to provide URLs of sites where you're having problems.Anonymous
July 13, 2009
What the $#@! is going on with IE8 recently? I can't edit any of my bookmarks, and I can't set any new bookmarks! I'm pretty sure 2 weeks ago this all worked fine. Now all my favorites don't point to a URL, but link to a file on my PC... thus creating a bookmarklet is now impossible and all the ones I have fail to work. For the record the error I get trying to add a new bookmark is: =====DIALOG========================== Windows Internet Explorer [Red X]
[Red X Icon] Unable to create '{TITLE_OF_HYPERLINK}': Class not registered [OK] =====DIALOG========================== PS This occurs if I am in regular mode or starting IE8 in no-addons mode. So much for doing any debug/development in IE this week.
Anonymous
July 13, 2009
Ian, I agree with you that in the cases you mentioned, the web page would break. Any web page made with the assumption that IE will never implement addEventListener, will break (obviously) once this function is implemented in IE. I would already be happy if Microsoft would have implemented this function in IE8 standard-compliant mode. Web pages assuming non-standard IE7 behavior have to be upgraded anyway to use IE8 in standard mode.Anonymous
July 13, 2009
@Alex - any site that has a test to check for addEventListener vs. attachEvent should be checking for the addEventListener method first. If a developer has "ASSUMED" that IE would never implement the addEventListener method they the DEVELOPER building the site need to fix THEIR code. We can't continue to support those that don't develop half-decent code. What IS important here, is that MICROSOFT publishes an INTENDED ROADMAP (hmm, that's only been said a thousand times already) that indicates that they PLAN to FIX this issue by IMPLEMENTING the addEventListener method in a future release (preferably indicate IE9 support, but even COMMITMENT would suffice) ONCE MICROSOFT has ESTABLISHED that a FEATURE is "ON THE ROADMAP" - THEN, and ONLY THEN can developers have some UNDERSTOOD EXPECTATIONS of what is coming, and start addressing these concerns. When the blog post comes out on the IE Blog that these changes are coming - developers will have the chance to start updating and investigating their code for issues etc. NOT HAVING A CLUE what is coming up in the IE.NEXT release is what is so frustrating... That said, someone should make a quick site that checks a site for you... finding code that should be looked at. e.g. Test example.com Results: 1.) Use of document.all (other than to provide workarounds for legacy IE) should be removed. 2.) Use of attachEvent (should check for W3C Standards addEventListener first) 3.) Use of createElement('HTML STRING'); should be avoided in IE8+ browsers. Use the appropriate W3C DOM methods instead. With a service like this, developers would have somewhere to go to see if they have issues as well as provide a URL for other developers to pass on to those less experienced with Web Development to set them on the right path to future success, or help them with existing issues.Anonymous
July 13, 2009
STEVE, i LIKE capital LETTERS too!!! WILL you BE my FRIEND?Anonymous
July 13, 2009
@Martin: It sounds like one or more of your registry entries was corrupted. You might try re-registering the InternetShortcut class (www.enhanceie.com/dl/RegisterInternetShortcutClass.reg) to see if that helps, but you may need to repair/reinstall.Anonymous
July 13, 2009
The comment has been removedAnonymous
July 14, 2009
@EricLaw MSFT - I tried that registry setting but had no luck. So I went to try and repair IE8, but no option for repair exists either in the IE8 menu, or the Add/Remove programs window. Therefore I've given up and am about to Uninstall/ReInstall IE8. I can't exactly say I'm enthused about this process since I'm a web developer that needs to test in IE regularly. Oh well... what's half a day of downtime... mmm can't wait for the endless reboots :-(Anonymous
July 14, 2009
@Martin: I'd start with Tools / Internet Options / Advanced / Reset IE to default settings. As to the "half a day of downtime," I'm not sure how long your days are, I've uninstalled/reinstalled IE multiple times per day for nearly a year and it takes me less than 30 minutes each time.Anonymous
July 14, 2009
@EricLaw MSFT - yeah the re-install did take less than I expected ;-)... but I still had 2 reboots (1 after the uninstall and 1 after the reinstall). That said - NO LUCK! My Bookmarks are still completely un-editable. Am I the only one experiencing this? Is there an addon within windows or IE that even though addons are disabled is still affecting my browser? I'm still in a "I can laugh at my woes" mode regarding this but if I can't solve this soon I'm going to need to test all content on another PC which won't impress me at all. Are their any specific Registry Key values I should verify are set? If I Google "Unable to create" "Class not registered" I get about 3,000 matches but most don't seem to match my issue. I did get this result though... http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.beta&tid=30d9c5e1-7afe-432a-a1ad-8ba9d7f19fad&cat=en_us_2BAF8EC5-645C-4477-A380-0F1CF6C102F9&lang=en&cr=us&sloc=&m=1&p=1 which claims to have a solution pointing to here: http://iefaq.info/index.php?action=artikel&cat=35&id=133&artlang=en I'll try this and see if it fixes IE8.Anonymous
July 14, 2009
Okay! yeehaw! that worked! well kind of. It works in that now all NEW bookmarks I add are editable but my current ~85 or so bookmarks all fail. that process was a real pita. I certainly hope that (if) this happens again, using that MVP reg tool will fix IE8 without the re-install.Anonymous
July 14, 2009
Just a question: Why is there no IE6 mode in IE8, similar to how there is an IE7 mode? Seems like a way to get those corporate IT departments to upgrade without forcing them to redo their intranets.Anonymous
July 14, 2009
The comment has been removedAnonymous
July 14, 2009
Morton: You're confused. The browser and its plugins are different things. When a Firefox extension has a bug, it's not a bug in Firefox, it's a bug in the extension. When an ActiveX control has a bug, it's not a bug "in IE" (unless the ActiveX control is a part of IE).Anonymous
July 14, 2009
I think the IE team has done a very good job to make sure older websites work with IE8. Now that they have accomplished that, they need to think about future web standards. What are your plans for IE9?Anonymous
July 14, 2009
IE team, can your browser do this? http://www.neowin.net/news/software/09/07/14/webkit-nightly-builds-enable-3d-css-transforms-for-os-x So behind the times still.Anonymous
July 14, 2009
The comment has been removedAnonymous
July 14, 2009
@David I agree! Already very curious about IE9 :)Anonymous
July 15, 2009
Since I downloaded the newer version of Internet Explorer, my coputer has a window tht constantly says Internet Explorer is shutting down. Can somebody help please We brought the tower in to be repaired and no one was able to help Can You? forcb1@aol.comAnonymous
July 15, 2009
@Joni: The majority of IE crashes are caused by buggy addons. See www.enhanceie.com/ie/troubleshoot.asp#crash for troubleshooting information.Anonymous
July 15, 2009
Here's one for the compatibility issues. I'm filing my tax return with HMRC (HTTPS throughout) and it all worked fine last year. I have 3 machines, A, desktop with Vista Business, IE8; B, laptop with XP home, IE8; C Desktop with XP Home, IE7. Other than IE, all machines uptodate with patches. End of tax return process is to produce an optional PDF of completed return. This year none of the machines will produce a PDF file. process apparently works, but no PDF appears. Compatibility mode does not produce any change. Out of interest I tried loading Firefox on A and the PDF file pops out no problem. However on IE8 the request for PDF generates a separate window; in Firefox its within the same window. Now however on A, uninstalling Firefox and going back to IE8 I 'can not log on'. Quotes because the logon procedure appears to work, in as much as if I put in an incorrect logon, I get an error, but the correct one just leaves me in the logon page. I wondered whether it was a timing issue, but having tried it after a delay, no change and I can log on properly on machines B & C. I'm going to try re-installing Firefox and see if that returns at least the logon functionality and then re-installing IE8, but given that it is burried in the update history, that is obviously not as simple as it could be.