How do I keep my site and add-ons working with Internet Explorer 8?

On this page:
For Sites
User-Agent String and Version Vector
Accessibility

For Add-ons
ActiveX Control Improvements
Loosely-Coupled Internet Explorer (LCIE)
DEP/NX Memory Protection
Manage Add-ons

User-Agent String and Version Vector

The User-Agent string, a browser’s identity as reported to websites via HTTP traffic, and version vector, a mechanism for obtaining the Internet Explorer version number that is used in the evaluation of conditional comments, have the potential to impact site compatibility. Understanding the best practices for browser detection ensures that your site continues to operate as intended when viewed by Internet Explorer 8 clients.

Best Practices for the User Agent String:

Review the sample code on MSDN for User-Agent checking - http://msdn2.microsoft.com/en-us/library/ms537509.aspx.
Review User-Agent checking code on your website.
- If your goal is to ensure Internet Explorer 8 clients receive content built and tested for Internet Explorer 7, use a greater than or equal to (>=) comparison rather than an equal to (=) comparison. Additionally, ensure that the document mode (such as quirks or strict) is compatible with Internet Explorer 8.
  
  Example
  function getInternetExplorerVersion()
  // Returns the version of Internet Explorer or a -1
  // (indicating the use of another browser)
  {
  var rv = -1; // Return value assumes failure
  if (navigator.appName == 'Microsoft Internet Explorer')
  {
  var ua = navigator.userAgent;
  var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
  if (re.exec(ua) != null)
     rv = parseFloat( RegExp.$1 );
  }
  return rv;
  }
  
  function checkVersion()
  {
  var msg = "You're not using Internet Explorer.";
  var ver = getInternetExplorerVersion();
  if ( ver > -1 )
  {
     if ( ver >= 7.0 )
       msg = "You're using Internet Explorer 7 or Internet Explorer 8. I should send a quirks or strict mode document."
     else
       msg = "You should upgrade your copy of Internet Explorer.";
  }
  alert( msg );
  }
- If you wish to target content exclusively to Internet Explorer 8—such as by sending a document in the latest rendering mode that follows CSS 2.1 guidelines—use a greater-than-or-equal-to (>=) comparison. An exact string match is not recommended because it is not "future proof." In other words, if there is an Internet Explorer 9, you will need to update your website at some future date to handle detecting that release.
  
  Example
  function getInternetExplorerVersion()
  // Returns the version of Internet Explorer or a -1
  // (indicating the use of another browser)
  {
  var rv = -1; // Return value assumes failure
  if (navigator.appName == 'Microsoft Internet Explorer')
  {
  var ua = navigator.userAgent;
  var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
  if (re.exec(ua) != null)
     rv = parseFloat( RegExp.$1 );
  }
  return rv;
  }
  
  function checkVersion()
  {
  var msg = "You're not using Internet Explorer.";
  var ver = getInternetExplorerVersion();
  if ( ver > -1 )
  {
  if ( ver >= 8.0 )
     msg = "You're using Internet Explorer 8 or later. I should send you CSS 2.1 content."
  else
     msg = "You should upgrade your copy of Internet Explorer.";
  }
  alert( msg );
  }

Best Practices for Version Vector:

Review the sample code on MSDN for using conditional comments - http://msdn2.microsoft.com/en-us/library/ms537509.aspx.
Review conditional comments in use on your website.
- If your goal is to ensure Internet Explorer 8 clients receive content built and tested for Internet Explorer 7, you must examine existing content to ensure the comment block evaluates to true for Internet Explorer 8 clients.
  
  Example
  <head>
      <title>Test Page</title>
      
      </style>
  </head>
- If your goal is to target Internet Explorer 8 clients and Internet Explorer 7 clients separately, you should use two conditional comment blocks. First, use a greater than or equal to (>=) comparison for the Internet Explorer 8 comment block. Note Using an exact string match is not recommended because it is not “future proof.” In other words, assuming there is an Internet Explorer 9, you would need to update your website at some future date to handle detecting that release. Second, use an equal to (=) comparison for the Internet Explorer 7 comment block.
  
  Example
  <head>
      <title>Test Page</title>
      <meta http-equiv="X-UA-Compatible" content="IE=8" />
      
      
      </style>
  </head>

See the User-Agent String and Version Vector white paper for more information.

Versioning and Internet Explorer rendering modes allow Internet Explorer 8 to remain compatible with today’s web content and provide a mechanism to introduce new features and stricter standards compliance. To learn more, see Versioning & Internet Explorer Modes.

return to top

Accessibility

Zoom Version 2

Page zoom lets you enlarge or reduce the view of a web page to improve readability. The feature is particularly useful on really large and really small displays, allowing for scaling of content while maintaining the intended layout of the page. The second iteration of the zoom feature set (the first shipped in Internet Explorer 7) focuses on improving the existing experience by providing a higher quality, more predictable and persistent zooming experience. Primary features in this release include the elimination of horizontal scroll bars for the majority of mainstream scenarios and the introduction of persistent zoom states.

See the Zoom Version 2 white paper for more information.

return to top

W3C’s ARIA (Accessible Rich Internet Application) Support

The W3C defines ARIA (Accessible Rich Internet Applications) as a syntax for making dynamic web content and custom UIs accessible. Internet Explorer 8 uses ARIA role, state, and property information to communicate with assistive technologies. Instead of building separate simplified web pages for accessibility, you can use ARIA to markup your rich web applications with roles, states, and properties. For example, to match the behavior you create through script, you can define a DIV element as a button, checkbox, or another ARIA role.

You can learn much more about ARIA and how to use it in your web content through the following W3C ARIA working drafts:

ARIA Introduction provides background on the accessibility problem space solved with ARIA.
ARIA Roles, States and Properties defines the ARIA syntax.
ARIA Best Practices describes how you can develop accessible rich web applications using ARIA.

See the W3C's ARIA Support white paper for more information.

return to top

ActiveX Control Improvements

Per-Site ActiveX Controls

Internet Explorer 8 allows for greater control of where and under what context ActiveX controls can run. In this version of Internet Explorer, ActiveX controls that are embedded as web objects are presented to user as add-ons. Through the Manage Add-ons dialog, the registry, or ATL Site Lock, these add-ons can be restricted for use on specific websites.

When an add-on is implemented on a website, the Information bar lets users allow an ActiveX control to run on all websites or only on the current one. Users can easily make changes to this behavior through the new Internet Explorer 8 Manage Add-ons dialog box. As in Internet Explorer 7, certain common controls (such as Adobe Flash) will initially be permitted to run on all websites in order to maintain an ideal user experience.

See the Per-Site ActiveX Controls white paper for more information.

return to top

Non-Admin ActiveX Controls

Internet Explorer 8 removes administrative involvement from the control-installation process for many existing and future ActiveX Controls. This solution addresses issues raised by customers regarding previous versions, where administration of controls was not optimal. In Windows Vista, standard users are now able to install ActiveX controls to their own user profiles without administrative involvement. In the event that a user does install a malicious ActiveX control, the system itself will be unaffected. As the installation will affect only the user profiles, the risk and cost of compromise will be lowered significantly. This feature relies on features found only in Windows Vista and is therefore not available on Windows XP. Benefits of non-admin ActiveX installations include:

Most existing ActiveX controls will not have to be rewritten to benefit from this feature; the only change will be repackaging.
This feature does not affect the installation behavior for legacy ActiveX controls.

See the Non-Admin ActiveX Controls white paper for more information.

return to top

Loosely-Coupled Internet Explorer (LCIE)

Loosely-coupled Internet Explorer, or LCIE, is an architectural effort to improve the browser by separating its components and loosening their dependence on one another. Most notably, the Internet Explorer frame and its tabs are isolated into separate processes. In Internet Explorer 8, this isolation will allow improved performance and scalability, and richer ways to recover from failures (including crashes and hangs).

This feature may impact the compatibility of extensions (ActiveX, Browser Helper Objects (BHO) or UI Toolbar) that use certain programming techniques. The following changes may impact such extensions:

The insertion of a new intermediate window between each tab and the UI frame.
- Extensions that use window hierarchy techniques to locate frame and tab windows will need to account for this.
The Internet Explorer frame process now runs at medium integrity level. Tab processes may run at low or medium always parent to this medium integrity frame.
- Extensions that subclass the frame from a low integrity tab process may no longer function correctly.
The Internet Explorer frame and tabs now run in separate processes.
- Extensions using unsupported messaging techniques may no longer function correctly. Extensions using the standard COM interfaces will not be affected.

See the Loosely-Coupled Internet Explorer white paper for more information.

return to top

DEP/NX Memory Protection

Internet Explorer 7 on Windows Vista introduced a new Internet Control Panel option to “Enable memory protection to help mitigate online attacks.” This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX). When enabled, it works with your processor to help prevent buffer overflow attacks by blocking code execution from memory that is marked as non-executable.

For Internet Explorer 8 on Windows Vista SP1 or later, we will enable this option by default.

While DEP/NX is not a panacea against all memory-based vulnerabilities, when combined with other technologies like Address Space Layout Randomization (ASLR), it helps prevent reliable exploitation of common buffer overflow vulnerabilities in Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.

DEP/NX Compatibility

For Internet Explorer 7, DEP/NX was disabled by default for compatibility reasons. Several popular add-ons were not compatible with DEP/NX and would crash when Internet Explorer loaded them with DEP/NX enabled. The most common problem was that these add-ons were built using an older version of the ATL library. Before version 7.1 SP1, ATL relied upon dynamically generated code in a way not compatible with DEP/NX. While developers of many popular add-ons have since released updated extensions compatible with DEP/NX, some add-ons may not be updated before Internet Explorer 8 becomes available.

Fortunately, new DEP/NX APIs have been added to Windows service packs to enable use of DEP/NX while retaining compatibility with older ATL versions. These new APIs allow Internet Explorer to opt into DEP/NX without causing add-ons built with older versions of ATL to crash.

In rare cases in which an add-on is not DEP/NX compatible for reasons other than outdated ATL usage, a group policy option will be available to enable an organization to opt-out of DEP/NX for Internet Explorer until an updated version of the broken control can be deployed. Local administrators can control DEP/NX by running Internet Explorer as an administrator and clearing the Internet Options / Advanced / Enable memory protection to help mitigate online attacks option.

Developer Call to Action

If you build Internet Explorer add-ons, you can help ensure a smooth upgrade to Internet Explorer 8 by taking the following steps today:

Rebuild older ATL code against ATL v7.1 SP1 or later (Visual Studio 2005 includes ATL 8.0).
Set the /NXCompat linker option to indicate that your extension is compatible with DEP/NX.
Test your code with DEP/NX enabled in Internet Explorer 7 on Windows Vista.
Opt your code into other available defenses like /GS, /SafeSEH, and ASLR.

return to top

Manage Add-ons

The add-on management experience in Internet Explorer 8 has been updated so that users can more easily find, research, and manage the toolbars and controls running within the browser. Introduced in Windows XP Service Pack 2 (SP2), Manage Add-ons is a place where users can view and enable or disable the add-ons currently running on their machine. Manage Add-ons tracks the following types of add-ons: ActiveX Controls, Browser Helper Objects (BHOs), browser extensions, Explorer Bars and toolbars. In addition in Internet Explorer 8, the list of add-ons managed in Manage Add-on is being expanded to include search providers and Activities in Internet Explorer 8. Existing controls do not have to make any changes to continue to be managed in Internet Explorer 8.

See the Manage Add-ons white paper for more information.

return to top