IE9 Feedback: Platform Previews through Beta

Thanks for your Feedback!

When we released the first IE9 Platform Preview, we talked about the importance of feedback. Since that first release last March, we’ve released six more platform previews, an IE9 Beta, and a bug-fix update to that Beta and the IE9 RC. We want to thank everyone who provided feedback during the last nine months. Sharing your experiences with the IE Test Drive and Testing Center while testing your sites for compatibility and trying out new features like Pinned Sites all helps make IE9 better. We’d like to take this opportunity to share with you the trends we are seeing in feedback, provide visibility into how we handle that feedback, and show how it is has affected the Release Candidate.

The Numbers

When we discussed our approach to feedback systems, we talked about our commitment to take action on every piece of feedback we receive. This approach is different than other feedback systems. The level of interest in the previews and Beta so far has been strong. At the time of this post, the IE9 Platform Previews have been downloaded over 3.3 million times, the Beta over 25 million times, and we’ve received over 17,000 bugs from the public via Connect. That is 23% more downloads than IE8 Beta 2 during the same period and over three times as much feedback as we received for the entirety of IE8—from Beta through RTM.
These numbers represent interest from customers, developers and enthusiasts around the world. Over 8,000 people have logged bugs on over 8,000 domains worldwide. More than 7,500 of these users are providing feedback for the first time with IE9. We welcome these new users, just as we marvel at those who have provided exceptional contributions. Two users, Wheels of Flames and the dees (registration required), have logged over 200 bugs each, while another three, iecustomizer, Taciturne, and FremyCompany, have each logged over 50. Wow! We cannot thank these and our other users enough for investing their time and effort.

More on our Feedback Systems

We investigate each item of feedback for reproducibility and uniqueness. Unique reproducible bugs are ranked in terms of importance and severity—a process we call triage. Once we investigate and triage an issue, we update the status in Connect.
Some of the feedback we receive is about the feedback management process itself, and questions around what the different resolutions for reported issues actually mean. Here are the resolutions you’ll see on Connect, and what they mean:

• Fixed: The engineering team reproduced the issue and has fixed it in this release. This is clearly our favorite resolution.
• Not Repro: The engineering team could not reproduce this issue. Some issues are very subtle and hard to reproduce across different systems and Internet access configurations. Help from the community here is crucial. (If you can still reproduce the problem, please provide step-by-step details and additional configuration information by attaching an IEDiag log file and a Fiddler trace while reproducing the problem. If possible, please try to reproduce on a second machine.)
• By Design: The engineering team expects the behavior noted in the report. By Design means we understand the feedback and the behavior is deliberate. An example of an issue that we consider By Design is that the Platform Preview does not install on Windows XP. IE9 has security (e.g. protected mode) and graphics (e.g. DirectX) functionality that requires other components not available on Windows XP, an operating system that first shipped in 2001 with IE6. Because of the decision to not support Windows XP, the issue of IE9 not installing on it is “By design.”
• Won’t Fix/Postponed/Feature Suggestion: The engineering team investigated the issue or suggestion and will not address it in this release of IE. We will consider the issue for the next product cycle, especially if the severity or frequency of the issue changes. An example here might be work that is out of scope for the current release (e.g. MathML support), or features that do not fit in the overall context of the release.

How it Comes Together

Your feedback helps us make IE9 better and we appreciate it. We use the feedback that you provide to aggregate and identify your top issues. We tally the number of duplicate bug reports, number of validations (when users click “I can reproduce the issue too” on Connect), and the number of comments to identify the most critical user concerns. From there, one of the steps of triage is to determine if the feedback is a product issue (code defect), feature request, or general feedback. We read all feedback and assign it an action on the path to closure. Additionally, every week we look at the list of top issues as a team to ensure we are doing the right thing for our customer concerns.
When we talked about how we listened, learned, and refined the user experience, we noted that your feedback was critical to several of the major changes we made in the IE9 RC. We provided several examples of how user input from Connect, blog post comments, and other sources led to improvements in the browser. Feedback directly contributes to what we call “Design Change Requests,” which typically occur when feedback indicates that a design decision should be revisited. Whether they were feature requests or bugs, we took all of the top issues seriously, fixing all of the top five issues and seven of the top 10. Note that we fix these at various times throughout the product cycle – it’s important for users to test out each new Platform Preview and full browser build to verify that their issues are resolved and validate the improved quality of the product.

Top 10 Concerns in IE9 Beta

Feedback ID	MS Connect Title	Duplicate Reports	Validations	Community Comments	Resolution Description
598728	[REQUEST] Make IE9 URL-BAR better please IE team!	283	351	177	The core of this issue is the desire to see more of the address and tabs for users who open many tabs. In response to this feedback, with the RC we added a feature to allow you to separate the tab bar from the address bar.
599845	Loading Circle	298	252	138	Users found that the spinning circle in the tab stopped before the page had fully loaded. We’ve fixed this in RC.
598400	Download speed not shown	169	198	80	Users wanted to see the speed of multiple downloads in progress. With RC, we’ve added this feature to the top level of the Download Manager.
598389	Highlighting text and releasing the button over a link clicks the link	123	117	59	This issue was fixed in Platform Preview 6
598102	Please return my Menu Bar	102	131	36	Users couldn’t find the Menu bar (which was found using the Alt key in the Beta). With the RC we’ve updated the right click interface in the title bar and tab bar to allow you to turn on the Menu bar permanently.
600623	Feature Request - Move Home, Favorites, and Tools buttons	88	87	30	With RC we addressed the primary user concern around the option to have a dedicated tab row along with showing the menu bar. With these options, users can get the favorites and tools option in the top-left region.
598091	Websites cannot be pinned to taskbar it taskbar is on the left of the screen	88	60	16	When users had their Taskbar anywhere other than the bottom of the screen, attempting to pin a site by dragging a tab was interpreted as an Aero Snap command for a side-by-side view. With the Release Candidate, the initial drag to a non-bottom aligned Taskbar is interpreted as a pin command – if you then drag your mouse away and back over the Taskbar, it will be interpreted as a Snap.
598615	Back button is drawn incorrectly	82	69	39	The clipping of the Back button is By Design. It is designed to provide some visual tension for the left side of the browser, balancing out the three buttons on the right side. It emphasizes the importance of site content over the browser frame.
598257	spellchecker	57	79	44	We are not addressing this feature request in IE9, but will be considering it for future versions.
598737	Show Desktop not showing Sidebar Gadgets	52	77	26	Gadgets should always remain visible on your desktop, even when you hit the Show Desktop button. We fixed this issue in the RC.

While we are pleased to be able to fix many of the top issues, in the end we won’t fix every issue reported. As we said above, there are a variety of reasons why we decide to not fix a reported issue. Some of these issues are external to IE, some may introduce security issues, while others may be limited in their scope of impact. Sometimes we receive conflicting feedback – while one segment of users may like the cut-off Back button, others may not. In all circumstances, our decision making revolves around delivering a quality default experience for all of our users.

Looking Forward

Our continued request is that you download the IE9 Release Candidate, try the samples on the test drive site, and try your own sites. Visit your favorite sites, try out the new features we announced and changes we made to the browser frame, and send us feedback about your experiences. Developers, send IE9 the same markup that you send to other browsers and use feature detection, not browser detection, to alter behavior between browsers and versions, when needed.
The IE7 compatibility view built into IE9, which some sites may run in, does not offer the best performance possible. If you still have sites that run in IE7 compatibility mode we recommend that you move those to IE9 standards mode. We want sites to get the full performance benefits of IE9 that come with running in IE9 standards mode. We also want your feedback from handing IE9 the same markup you hand other browsers.
Thanks again for your participation in the Internet Explorer feedback program.
—Justin Saint Clair, Program Manager

Web Tracking Protection: An Emerging Internet Standard that Helps Protect Consumers from Tracking

Today, the W3C has accepted and published Microsoft’s member submission for an Internet standard to help protect consumer privacy. This announcement from the Web standards body responsible for HTML5 is an important step forward for people and businesses that interact online.

The privacy concerns from consumers and academics and governments world-wide have both technical and non-technical aspects. Addressing these concerns will involve technology. The W3C’s involvement provides the best forum possible for that technology discussion. Just as the community has worked together at the W3C on interoperable HTML5, we can now work together on an interoperable (or universal, to use the FTC privacy report’s term) way to help protect consumers’ privacy.

Addressing these privacy concerns will also involve much more than technology. Governments and regulators and law enforcement have a crucial role to plan in addressing the public’s privacy concerns. There’s a large and growing body of work that shows the complexities of the non-technical issues they face. Some examples are the privacy report from the US Federal Trade Commission in December 2010, the work of the EU’s Article 29 working group and EU ePrivacy directives, and public discussions like the recent one at the UC Berkeley. 

The technology solutions we work on as an industry need to work well with the social, economic, and political discussions that occur world-wide outside the W3C. The FTC’s report, for example, provided a context that made our announcement of IE9’s Tracking Protection functionality much easier for many to understand. That report also notes the following issues and questions about technical solutions:

• A universal mechanism should not undermine the benefits of online behavioral advertising, including funding free online content and providing personalized advertisements that many consumers want.
• A universal mechanism should be different from the Do Not Call program (which has a registry of consumer phone numbers) in one key regard:   it should not require a registry of unique identifiers as that could negatively impact privacy.  Instead, the FTC recommended a browser-based mechanism.
• Should a universal choice mechanism go beyond a total opt-out and include an option that lets consumers make granular choices about the types of data they are willing to have collected from them and the type of advertising they wish to receive?
• Universal choice mechanisms should be understandable, simple, easy to find and very clear about what the choices mean.
• There are a number of questions about the mechanics of a universal mechanism, including how it should be publicized, how it can be as clear as possible, how many consumers are likely to choose to opt out of targeted advertising, what will happen if many opt out and whether legislation should be passed if the private sector does not implement a universal mechanism voluntarily.

Through this lens, the W3C’s Web Tracking Protection, based on the IE9 Tracking Protection functionality, is a strong step forward.

The proposal with the W3C is a significant step toward enabling an industry standard way for Web sites to (1) detect when consumers express their intent not to be tracked, and (2) help protect themselves from sites that do not respect that intent. Enabling consumers merely to express their intent to not be tracked is just not sufficient. It’s a subset of what effective tracking protection should do. IE9’s Tracking Protection also enables consumers to block the content that does the tracking. You can see some initial examples of Tracking Protection lists here. This diagram illustrates how a browser that supports Web Tracking Protection works with lists:

We look forward to working with the community through the W3C on a common standard for Internet Privacy. It will help consumers who use browsers that support it.
—Dean Hachamovitch, Corporate Vice President, Internet Explorer
Updated 2/24: added link to announcement of IE9's Tracking Protection

ActiveX Filtering for Consumers

ActiveX Filtering in the IE9 Release Candidate gives you greater control over how Web pages run on your PC. With ActiveX Filtering, you can turn off ActiveX controls for all Web sites and then turn them back on selectively as you see fit. While ActiveX controls like Adobe Flash are important for Web experiences today for videos and more, some consumers may want to limit how they run for security, performance, or other reasons.
In this post, we’ll show how you can improve your browsing experience with ActiveX Filtering. We’ll walk through how this feature works in IE9 and share details on how IT administrators can deploy this feature in corporations. In a future post we’ll share some best practices that Web site authors should use to ensure that their sites work well with ActiveX Filtering.
You can try out ActiveX Filtering in the Release Candidate using this demo from the IE TestDrive site. You can also see the feature in action in this short video:

Background: ActiveX Controls & Browsing

To display interactive content and video, many of today’s Web sites use plug-ins like Adobe Flash or Microsoft Silverlight. “ActiveX” is the technology these plug-ins use to run inside of IE. Like other add-ons, they are essentially Windows applications that run in the browser. Poorly written add-ons and ActiveX controls can therefore affect IE’s performance, reliability, security and privacy in similar ways.
Some controls may be used to display undesirable or malicious content, preventing you from having a good experience when viewing a Web site.

ActiveX content may prevent you from having a good experience viewing a Web site

Some consumers are concerned about the potential impact of ActiveX controls and would want to limit them to run only on Web sites where you need them to view the content. ActiveX Filtering is a built-in, more generalized version of browser extensions like FlashBlock and ClickToFlash.

Introducing ActiveX Filtering

With ActiveX Filtering, you choose which sites are allowed to use your ActiveX controls, while all other Web sites cannot use them. ActiveX Filtering helps limit the impact that ActiveX controls have on your browsing experience since the controls can run only on specific sites. ActiveX Filtering also prevents Web pages from showing potentially unwanted content that relies on ActiveX controls.

ActiveX Filtering enables you to focus on the content you want to view

By default, IE9 does not filter any ActiveX controls on Web sites to ensure you experience the sites as intended by their authors. If you desire increased control of ActiveX controls while browsing, you can enable ActiveX Filtering via the Tools menu:

Tools / > Safety > ActiveX Filtering

Once you enable ActiveX Filtering, IE prevents ActiveX controls from running on all Web sites. When you visit a Web page that contains ActiveX controls, notice that ActiveX content is blocked from loading on the page. IE displays fallback content chosen by the site’s author if it is available.
Instead of displaying a prominent notification prompting you to install or enable controls, IE stays out of the way of your browsing while it also makes it easy for you to turn off filtering when you need to. IE displays an icon in the address bar to indicate that some content has been filtered on the site.

If a Web site contains ActiveX content that you want to view, you can turn off filtering for just the current Web site. When you click on the icon in the address bar, IE displays the fly-out window:

You can click “Turn off ActiveX Filtering” for just the current site. Once you take action, IE refreshes the Web page to ensure that ActiveX controls are properly instantiated in place of any fallback content that was originally present on the page. ActiveX controls from other Web pages under the same domain (in the above case, msn.com) will also be unblocked.
The icon on the address bar changes color to indicate that you have turned off filtering on this Web site. After you’ve finished viewing the content, you can turn ActiveX Filtering back on by clicking on the icon again, which re-displays the fly-out window:

The address bar icon and fly-out window are also used for the Tracking Protection feature. If you have installed a Tracking Protection list you may see this icon appear on sites that only contain content blocked by Tracking Protection. In these cases you’ll need to launch the fly-out window to determine what content has been blocked. If you want to reset all the exceptions you’ve made for ActiveX Filtering and Tracking Protection, you can use Delete Browsing history. Be sure to select just this one checkbox:

Section to delete ActiveX Filtering data from the Delete Browsing History dialog

ActiveX Filtering for Managed Desktops

Administrators can deploy ActiveX Filtering for their organizations easily by setting a group policy. The feature is disabled by default for the Local Intranet Zone so that intranet Web sites and LOB applications can continue to use ActiveX controls without disruption, and can be adjusted separately for each security zone.

Try it out!

To have a trustworthy browsing experience, it’s important that you are in control of the applications running in your browser. With ActiveX Filtering, you can now browse the Web with more control of your ActiveX controls. You can easily turn on the controls on sites that contain ActiveX content you want to view. This feature successfully limits the content that is allowed to run ActiveX controls, thus minimizing any potential performance, reliability, security or privacy impact on your browsing experience.
We encourage you try out this feature on the Internet Explorer 9 Release Candidate today, using the demo available from the TestDrive site. Please let us know if you find sites that don’t work properly with ActiveX Filtering. We look forward to hearing your feedback through blog comments and the Connect site.
—Herman Ng, Program Manager, Internet Explorer

Sharing Links from IE10 on Windows 8

Sharing a link to a Web page is a common activity on the PC, and it gets better with IE10 on Windows 8. One of the new features on Windows 8 is the Share charm, which allows you to seamlessly send content between apps on your PC. Previously, if you wanted to share an interesting article with your friend, or post a funny picture on your blog, you’d copy the link from the address bar, switch to a different site or app, and then paste it. Now, with the Windows 8 Share charm, you can share directly from the browser without ever leaving your current page.
When you use the Share charm to share a site from the browser, IE10 creates two data formats that contain relevant content – the URI, and some HTML that includes a rich representation of the page. Here are two examples of data that get shared for a YouTube video:

The URI (of the current site)

http://www.youtube.com/watch?v=4DbgiOCTQts

The HTML (with a link preview)

An example of IE10's rich preview of Web pages

Both of these data formats are created for an “implicit” share, which is the name for what happens when you share the site that you are currently viewing. Since Web pages can be represented as hyperlinks or a rich HTML link preview, IE10 includes both types of data. Of course, if you aren’t sharing the whole page, but rather, some content that you’ve highlighted, IE10 will share the HTML of your selection instead of the URI and the link preview. In this case, sharing a selection would be called an “explicit” share, and does not include the link. This post describes the link sharing case, how IE10 participates in the Windows 8 Share contract using HTML, and how Web developers can create link previews with just a few meta-tags.

The Share Charm and IE10

Here’s a video of how a user might share links from the browser to an app that uses HTML.

Sharing from IE10: Link Previews in Action

In this video, “Stash” is a sample link saving app that makes use of the Windows share charm with HTML. The sample app simply supports the HTML data format for sharing, and IE provides the link preview. Link previews are HTML that contains a title, image, and description for every shared link. This makes it easy for you to recognize the site content. If you have Windows 8 Consumer Preview and Visual Studio 11 Beta, you can download and run Stash on your own PC. Stash integrates with the Windows 8 Share contract as a target app, as you can see below. Below, you can see a high-level diagram that shows how links are shared from IE10.

Diagram: Sharing a link from IE10 to target apps, using the Share charm’s data package

Windows 8 Share charm handles the coordination between the source and target apps to provide an integrated sharing experience across all apps. This removes the need for target and source apps to be aware and coordinate between each other.

Sharing the Web is Better, Start to Finish

The Web is made up of HTML. That’s why HTML is one of the most important data formats in IE10’s integration with the Share contract. IE10 creates link previews to both provide a better sharing experience for users, and to help connect Web developers to Windows 8 Share. With a little extra meta-data markup, sites can define what information is included in their link previews. On the other end of the share contract, target apps that support the HTML data format can get the full experience of contextual Web hyperlinks without having to parse a single site. The end result is a rich, modern, and fluid sharing experience, from end to end.

Screenshot of target apps available in Share pane

Screenshot of Stash’s Share Pane

When you share a Web site, IE10 parses that site to create a link preview. In the example above, it’s a short snippet of content that represents a movie page on IMDb. The goal of sharing HTML, in addition to the URI, is to share the best possible representation of what the user intended to share, so IE10 creates link previews for all implicit shares. The benefits of HTML are that it can include more information than a URI, and the content of the HTML is more meaningful than a hyperlink. In the words of Leslie Knope, no one wants to share that “complicated nonsense.”

From NBC’s Parks and Recreation, Season 4, Episode 16

So, as you can imagine, we would have never ordered a sign with all this complicated nonsense because, you know, we’re not insane.

Depending on the target app, though, sometimes rich content is not the best kind of data, and a URI is more useful. For example, blogging apps can take advantage of rich HTML content, and SMS apps would do best to use the URI. Developers of Metro style apps choose the data format(s) that make most sense for their app to receive, following the Windows 8 Share guidance.

Sites Use Markup to Define What IE10 Shares

Since IE10 uses existing markup meant for sharing on the Web, many sites will already look great when sharing HTML link previews on Windows 8. We support the Open Graph protocol as a simple way to add meta-data about the page. When users share sites on Facebook and through Windows 8 and IE10, you can use OpenGraph to control the way your Web page appears to others.
Here’s an example of an IE test drive demo that uses this markup:

<head>

<meta name="description" content="Brick Breaker TestDrive Demo Game, Performance and Touch benchmark" />

<title>Brick Breakertitle>

<meta property="og:image" content="Views/Homepage/Icons/BrickBreaker.png" />

head>

IE looks for the following tags in the site’s markup to create the page’s link preview.

Property	HTML tag	Character limit
Title 1		2,048 (limit for image URI)
Image 2		2,048 (limit for image URI)
Image 3		2,048 (limit for image URI)
Image 4		2,048 (limit for image URI)

Note that this is the order in which we parse for each attribute. For example, if both Image 1 and Image 2 tags are present, we’ll use the Image 1 tag. Additionally, if more than one tag of any type is present, we use the first one you list in your markup.
For character limits, if the description is longer than the maximum length, IE will put a “…” at the end in the preview.
Make sure to include at least one of each property in your site markup to get your pages looking great for sharing in Windows 8. See this demo on the IE Test Drive site for more on how the markup works.

Apps Get the Benefit of a Powerful Web Browser

If your app supports the Share target app contract, you should consider whether it makes sense for it to support HTML as a shared data format. Apps that use HTML can benefit from the link previews shared by IE10 because IE10 does all of the heavy lifting. It parses the site and puts together a short and informative link preview, and all your app needs to do is display and host the HTML. The hyperlink is embedded within the preview, so it functions just like a Uri, but looks much better. This way, apps that don’t have the resources to parse the Web to condense pages into small, rich previews, can still display contextual links as HTML.
Many apps, in addition to IE10, will share HTML. Target apps that accept HTML must be agnostic about the source of the shared data. As noted above, IE10 shares HTML for both implicit and explicit sharing scenarios, so sometimes the HTML is a link preview, and sometimes it’s a user selection. In either case, the content of the HTML is the best possible representation of what the user intended to share. Here’s a snippet of what the link preview HTML generated by IE10 will look like when it’s added to the Share charm’s Data Package:

<html>

<body>

<style>

/* IE10\uc1\u8217?s metro-style CSS attributes */

style>

<a class="snippet-URL" href="http://site_link_goes_here">Website Title goes herea>

<table>

<tr>

<td class="snippet-image">

<img src="image_link_goes_here" />

td>

<td class="snippet-text">Website description goes here td>

tr>

table>

body>

html>

For an example of an app that uses HTML from IE10, download the sample app “Stash” seen in the video above. This app demonstrates how a Metro style app can use HTML data as a share target.
Here’s a code snippet from the app, which shows how Stash uses HTML sent from the Share charm.

function activatedHandler(eventArgs) {

// In this sample we only do something if it was activated with the Share contract

if (eventArgs.detail.kind

=== Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {

// We receive the ShareOperation object as part of the eventArgs

var shareOperation = eventArgs.detail.shareOperation;

if (shareOperation.data.contains(

Windows.ApplicationModel.DataTransfer.StandardDataFormats.html)) {

shareOperation.data.getHtmlFormatAsync().then(

function (htmlFormat) {

// Extract the HTML fragment from the HTML format

var htmlFragment = Windows.ApplicationModel.DataTransfer

.HtmlFormatHelper.getStaticFragment(htmlFormat);

// Display the HTML in the Share pane.

id("htmlArea").innerHTML = htmlFragment;

});

}

}

}

The above code lets Stash accept HTML when the user selects it as their Share target. For more on developing a Share target app on Windows 8, see the MSDN Quickstart page for receiving shared content.
Happy sharing!
—Alex Feldman, Program Manager, Internet Explorer

IE9’s Document Modes and JavaScript

• Internet Explorer 9 standards document mode enables the same markup and same script to work across browsers. You should use Internet Explorer 9 standards document mode to take advantage of new features in the ECMAScript, Fifth Edition standard (ES5) and IE9’s enhanced DOM programmability. However, to maintain fidelity with older versions of IE, the JavaScript functionality supported in IE9’s Quirks mode, IE7 standards mode, and IE8 standards mode differs somewhat from IE9 standards mode. You can use these compatibility modes and the F12 developer tools to migrate your site to use the new ES5 features on your own schedule, while your site continues to run in IE9.
  In two blog posts – Testing sites with Browser Mode vs. Doc Mode and IE’s Compatibility Features for Site Developers – Marc Silbey explains how to take advantage of document modes in Internet Explorer 9. He also discusses how to use Browser Mode and Document Mode to test sites for IE9 and previous IE versions. In this post, we’ll explore what developers need to know about how the document modes in IE9 affect JavaScript code.
  

  Document Modes and JavaScript Support

  As mentioned in a previous post, you (the developer) control the document mode that IE will use when rendering your site by using the DOCTYPE and X-UA-Compatible Meta tag or HTTP Header. Chakra, the new JavaScript engine in IE9, uses the document mode to determine the JavaScript features to support. The table below summarizes Chakra’s JavaScript support under the four IE9 document modes. For information on how to set the document mode, see our post on IE’s Compatibility Features for Site Developers and the Determining Document Mode diagram for IE9.
  

  Document Mode	Description
  IE9 standards	IE9 standards document mode is the default if a Web page uses a standards-compliant DOCTYPE and doesn’t specify an X-UA-Compatible meta tag. In this mode, IE supports ECMAScript, Fifth Edition features, enhanced DOM programmability, and removes some of the key differences between our IE8 JavaScript implementation and the ECMAScript, Third Edition Specification.
  IE8 standards	IE8 standards document mode supports the JavaScript additions we made in IE8 to implement portions of the then-draft ES5 standard, such as native JSON support and accessor support on DOM objects. This mode also supports the changes made in IE8 to fix some key issues raised by developers.
  IE7 standards	IE7 standards document mode supports the JavaScript functionality that was available in IE7, including the Microsoft extensions supported in the IE7 standards mode in IE7 and IE8.
  Quirks	Quirks mode supports the JavaScript functionality of IE6, and the Quirks mode of IE7 and IE8.

  Your JavaScript may behave differently in the different document modes. Here are three examples of code that, due to our conformance to the ES5 standard, provide different results depending upon the document mode. For additional compatibility guidance and JavaScript feature changes in IE9, see the Compatibility Cookbook on MSDN, the blog post Enhanced Scripting in IE9: ECMAScript 5 Support and More, the ES3 Standards Support document, and the Microsoft JScript extensions to the ES3 standard.
  

  Arguments.caller

  Arguments.caller is not supported in IE9 standards document mode, per ES5 section 10.6. Consequently, Quirks, Internet Explorer 7 standards, and Internet Explorer 8 standards document modes in IE9 alert “1” for the following code. Internet Explorer 9 standards mode issues the script error "Unable to get value of the property 'length': object is null or undefined."

  function alertCallerLength() {
      alert(arguments.caller.length); // IE9 standards doc mode issues script error
  }
  
  function callingFunction() {
      alertCallerLength();
  }
  
  callingFunction(1)

  Indirect Eval

  The ES5 standard requires that indirect evals—invocations of eval() by using a name other than “eval”—resolve to a global scope rather than a local scope. To support compatibility with previous versions of IE, Quirks, IE7, and IE8 doc modes maintain a local scope for indirect evals, while IE9 standards mode interprets them according to the global scope.

  var x = "Global Scope";
  var myeval = eval;
  
  function f() {
      var x = "Local Scope";
      alert(myeval("x"));
  }
  
  f(); // IE9 doc mode alerts "Global Scope"; other doc modes alert "Local Scope"

  String objects

  In IE8 and IE9, indexed properties can be added to string objects. With IE8 you can create these properties for all indexes regardless of the length of the string object. In IE9 you can create indexed properties, but only for indexes that are greater than the length of the string. IE9 will also give you indexed access to the string itself. In the example below, we create a String object and then attempt to define values for array indices of that object. IE8 and the IE9 compatibility document modes allow us to create an array object with the same variable name as a string object; IE9 standards mode does not. As a result, in IE9 standards mode, the function returns “H-e-l-l-o- -W-o-r-l-d.” In the other document modes, the function returns “-1----5----9-.”

  function JoinDemo(){
      var a = new String("Hello World");
      a[1]="1";
      a[5]="5";
      a[9]="9";
      alert(Array.prototype.join.call(a, "-"));
  }
  
  JoinDemo();
  // IE9 standards doc mode alerts "H-e-l-l-o- -W-o-r-l-d"
  // IE8, IE7, Quirks doc modes alert "-1----5----9-"

  Testing JavaScript in Different Document Modes

  As you migrate your site to IE9 standards doc mode, you may find that some of your script behaves differently than in Internet Explorer 8. The F12 developer tools in Internet Explorer 9 enable you to test your scripts in the four document modes. Changing the Document Mode through IE’s F12 developer tools refreshes the page and instructs the Chakra JavaScript engine to reparse the script according to the specified document mode. You can use these document modes to help debug your scripts as you migrate your code to IE9 standards mode.
  

  

  Additional Information

  We have made every effort to ensure that IE9’s compatibility document modes support the same functionality that we shipped for these modes in IE8. However, because the Chakra engine is not the same as we shipped in IE8, it is bound to have some differences. The Internet Explorer 9 Compatibility Cookbook explains some of these key differences. Briefly the following are affected:
  

  • Enumeration order differs between IE8 and IE9.
  • Internet Explorer 9 correctly handles array elements with large indices.
  • Math precision differs between IE8 and IE9.

  If you encounter additional compatibility issues, we’d like to hear about them. Please send us your feedback via Connect.
  We’d also like to point you to some blog posts and IE Test Drive demos that we have created to explain or showcase the new functionality that Chakra introduces, and some differences from IE8.
  

  • Enhanced Scripting in IE9: ECMAScript 5 Support and More describes the new ES5 features that are now available in Chakra and IE9.
  • Exploring IE9's Enhanced DOM Capabilities explains the IE9 enhanced DOM programmability support, which brings DOM objects closer to native JavaScript objects. The Enhanced DOM Capabilities demo showcases these concepts.
  • ECMAScript 5 Part 1: Reusable Code talks about the new JavaScript object model introduced by ES5 and how developers can use the new Object reflection features to develop controlled reusable components. The ECMAScript5 Breakout and Texas Hold’em demos also showcase some of these concepts.
  • ECMAScript 5 Part 2: Array Extras talks about some of the common loops and array methods that are now implemented natively within Chakra. ECMAScript5 Tile Game and ECMAScript5 Arrays demo this functionality.

  In summary, IE9 supports different ECMAScript standards and extensions in different document modes. The new IE9 document mode allows you to take advantage of new ES5 features according to your schedule. We hope you find the F12 developer tools useful as you debug your code and migrate to the ES5 and HTML5 features supported in IE9 document mode.
  —Gaurav Seth and Paul Chapman, Program Managers, JavaScript
  

• Updates to Add-on Performance Advisor

  over 1 year ago

  • 31

  The Add-on Performance Advisor helps you stay in control of your browsing experience with add-ons. Since we introduced this feature in IE9 Beta, the positive and constructive feedback you provided enabled us to adjust the functionality while maintaining its original goals. You can experience these changes in action with the final release of IE9.
  In this post, we review the issues users face today with add-on performance and the benefits offered with this feature. We describe the rationale behind the key changes we made and show how they improve the user experience and more accurately measure add-on performance. Along the way, we address some frequently asked questions on the feature’s functionality.
  

  Recap: Add-ons and Performance

  Add-ons can have a material impact on browsing performance, most notably in the following activities:
  

  • Opening a New Tab
    Every time you open a new tab or browsing window, IE initializes your add-ons. The time it takes each add-on to initialize is its load time.
  • Navigating to Web pages
    Every time you visit a Web page, your add-ons can perform operations on the page, such as adding icons next to search results or scanning links to identify phishing sites. The time it takes an add-on to perform these operations for each navigate is its navigation time.

  Many users have multiple add-ons installed and running in their browsers. The cumulative performance impact of all these add-ons affects the overall experience of browsing and viewing a Web site.
  While we work with add-on developers to improve add-on performance, it’s important for you to understand add-ons’ performance impact and how to manage them. The Add-on Performance Advisor monitors add-on performance and notifies you only when your add-ons are noticeably slowing down your browsing experience. You can choose to use only the add-ons you want while maintaining browsing performance.
  

  Accurately Measuring Add-on Performance

  We made two changes to our add-on performance measurement algorithms since IE9 Beta:
  

  • IE no longer records the first load time for all add-ons after upgrading to IE9
  • IE no longer records an add-on’s first load time after it is installed and enabled for use in IE9

  Here’s a brief explanation of the change. While analyzing the load times for 15 of the most popular add-ons in IE8 we found that the average add-on load time in the above two scenarios were notably higher than the average load time during regular browsing:
  

  Load Time Measurement Scenario	Average Load Time (milliseconds)
  Launch IE9 regularly	37
  IE9 first run after upgrade	399
  Add-on first run after it is enabled in IE9	300

  This difference in load time exists because add-ons typically perform more operations when launched for the first time. Additionally, since IE takes longer to launch for the first time, it shares system resources with add-ons and will increase add-on load times.
  It’s important that we measure an add-on’s load time accurately and consistently so that you can make the right decisions on your add-ons. We decided not to record load times in the above two scenarios with this goal in mind.
  For example, in IE9 Beta you may prematurely disable an add-on that you like because its first load time is notably higher and triggers the Add-on Performance notification. With the current functionality, we will show the Add-on Performance notification only if we continue to measure high load times for that add-on.
  

  Evolving Notifications

  We received lots of good feedback regarding the design of the Add-on Performance notification since Beta. We’ve since refined the design for the final IE9 release:
  

  

  We updated the notification message and added an option in the dropdown menu for the “Ask me later” button:
  

  

  If you are satisfied with your add-on performance even though it is above your desired threshold, you can select the “Don’t disable” option to turn off the Add-on Performance notification for 30 days. If you prefer not to make a decision on your add-ons yet, you can select the “Ask me later” option which only turns off the notification for 1 day.
  Once you install and enable a new add-on, IE will turn the Add-on Performance notification back on since the new add-on may impact browsing performance beyond your previously desired levels.
  When multiple new add-ons are installed, we made it clearer to users that they can choose which ones to enable:
  

  

  Choose Add-ons Dialog

  You can launch the Choose Add-ons dialog via both the above notifications. When it’s launched from the Add-on Performance notification, we show the following variation of the dialog:
  

  

  Some of you asked how IE decides which color is used to display the bars in the above dialog. Our intention is to use the colors to indicate the minimum number of add-ons that need to be disabled so that you can stay below the threshold. In the above dialog, disabling the Contoso and Litware toolbars, which have red bars, leaves you with 0.04 seconds of total load time.
  You may decide to only use the Contoso Toolbar. If you disable all the other add-ons, we’ll display a grey bar for the Contoso Toolbar indicating that you’re now below the threshold. Similarly, you can change the default threshold to 0.50 seconds and all the above add-ons will have grey bars displayed.
  Notice that we lengthened the default height of the above dialog to accommodate 6 add-ons before requiring you to scroll. This helps you make the most informed decision on which add-ons to use since you can view the performance impact of more add-ons at one glance. We also added a confirmation dialog when you press “Disable All” so that you don’t accidentally disable all your add-ons:
  

  

  Thanks for Your Feedback

  The feedback you’ve given us on the Add-on Performance Advisor since IE9 Beta allowed us to improve the overall user experience and add-on performance measurement accuracy.
  In a future post, we’ll blog more about add-on performance and how the ecosystem has evolved since we started the conversation around measuring and improving performance. We’ll continue to engage with add-on developers on improving add-on performance through blog posts and other efforts. The ideal experience is one where you can use as many add-ons as you want without compromising browsing performance (and reliability, security, and privacy).
  —Herman Ng, Program Manager, Internet Explorer
  

• SmartScreen® Application Reputation – Building Reputation

  over 1 year ago

  • 25

  With the Internet Explorer 9 (IE9) beta in September we introduced IE9's new application reputation feature and more recently we provided a summary of how this fits into the overall layered approach to security. With the final release of IE9 now available, we want to share some additional information about application reputation, clarify how code signing impacts the IE experience, and reiterate industry best practices that application developers should consider.
  SmartScreen Application Reputation is a consumer focused safety feature that helps consumers make better decisions about the programs they download. Downloads are automatically assigned a reputation rating based on multiple algorithms that consider many objective criteria, such as antivirus results, download traffic, download history, and URL reputation. If a user opts into enabling the SmartScreen Filter, application downloads without established reputation result in a notification (see below) warning them that the file may be a risk to their computer.
  From this notification, users can choose to delete the file or ignore the warning and run the downloaded program. For the typical user, the risk of running the download is a 25% to 40% chance of malware infection. We've been building reputation for some time now and approximately 90% of all application downloads have established reputation by hash or digital certificate. For the typical user, this notification is an infrequent experience associated with higher risk of malware infection. To put the scale of this risk in perspective, approximately 7% of all executable files downloaded by Internet Explorer are later confirmed as malicious. A portion of these attacks are prevented by blocklist solutions such as SmartScreen URL reputation or antivirus products. Unfortunately, no blocklist-based solution is 100% effective at preventing these attacks. Since Application Reputation was enabled in the IE9 beta release, the feature has greatly reduced infection rates from attacks that were not otherwise detected at the time of download.
  

  Unsigned Download – IE9 Application Reputation Notification
  

  Signed Download – IE9 Application Reputation Notification
  

  How programs are identified in IE9

  A download’s Application Reputation is assigned by:
  

  • a hash of the downloaded file
  • the digital certificate used to sign the file (if signed)

  The file hash is an exact identifier for the specific file downloaded. If any part of the application changes, the program identity (file hash) will also change. An unsigned application that is updated regularly (e.g. unsigned daily builds) will appear as multiple distinct programs that will have to build reputation individually.
  Reputation is also generated for digitally signed downloads based on the digital certificate used to sign the file. Digital certificates allow reputation to be assigned to a single identity (digital certificate) across multiple files. If you are not signing your programs, reputation will be built independently for each file you distribute. In contrast, signed programs may inherit the reputation of your digital certificate.
  

  Why Sign Your Code?

  For developers distributing applications online, signing your code is not required to establish reputation, but it is highly recommended. Code signing is an industry best practice that allows consumers to authenticate that files signed by a publisher are actually from that publisher. Signing also helps ensure that files cannot be secretly tampered with while stored on a server or during the download process. Without a digital signature, there is no way for a user to validate who actually created the file. This threat is commonly exploited by malware authors in their social engineering attacks.
  Of course, the presence of a digital signature alone does not ensure a download is non-malicious. Digitally signing your application is not a guarantee that your download will have established reputation immediately, but can play an important part in ensuring that your applications receive the reputation they deserve.
  Note that even if SmartScreen® Filter is disabled, users will be warned before unsigned applications are run:
  

  Internet Explorer 9 – Unsigned File Notification
  

  Best Practices for Application Developers

  There are several industry best practices an application developer can follow to help establish and maintain reputation for your applications:
  

  • Digitally sign your programs with an Authenticode signature.
    
    • Obtain a valid Authenticode code signing certificate from one of the many certificate authorities (CAs) supported by Windows.
    • Use development tools (such as signtool.exe) to sign your applications prior to distribution.
    • For more detailed information and a step-by-step description of the code signing process, see Eric Lawrence's excellent post Everything you need to know about Authenticode Code Signing.
  • Ensure downloads are not detected as malware. Downloaded programs that are detected and confirmed as malware will affect both the download’s reputation and the reputation of the digital certificate used to sign that file.
  • Apply for a Windows Logo. To learn more about the Windows Logo visit the Windows 7 Logo Program page on MSDN.

  More information about digital signatures and code signing:
  

  • Authenticode Overview
  • Ensuring Integrity and Authenticity
  • Code Signing Best Practices
  • What are Digital Certificates?

  Thanks for your help in ensuring a safer, more streamlined download experience for consumers.
  —Ryan Colvin, Program Manager, SmartScreen

Browser Power Consumption—Leading the Industry with Internet Explorer 9

Power consumption is an important consideration in building a modern browser and one objective of Internet Explorer 9 is to responsibly lead the industry in power requirements. The more efficiently a browser uses power the longer the battery will last in a mobile device, the lower the electricity costs, and the smaller the environment impact. While power might seem like a minor concern, with nearly two billion people now using the Internet the worldwide implications of browser power consumption are significant.
This post looks at how we measure power consumption, shares the results from recent engineering tests comparing browser power requirements, and explains how fully hardware accelerating Internet Explorer 9 has improved overall power efficiency.

Browsers Influence Power Consumption

How a browser uses the underlying PC hardware has a significant impact on power consumption. The components used in modern PC’s are power conscious and have the ability to conserve power through techniques such as putting idle hardware to sleep and coalescing computation. Browsers need to take these behaviors into consideration to efficiently use power.
With Internet Explorer 9 we followed several principles to guarantee industry leading power consumption. We focused on making IE fast - the quicker a browser can perform an action the less power the browser will consume. We focused on using modern PC hardware to accelerate IE - natively using the specialized hardware decreases power consumption. We focused on idle resource usage - the browser shouldn’t be doing work and consuming power when the user isn’t interacting with the browser. And we focused on following device power management guidance - the browser should respect the guidance of the hardware manufactures.

How to Measure Power Consumption

To measure power consumption, you have to monitor the power consumed by individual PC components across different real world customer scenarios. Every PC component contributes to power consumption and the patterns around their power usage vary over time based on what’s occurring.
We worked closely with our hardware ecosystem during the development of Windows 7 to build one of the worlds most advanced PC power testing environments. We’ll be using some of the hardware from this test environment, including an instrumented Intel reference PC based on the Calpella architecture, for the measurements in this post.
For fun, here are a few pictures of the machines we use to measure power.

Instrumented Intel reference PC	Reference PC back panel	DC Power Supply Units for Instrumented Laptops
	Instrumented laptops

By using an instrumented PC we’re able to measure the power usage of each PC component, including CPU, GPU, GMCH, Memory, Uncore, Hard Disk, Network, USB and many others. This is a more reliable approach than measuring overall system power consumption or battery durations which both have higher variance. Wires from the sense resistors on the instrumented PC are connected to a PCI-6259 DAQ card from National Instruments. With this approach we’re able to sample individual measurement points thousands of times per second and record these result for analysis.
Before running any power test the instrumented machine is restored to a baseline configuration of Windows 7 Ultimate, fully updated with the latest updates and device drivers, and a defragmented hard drive. This ensures the system itself won’t interfere with the power measurements and makes the browser the only variable.

Testing Power Consumption Across Common Scenarios

To ensure Internet Explorer 9 is achieving our goals, we measure power consumption across six scenarios. These scenarios cover both todays HTML4 based Web and the HTML5 based Web applications of tomorrow. We allow each scenario to run for 7 minutes and look at the average power consumption over that duration. This allows us to see multiple power cycles and ensure statistically accurate results.
The scenarios we’re going to look at today are:

1. Windows 7 without any browsers running (provides baseline).
2. Browsers navigated to about:blank (power consumption of the browser UI).
3. Loading one of the world’s most popular news Web sites (common HTML4 scenario).
4. Running the HTML5 Galactic experience (representative of graphical HTML5 scenario).
5. Fish swimming around the FishIE Tank (what test is complete without FishIE).

Scenario #1: Power Consumption with Idle System

We’ll start by measuring Windows 7 Ultimate without any additional software installed or running. The power consumption for the system over the duration of the test can be seen below.

The vertical axis shows the Watts consumed for each individual PC component. As you can see each PC component consumes between 0.2 and 1.5 Watts. Over the course of this test the average power consumption for each component was System (10.529), CPU (0.042), Memory (0.257), Uncore (1.123), GPU+GMCH (1.359), Disk (1.120), and LAN (0.024).

Scenario #2: Power Consumption with about:blank

To gauge how much power the browser UI itself consumes, we next measure each browser navigated to about:blank. In this scenario the browsers are not executing any markup and are close to idle, however differences in power consumption begin to emerge. Each browser exhibits the following power consumption patterns:

about:blank	System Idle	IE9	Chrome 10	Firefox 4	Opera 11	Safari 5
System	10.529 W	10.668 W	10.658 W	10.664 W	11.290 W	11.040 W
Battery Life	5:19 hrs	5:14 hrs	5:15 hrs	5:15 hrs	4:57 hrs	5:04 hrs

With this scenario most browsers are close to the system idle power usage, meaning they have little impact on power consumption. The exception is Opera 11 which is consuming about 5% more power than other browsers when idle.
One reason for this is that Opera changes the system timer resolution from the default 15.6ms to 2.5ms which prevents the CPU from entering low power states.
From Timers, Timer Resolution, and Development of Efficient Code June 16, 2010 Page 3:

The default timer resolution on Windows 7 is 15.6 milliseconds (ms). Some applications reduce this to 1 ms, which reduces the battery run time on mobile systems by as much as 25 percent.

Your choice in browser makes a difference even when the browser is idle and minimized.

Scenario #3: Power Consumption on News Site

To understand the power consumption when browsing between Web sites, we next measure each browser loading and viewing one of the world’s most popular news sites. To ensure consistent results the news site was cached on the network and each browser loaded an identical copy of the site. To provide more context on the power consumption patterns, we’ll walk through each browser individually.

You can see the average power consumption for Internet Explorer 9 follows a different pattern but does not consume significantly more power than the system idle scenarios. Internet Explorer 9’s power consumption for each component was System (11.728), CPU (0.041), Memory (0.273), Uncore (1.152), GPU+GMCH (1.391), Disk (1.198), and LAN (0.697).

When we look at Chrome 10 a very different pattern emerges. Where Internet Explorer 9’s power consumption was relatively stable, you’ll notice that Chrome 10 power consumption is cyclical with regular power spikes that push GPU and Uncore power consumption to nearly 3 Watt’s for those components. Chrome 10’s power consumption for each component was System (13.561), CPU (0.198), Memory (0.300), Uncore (1.810), GPU+GMCH (2.027), Disk (1.311), and LAN (0.697).

When we look at Firefox 4 we see a stable pattern consistent with Internet Explorer 9. One thing to note about power consumption is that low and steady consumption is more efficient than cyclical and high power spikes. Both Firefox 4 and Internet Explorer 9 do well against this objective. Firefox 4’s power consumption for each component was System (11.830), CPU (0.048), Memory (0.273), Uncore (1.170), GPU+GMCH (1.399), Disk (1.275), and LAN (0.697).

When we look at Opera 11 a cyclical consumption pattern is visible again. It’s that cyclical pattern that impacts the system power consumption over time. Opera 11’s power consumption for each component was System (12.833), CPU (0.108), Memory (0.283), Uncore (1.382), GPU+GMCH (1.637), Disk (1.283), and LAN (0.690).

Safari shows a stable pattern similar to Internet Explorer 9 and Firefox 4. Safari 4’s power consumption for each component was System (12.060), CPU (0.043), Memory (0.272), Uncore (1.122), GPU+GMCH (1.379), Disk (1.211), and LAN (0.690).

News Site	IE9	Chrome 10	Firefox 4	Opera 11	Safari 5
System	11.728 W	13.561 W	11.830 W	12.833 W	12.060 W
Battery Life	4:46 hrs	4:07 hrs	4:44 hrs	4:21 hrs	4:38 hrs

Scenario #4: Power Consumption on HTML5 Application, Galactic

The Web is rapidly moving to HTML5 and new capabilities including Audio, Video, Canvas, SVG, and CSS3 are enabling a new class of Web based experiences. HTML5 is the future and to understand the power consumption of HTML5 based scenarios, we next measure the Galactic from the IETestDrive Web site. The Galactic demo uses HTML5 capabilities, common Web patterns, an open source JavaScript framework, and NASA images to simulate the solar system. To ensure a fair test we use a locally cached copy of Galactic and rotate the solar system three times per second (that’s how fast Chrome 10, the slowest of the browsers, can rotate the solar system on this machine).

Internet Explorer 9 exhibits again a fairly stable pattern with the GPU clearly being utilized. Internet Explorer 9’s power consumption for each component was System (14.345), CPU (0.462), Memory (0.527), Uncore (1.847), GPU+GMCH (2.170), Disk (1.169), and LAN (0.697).

Compare with Internet Explorer’s power consumption, Chrome 10 exhibits a very different pattern. The two camel hump CPU power consumption is paramount consuming over 5 Watt at its peaks. In addition the GPU and Uncore usage is also up to a Watt larger than in Internet Explorer. Both of these factor into the dramatic difference in overall average consumption of IE’s 14.345 and Chrome’s 19.283. Chrome 10’s power consumption for each component was System (19.283), CPU (2.980), Memory (0.493), Uncore (2.673), GPU+GMCH (2.905), Disk (1.274), and LAN (0.697).

Firefox 4’s power consumption for each component was System (16.708), CPU (1.188), Memory (0.784), Uncore (2.146), GPU+GMCH (2.550), Disk (1.335), and LAN (0.697).

Safari 5’s power consumption is significantly higher than all of the other browsers. Specifically the CPU usage is even higher than Chrome 10. Safari 5’s power consumption for each component was System (24.321), CPU (6.597), Memory (0.477), Uncore (3.120), GPU+GMCH (3.280), Disk (1.155), and LAN (0.690).
We did not run Galactic on Opera since at this time it does not run on Opera, specifically, Galactic uses ECMAScript 5 properties API which Opera 11 does not support.

Galactic	IE9	Chrome 10	Firefox 4	Opera 11	Safari 5
System	14.345 W	19.283 W	16.708 W	n/a	24.321 W
Battery Life	3:54 hrs	2:54 hrs	3:21 hrs	n/a	2:18 hrs

Scenario #5: Power Consumption on HTML5 Application, FishIE Tank

Finally, no Internet Explorer 9 discussion is complete without testing FishIE Tank, one of our favorite demos. To ensure a fair and equitable test on this hardware, we’re only running with 10 fish swimming around the screen. This allows every browser to be able to achieve 60 frames per second (FPS). In this scenario each browser must update the screen 60 times per second which is considered real time animation and something we believe is important to ensure HTML5 success.
In this scenario each browser’s power consumption looks dramatically different by comparison:

Fish	IE9	Chrome 10	Firefox 4	Opera 11	Safari 5
System	22.738 W	32.812 W	23.195 W	31.941 W	29.021 W
Battery Life	2:27 hrs	1:42 hrs	2:24 hrs	1:45 hrs	1:55 hrs

Results of Power Consumption

For many customers, battery life is the most important gauge of power consumption. A typical laptop uses a 56 Watt hour battery, which means the laptop can consume 56 Watts worth of energy for one hour before running out. The fewer Watts the browser consumes the longer the laptop battery will last. Where’s how the battery life works out across these scenarios for a standard 56 Watt laptop.

We are using an equal weighting for each scenario, meaning each would be run the same about of time. So the power consumption and battery life of a 56Wh battery is:

Scenario	IE9	Chrome 10	Firefox 4	Opera 11	Safari 5
about:blank	10.044 W	7.821 W	9.570 W	7.704 W	8.087 W
News Site	11.042 W	9.951 W	10.617 W	8.757 W	8.835 W
Galactic	13.506 W	14.150 W	14.995 W	17.742 W	17.817 W
Fish	21.408 W	24.078 W	20.817 W	21.769 W	21.260 W
Battery Life	3:45 hrs	2:56 hrs	3:35 hrs	2:43 hrs	2:55 hrs

Power Consumption Matters

Browsers play a significant and important role in overall power consumption. The more efficiently a browser uses power the longer the battery will last in a mobile device, the lower the electricity costs, and the smaller the environment impact.
How a browser takes advantage of the underlying hardware makes a significant impact on power consumption not to mention performance and user experience. As computing becomes more mobile, and as the HTML5 based Web becomes pervasive it’s important that browsers make power consumption a focus. We hope and encourage the industry and other browser vendors to follow us on the path to a more power efficient Web.
Special thanks to the platform engineering teams at Intel Corporation who have worked closely with us to make power a priority throughout the Windows 7 and Internet Explorer 9 releases, and for their assistance reviewing the results of our tests.

—Walter VonKoch, IE Performance Program Manager,
Matthew Robben, Windows Power Program Manager, and
Jason Weber, IE Performance Lead