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