Tag Archives: EdgeHTML 15

Microsoft Edge at Build 2017

Last week, Microsoft welcomed thousands of developers from around the world to Build 2017, where we shared our vision for the future of dozens of products and services. Build featured a number of exciting sessions for developers building sites and apps with web technologies, including a peek at what’s coming to the web platform beginning with EdgeHTML 16 the Windows 10 Fall Creators Update.

In this post, you’ll find a quick review of the web developer sessions at Build 2017. If you see something you’d like to learn more about, dive into the recording to get all the details!

What’s new and what’s next for the web on Windows

In this session, Kyle Pflug and Nadia Fortini take you on a whirlwind tour of what’s new in Microsoft Edge in EdgeHTML 15, and share a roadmap for our priorities in upcoming releases of Microsoft Edge.

You’ll learn about new features like Payment Request for standardized checkout experiences, WebVR for immersive mixed reality experiences built with immersive web technologies, and dramatically improved responsiveness and battery life. We also cover upcoming APIs in development for future releases, including an updated CSS Grid implementation, Service Worker and other features that enable Progressive Web Apps, and much more.

Screen capture showing Fluent Design in Microsoft Edge. The use of materials like Acrylic allows elements of the background to influence the color and texture of the browser frame.

This session also shows an early look at upcoming changes to the design and personality of Microsoft Edge, as the new Fluent Design System begins to make to the browser beginning with the Windows 10 Fall Creators Update. Fluent Design brings depth, motion, and personality to the controls and browser frame in Microsoft Edge, allowing elements of the page and background to influence the color of the browser window.

Progressive Web Apps on Windows

In this session, Aaron Gustafson introduces Progressive Web Apps, a new vision for the future of web apps enabled by groundbreaking technologies like Service Worker, which will be coming to preview builds of Microsoft Edge for developer testing this summer.

You’ll learn how Progressive Web Apps enable world-class, cross-platform, native-like apps, build on web technologies and hosted on your own server. PWAs can work offline, update content in the background even when the browser or the app is closed, and intercept network requests to update content from a cache when the network is unavailable.

This session details how we will a first-class web app ecosystem on Windows by ingesting high-quality PWAs from across the internet, and making it easy for developers to participate in the Windows Store alongside native apps with no extra effort, using tools like Web App Manifests and PWABuilder.

WebVR: Immersive Mixed Reality powered by web technologies

In this session, David Rousset and Etienne Margraff describe how EdgeHTML 15 on the Windows 10 Creators Update enables any web developer to build an immersive mixed reality experience with Microsoft Edge, Windows Mixed Reality, and the WebVR 1.1 API.

Modern frameworks like Babylon.js and A-Frame make it easy to get started building WebVR experiences using familiar web technologies. Developers can get started today even without a headset using the Windows Mixed Reality Simulator.

Better checkout experiences with the Payment Request API

In this session, Molly Dalton, Stan Change, and Jonathan Cutler provide an in-depth look at the new Payment Request API, which allows you to build standardized, cross-browser checkout experiences on the web and in apps. Payment Request dramatically simplifies checkout by leveraging a payment app – in this case, the browser – to store and provide payment and shipping details, so your customers can enjoy less friction and a more delightful user experience.

Payment Request works in EdgeHTML 15 as well as in UWP apps, apps packaged with the Desktop Bridge, and the Microsoft Bot Framework, allowing you to build a faster and easier checkout experience across a variety of devices and platforms.

What’s new in ChakraCore

In this session, Brian Terlson gives an overview of what’s new in Chakra – the open-source JavaScript engine that powers Microsoft Edge and Windows 10.

You’ll learn about the near-native performance enabled by experimental WebAssembly support in Microsoft Edge, and exciting new emerging tools like Time Travel Debugging. You’ll also learn about Chakra’s journey to other operating systems, and the work we’ve been doing with the Node.js core project to help solve key problems like providing a stable Node API for native module developers.

Get started today

Many of these new APIs – including WebVR 1.1, Payment Request, CSS Custom Properties, and more – are available and on by default in Microsoft Edge on the Windows 10 Creators Update, which is available now. To get started with experimental features like WebAssembly, you can simply navigate to about:flags in Microsoft Edge.

To make it as easy as possible to get started, we’ve partnered with BrowserStack to provide instant, free testing of Microsoft Edge from any device. You can test the latest stable and preview releases of Microsoft Edge, and even test localhost or using WebDriver.

We look forward to sharing more about upcoming features soon as they make their way to the Windows Insider Program. In the meantime, check out the Build sessions, and let us know what you think!

Kyle Pflug, Senior Program Manager, Microsoft Edge

Improvements for Enterprises in Microsoft Edge on the Windows 10 Creators Update

Last month, we began rolling out the Windows 10 Creators Update (Windows 10 version 1703) to over 400 million customers around the world. The Creators Update upgrades Microsoft Edge to EdgeHTML 15, including a number of performance, security, and compatibility improvements.

In this post, we’ll share a bit more detail on how the Windows 10 Creators Update makes Microsoft Edge better than ever for Enterprise customers and IT Professionals.

Management Improvements

In Windows 10 version 1703, we’ve added new policies that support key management scenarios, enabled by Mobile Device Management (MDM), Microsoft Intune, and Group Policy. In particular, we’ve focused on missing policies that were requested in your feedback.

You can find the full list of new policies for Microsoft Edge in the Available Policies topic on TechNet. Some of the highlights include:

Compatibility

We’ve often discussed compatibility for legacy sites, and how Microsoft Edge and Internet Explorer 11 can work better together to provide a modern experience, while still providing a compatible fallback for legacy experiences. Microsoft Edge and Internet Explorer provide the ability to seamlessly switch from one to the other, based on the site you’re loading, making sure your users have the best experience possible. To reinforce this approach, we’ve added these policies for better app compatibility:

Keep favorites in sync between Internet Explorer and Microsoft Edge

One of our most common requests is for a policy to Keep favorites in sync between Internet Explorer and Microsoft Edge. New in the Windows 10 version 1703, this policy setting synchronizes user favorites between the two browsers in real-time. That means that any changes you make in the Internet Explorer Favorites folder structure is also made in the Microsoft Edge Favorites database, and vice versa. Combined with the Enterprise Mode Site List, your users should never need to remember which browser to use to open a site – it should all be done automatically.

Allow Adobe Flash

Some customers have shared concerns about how to manage Adobe Flash content. Windows 10 version 1703 adds the Allow Adobe Flash policy setting to completely turn off, or disable, Adobe Flash content from running in your organization.

Adobe Flash Click-to-Run

We’re encouraging the transition to HTML5 alternatives by providing additional user control over when Flash content loads. We’ve made Microsoft Edge default to only allow Adobe Flash content to run when someone explicitly clicks on it. With this policy, you can choose to override this experience and allow Adobe Flash content to simply run,.

Customizing the experience

We’ve also added a number of policy settings that help you customize user experiences and functionality as per your enterprise policy:

Prevent the First Run webpage from opening on Microsoft Edge

This setting disables the “First Run” experience in Microsoft Edge. Your users will instead navigate straight to their default start page.

Disable lockdown of Start pages

We’ve previously provided the ability to lock down your Start pages by using the policy setting, Configure Start pages. Since then, we’ve heard feedback from a number of customers who simply wanted a configuration option, with no lock down. In Windows 10 version 1703, we’ve added an additional policy setting that you can set on top of the existing one to configure Start pages without locking them down. You can then decide whether to modify, add, or delete these Start pages.

Search

We have introduced three new policies to help you configure search providers:

  • Configure additional search engines: Lets you add additional search engine providers for your employees to choose from.
  • Set default search engine: Lets you decide the default search engine for your employees.
  • Allow search engine customization: Lets you decide whether to lock down your search engine configuration so your employees can’t change it.

Allow Address bar drop-down list suggestions

This policy setting lets you decide whether the Address bar drop-down functionality is available in Microsoft Edge. If you disable this setting, your employees won’t get suggested search results when typing in the Microsoft Edge suggestions list.

Allow clearing browsing data on exit

If you don’t want an employee’s browsing data to persist on the machine at the end of a browsing session, you can use this policy setting to automatically clear all browsing data when Microsoft Edge closes.

Productivity

With the Windows 10 Creators Update, we’ve introduced a number of  new features and ongoing improvements to browser fundamentals, to improve the overall experience of the browser for all of your users.

Tab management

Microsoft Edge now lets your users set tabs aside for later, sweeping them aside and organizing them neatly in a special section for easy access at a later time. We’ve also made it easier to glance at the content of all open tabs by simply clicking the “show tab previews” icon, which will expand the tab bar to show a preview of each open tab.

Fundamentals

Made for the modern web, with available support for the legacy web

Microsoft Edge stays up-to-date. with support for the latest web standards that are driving today’s websites and web apps, giving you a browser that “just works” with modern sites. The Edge Developer Center also provides guidance and tools to help developers update their sites to use modern standards.

We understand that migrating your sites to modern web standards can be a long-term process. Using Enterprise Mode with Internet Explorer for backward compatibility can help you upgrade more easily. We’re also making it easier for you to manage your Enterprise Mode site lists. If your site list is of a relatively small size, using the Enterprise Mode Site List Manager is the easiest way to manage your Enterprise Mode Site List. If your if your site list is relatively large and requires multiple users to work on it, we recommend using the Enterprise Mode Site List Portal.

More efficient, more responsive and more secure

In a recent blog post, we talked in detail about the work done to make Microsoft Edge more efficient, responsive, and secure in the Windows 10 Creators Update. Some of the highlights are:

Conclusion

The Windows 10 Creators Update (version 1703) makes life easier for you as an Enterprise administrator or IT professional, introducing a number of new policies and improvements to reduce the overhead of supporting both Microsoft Edge and Internet Explorer 11. It also improves the end-user experience considerably, with new features and improved fundamentals for a more productive and enjoyable experience on the web.

If you’re on a Windows 10 device, you can simply check for updates to try the Windows 10 Creators Update today – see the instructions here for more details.

Puneet Arora, Principal Program Manager, Microsoft Edge

Improved JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge

JavaScript performance is an evergreen topic on the web. With each new release of Microsoft Edge, we look at user feedback and telemetry data to identify opportunities to improve the Chakra JavaScript engine and enable better performance on real sites.

In this post, we’ll walk you through some new features coming to Chakra with the Windows 10 Creators Update that improve the day-to-day browsing experience in Microsoft Edge, as well as some new experimental features for developers: WebAssembly, and Shared Memory and Atomics.

Under the hood: JavaScript performance improvements

Saving memory by re-deferring functions

Back in the days of Internet Explorer, Chakra introduced the ability to defer-parse functions, and more recently extended the capability to defer-parse event-handlers. For eligible functions, Chakra performs a lightweight pre-parsing phase where the engine checks for syntax errors at startup time, and delays the full parsing and bytecode generation until functions are called for the first time. While the obvious benefit is to improve page load time and avoid wasting time on redundant functions, defer-parsing also prevents memory from being allocated to store metadata such as ASTs or bytecode for those redundant functions. In the Creators Update, Microsoft Edge and Chakra further utilizes the defer-parsing mechanism and improves memory usage by allowing functions to be re-deferred.

The idea of re-deferring is deceptively simple – for every function that Chakra deems would no longer get executed, the engine frees the bulk of the memory the function holds to store metadata generated after pre-parsing, and effectively leaves the function in a deferred state as if it has just been pre-parsed. Imagine a function foo which gets deferred upon startup, called at some point, and re-deferred later.

Illustration showing a function foo which gets deferred upon startup, called at some point, and re-deferred later.

The tricky part about re-deferring is that Chakra cannot perform such actions too aggressively or it risks frequently re-paying the cost of full-parsing, bytecode generation, etc. Chakra checks its record of function call counts every N GC cycles, and re-defers functions that are not called over that period of time. The value of N is based on heuristics, and as a special case a smaller value is used at startup time when memory usage is more susceptible to peak. It is hard to generalize the exact saving from re-deferring as it is very subject to the content served, but in our experiment with a small sample of sites, re-deferring typically reduces the memory allocated by Chakra by 6-12%.

Bar chart showing memory allocated by Chakra for various popular sites, with and without re-deferral. With re-deferral, the memory allocated is reduced by 6-12%.

Post Creators Update, we are working on addressing an existing limitation of re-deferring to handle arrow functions, getters, setters, and functions that capture lexically-scoped variables. We expect to see further memory savings from the re-deferring feature.

Optimizing away heap arguments

The usage of arguments object is fairly common on the web. Whenever a function uses the arguments object, Chakra if necessary, creates a “heap arguments” object so that both formals and the arguments object refer to the same memory location. Allocating such object can be expensive, so the Chakra JIT optimizes away the creation of heap arguments when functions have no formal parameters.

In the Creators Update, the JIT optimization is extended to avoid the creation of heap arguments with the presence of formals as long as there’re no writes to the formals. It is no longer necessary to allocate heap arguments objects for code such as below.

// no writes to formals (a & b) therefore heap args can be optimized away
function plus(a, b) {
  if (arguments.length == 2) {
      return a + b; 
  }
}

To measure the impact of the optimization, our web crawler estimates that the optimization benefits about 95% websites and it allows the React sub-test in the Speedometer benchmark, which runs a simple todoMVC implemented with React, to speed up by about 30% in Microsoft Edge.

Better performance for minified code

Using a minifier before deploying scripts has been a common practice for web developers to reduce the download burden on the client side. However, minifiers could sometimes pose performance issues as they introduce code patterns that developers typically would not write by hand and therefore might not be optimized.

Previously, we’ve made optimizations in Chakra for code patterns observed in UglifyJS, one of the most heavily-used minifiers, and improved performance for some code patterns by 20-50%. For the Creators Update, we investigated the emit pattern of the Closure compiler, another widely used minifier in the JavaScript ecosystem, and added a series of inlining heuristics, fast paths and other optimizations according to our findings.

The changes lead to a visible speedup for code minified by Closure or other minifiers that follow the same patterns. As an experiment to measure the impact consistently in a well-defined and constrained environment, we minified some popular JavaScript benchmarks using Closure and noticed a 5~15% improvement on sub-tests with patterns we’ve optimized for.

WebAssembly

WebAssembly is an emerging portable, size- and load-time-efficient binary format for the web. It aims to achieve near-native performance and provides a viable solution for performance-critical workloads such as games, multimedia encoding/decoding, etc. As part of the WebAssembly Community Group (CG), we have been collaborating closely with Mozilla, Google, Apple and others in the CG to push the design forward.

Following the recent conclusion of WebAssembly browser preview and the consensus over the minimum viable product (MVP) format among browser vendors, we’re excited to share that Microsoft Edge now supports WebAssembly MVP behind the experimental flag in the Creators Update. Users can navigate to about:flags and check the “Enable experimental JavaScript features” box to turn on WebAssembly and other experimental features such as SharedArrayBuffer.

Under the hood, Chakra defers parsing WebAssembly functions until called, unlike other engines that parse and JIT functions at startup time. We’ve observed startup time as a major headache for large web apps and have rarely seen runtime performance being the issue from our experiences with existing WebAssembly & asm.js workloads. As a result, a WebAssembly app often loads noticeably faster in Microsoft Edge. Try out the Tanks! demo in Microsoft Edge to see it for yourself – be sure to enable the “Experimental JavaScript Features” flag in about:flags!

Beyond the Creators Update, we are tuning WebAssembly performance as well as working on the last remaining MVP features such as response APIs and structured cloning before we enable WebAssembly on by default in Microsoft Edge. Critical post-MVP features such as threads are being considered as well.

Shared Memory & Atomics

JavaScript as we know it operates in a run-to-completion single-threaded model. But with the growing complexity of web apps, there is an increasing need to fully exploit the underlying hardware and utilize multi-core parallelism to achieve better performance.

The creation of Web Workers unlocked the possibility of parallelism on the web and executing JavaScript without blocking the UI thread. Communication between the UI thread and workers was initially done via cloning data and postMessage. Transferable object was later added as a welcome change to allow transferring data to another thread without the runtime and memory overhead of cloning, and the original owner forfeits its right to access the data to avoid synchronization problems.

Soon to be ratified in ES2017, Shared Memory & Atomics is the new addition to the picture to further improve parallel programming on the web. With the release of Creators Update, we are excited to preview the feature behind the experimental JavaScript features flag in Microsoft Edge.

In Shared Memory and Atomics, SharedArrayBuffer is essentially an ArrayBuffer shareable between threads and removes the chore of transferring data back and forth. It enables workers to virtually work on the same block of memory, guaranteeing that a change on one thread on a SharedArrayBuffer will eventually be observed (at some unknown point of time) on other threads holding the same buffer. As long as workers operate on different parts of the same SharedArrayBuffer, all operations are thread-safe.

The addition of Atomics gives developers the necessary tools to safely and predictably operate on the same memory location by adding atomics operations and the ability to wait and wake in JavaScript. The new feature allows developers to build more powerful web applications. As a simple illustration of the feature, here’s the producer-consumer problem implemented with shared memory:

// UI thread
var sab = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT * 1000);
var i32 = new Int32Array(sab);
producer.postMessage(i32);
consumer.postMessage(i32);

// producer.js – a worker that keeps producing non-zero data
onmessage = ev => {
  let i32 = ev.data;
  let i = 0;
  while (true) {
    let curr = Atomics.load(i32, i);             // load i32[i]
    if (curr != 0) Atomics.wait(i32, i, curr);   // wait till i32[i] != curr
    Atomics.store(i32, i, produceNonZero());     // store in i32[i]
    Atomics.wake(i32, i, 1);                     // wake 1 thread waiting on i32[i]
    i = (i + 1) % i32.length;
  }
}

// consumer.js – a worker that keeps consuming and replacing data with 0
onmessage = ev => {
  let i32 = ev.data;
  let i = 0;
  while (true) {
    Atomics.wait(i32, i, 0);                     // wait till i32[i] != 0
    consumeNonZero(Atomics.exchange(i32, i, 0)); // exchange value of i32[i] with 0
    Atomics.wake(i32, i, 1);                     // wake 1 thread waiting on i32[i]
    i = (i + 1) % i32.length;
  }
}

Shared memory will also play a key role in the upcoming WebAssembly threads.

Built with the community

We hope you enjoy the JavaScript performance update in Microsoft Edge and are as excited as we are to see the progress on WebAssembly and shared memory pushing the performance boundary of the web. We love to hear user feedback and are always on a lookout for opportunities to improve JavaScript performance on the real-world web. Help us improve and share your thoughts with us via @MSEdgeDev and @ChakraCore, or the ChakraCore repo on GitHub.

― Limin Zhu, Program Manager, Chakra Team

Modernizing the DOM tree in Microsoft Edge

The DOM is the foundation of the web platform programming model, and its design and performance impacts the rest of the browser pipeline. However, its history and evolution is far from a simple story.

Over the past three years, we’ve embarked on an in-flight refactoring of the DOM in Microsoft Edge, with our eye on a modernized architecture offering better real-world performance and reduced complexity. In this post, we’ll walk you through the history of the DOM in Internet Explorer and Microsoft Edge, and the impact of our recent work to modernize the DOM Tree, which is already resulting in substantially improved performance in the Windows 10 Creators Update.

A diagram of the web platform pipeline, with the DOM Tree and cooperating components (CSS Cascade, DOM API & Capabilities, and Chakra JavaScript) highlighted.

What we think of as “the DOM” is really the cooperation of several subsystems. In Microsoft Edge, this includes JS binding, events, editing, spellchecking, HTML attributes, CSSOM, text, and others, all working together. Of these subsystems, the DOM “tree” is at the center.

Several years ago, we began a long journey to update to a modern DOM “tree” (node connectivity structures). By modernizing the core tree, which we completed in Microsoft Edge 14, we landed a new baseline and the scaffolding to deliver on our promise of a fast and reliable DOM. With Windows 10 Creators Update and Microsoft Edge 15, the journey we started is beginning to bear fruit.

Circular tree map showing "DOM Tree" at the center, surrounded by "JS Binding," "Editing," "Spellcheck," "Events," and "Attributes."

“The DOM” is really the cooperation of several subsystems that make up the web programming model.

We’re just scratching the surface, but want to take this opportunity to geek out a bit, and share some of the internal details of this journey, starting with the DOM’s arcane history and showcasing some of our accomplishments along the way.

The history of the Internet Explorer DOM tree

When web developers today think of the DOM, they usually think of a tree that looks something like this:

A diagram of a simple tree

A simple tree

However nice and simple (and obvious) this seems, the reality of Internet Explorer’s DOM implementation was much more complicated.

Simply put, Internet Explorer’s DOM was designed for the web of the 90s. When the original data structures were designed, the web was primarily a document viewer (with a few animated GIFs and other images thrown in). As such, algorithms and data structures more closely resembled those you might see powering a document viewer like Microsoft Word. Recall in the early days of the web that there was no JavaScript to allow scripting a web page, so the DOM tree as we know it didn’t exist. Text was king, and the DOM’s internals were designed around fast, efficient text storage and manipulation. Content editing (WYSIWYG) was already a feature at the time, and the manipulation paradigm centered around the editing cursor for character insertion and limited formatting.

A text-centric design

As a result of its text-centric design, the principle structure of the DOM was the text backing store, a complex system of text arrays that could be efficiently split and joined with minimal or no memory allocations. The backing store represented both text and tags as a linear progression, addressable by a global index or Character Position (CP). Inserting text at a given CP was highly efficient and copy/pasting a range of text was centrally handled by an efficient “splice” operation. The figure below visually illustrates how a simple markup containing “hello world” was loaded into the text backing store, and how CPs were assigned for each character and tag.

Diagram of the text backing store, with special positional placeholders for non-text entities such as tags and the insertion point.

The text backing store, with special positional placeholders for non-text entities such as tags and the insertion point.

To store non-textual data (e.g. formatting and grouping information), another set of objects was separately maintained from the backing store: a doubly-linked list of tree positions (TreePos objects). TreePos objects were the semantic equivalent of tags in HTML source markup – each logical element was represented by a begin and end TreePos. This linear structure made it very fast to traverse the entire DOM “tree” in depth-first pre-order traversal (as required for nearly every DOM search API and CSS/Layout algorithm). Later, we extended the TreePos object to include two other kinds of “positions”: TreeDataPos (for indicating a placeholder for text) and PointerPos (for indicating things like the caret, range boundary points, and eventually for “new” features like generated content nodes).

Each TreePos object also included a CP object, which acted as the tag’s global ordinal index (useful for things like the legacy document.all API). CPs were used to get from a TreePos into the text backing store, easily compare node order, or even find the length of text by subtracting CP indices.

To tie it all together, a TreeNode bound pairs of tree positions together and established the “tree” hierarchy expected by the JavaScript DOM as illustrated below.

Diagram showing the dual representation of the DOM as both text and (possibly overlapping) nodes

The dual representation of the DOM as both text and (possibly overlapping) nodes

Adding layers of complexity

The foundation of CPs caused much of the complexity of the old DOM. For the whole system to work properly, CPs had to be up-to-date. Thus, CPs were updated after every DOM manipulation (e.g. entering text, copy/paste, DOM API manipulations, even clicking on the page—which set an insertion point in the DOM). Initially, DOM manipulations were driven primarily by the HTML parser, or by user actions, and the CPs-always-up-to-date model was perfectly rational. But with rise of JavaScript and DHTML, these operations became much more common and frequent.

To compensate, new structures were added to make these updates efficient, and the splay tree was born, adding an overlapping series of tree connections onto TreePos objects. The added complexity helped with performance—at first; global CP updates could be achieved with O(log n) speed. Yet, a splay tree is really only optimized for repeated local searches (e.g., for changes centered around one place in the DOM tree), and did not prove to be a consistent benefit for JavaScript and its more random-access patterns.

Another design phenomenon was that the previously-mentioned “splice” operations that handled copy/paste, were extended to handle all tree mutations. The core “splice engine” worked in three steps, as illustrated in the figure below.

Timeline diagram of the splice engine algorithm

The splice engine algorithm

In step 1, the engine would “record” the splice by traversing the tree positions from the start of the operation to the end. A splice record was then created containing command instructions for this action (a structure re-used in the browser’s Undo stack). In step 2, all nodes (i.e., TreeNode and TreePos objects) associated with the operation were deleted from the tree. Note that in the IE DOM tree, TreeNode/TreePos objects were distinct from the script-referenced Element objects to facilitate overlapping tags, so deleting them was not a functional problem. Finally, in step 3, the splice record was used to “replay” (re-create) new objects in the target location. For example, to accomplish an appendChild DOM operation, the splice engine created a range around the node (from the TreeNode‘s begin TreePos to its end), “spliced” the range out of the old location, and created new nodes to represent the node and its children in the new location. As you can imagine, this created a lot of memory allocation churn, in addition to the inefficiencies of the algorithm.

No encapsulation

These are just a few of the examples of the complexity of the Internet Explorer DOM. To add insult to injury, the old DOM had no encapsulation, so code from the Parser all the way to the Display systems had CP/TreePos dependencies, which required many dev-years to detangle.

With complexity comes errors, and the DOM code base was a reliability liability. According to an internal investigation, from IE7 to IE11, approximately 28% of all IE reliability bugs originated from code in core DOM components. This complexity also manifested as a tax on agility, as each new HTML5 feature became more expensive to implement as it became harder to retrofit concepts into the existing architecture.

Modernizing the DOM tree in Microsoft Edge

The launch of Project Spartan created the perfect opportunity modernize our DOM. Free from platform vestiges like docmodes and conditional comments, we began a massive refactoring effort. Our first, and most critical target: the DOM’s core tree.

We knew the old text-centric model was no longer relevant; we needed a DOM tree that actually was a tree internally in order to match the expectations of the modern DOM API. We needed to dismantle the layers of complexity that made it nearly impossible to performance-tune the tree and the other surrounding systems. And finally, we had a strong desire to encapsulate the new tree to avoid creating cross-component dependencies on core data structures. All of this effort would lead to a DOM tree with the right model in place, primed and ready for additional improvements to come.

To make the transition to the modern DOM as smooth as possible (and to avoid building a new DOM tree in isolation and attempting to drop and stabilize untested code at the end of the project—a.k.a. the very definition of “big bang integration”), we transitioned the existing codebase in-place in three phases. The first phase of the project defined our tree component boundary with corresponding APIs and contracts. We chose to design the APIs as a set of “reader” and “writer” functions that operated on nodes. Instead of APIs that look like this:

parent.appendChild(child);
element.nextSibling;

our APIs looked like this:

TreeWriter::AppendChild(parent, child);
 TreeReader::GetNextSibling(element);

This API design discourages callers from thinking about tree objects as actors with their own state. As a result, a tree object is only an identity in the API, allowing for more robust contracts and hiding representational details, which proved useful in phase 3.

The second phase migrated all code that depended on legacy tree internals to use the newly established component boundary APIs instead. During this migration, the implementation of the tree API would continue to be powered by the legacy structures. This work took the most time and was the least glamorous; it took several dev-years to detangle consumers of the old tree structures and properly encapsulate the tree. Staging the project this way let us release EdgeHTML 12 and 13 with our fully-tested incremental changes, without disrupting the shipping schedule.

In the third and final phase, with all external code using the new tree component boundary APIs, we began to refactor and replace the core data structures. We consolidated objects (e.g., the separate TreePos, TreeNode, and Element objects), removed the splay tree and splice engine, dropped the concept of PointerPos objects, and removed the text backing storage (to name a few). Finally, we could rid the code of CPs.

The new tree structure is simple and straightforward; it uses four pointers instead of the usual five to maintain connectivity: parent, first-child, next, and previous sibling (last-child is computed as the parent’s first-child’s previous sibling) and we could hide this last-child optimization behind our TreeReader APIs without changing a single caller. Re-arranging the tree is fast and efficient, and we even saw some improvements in CPU performance on public DOM APIs, which were nice side-effects of the refactoring work.

Diagram of Microsoft Edge’s new DOM tree structure, showing all four possible pointers

Microsoft Edge’s new DOM tree structure, showing all four possible pointers.

With the new DOM tree, reliability also improved significantly, dropping from 28% of all reliability issues to just around 10%, and at the same time providing secondary benefits of reducing time spent debugging and improving team agility.

The next steps in the journey

While this feels like the end of our journey, in fact it’s just the beginning. With our DOM tree APIs in place and powered by a simple tree, we turned our attention to the other subsystems that comprise the DOM, with an eye towards two classes of inefficiencies: inefficient implementations inside the subsystems, and inefficient communication between them.

Circular tree map showing "DOM Tree" at the center, surrounded by "JS Binding," "Editing," "Spellcheck," "Events," and "Attributes."

The DOM tree is at the center of many cooperating components that make up the web programming model.

For example, one of our top slow DOM APIs (even after the DOM tree work) has historically been querySelectorAll. This is a general-purpose search API, and uses the selectors engine to search the DOM for specific elements. Not surprisingly, many searches involve particular element attributes as search criteria (e.g., an element’s id, or one of its class identifiers). As soon as the search code entered the attributes subsystem, it ran into a whole new class of inefficiencies, completely unrelated to those addressed by the new DOM tree.

For the attributes subsystem, we are simplifying the storage mechanism for element content attributes. In the early days of the web, DOM attributes were primarily directives to the browser about how to display a piece of markup. A great example of this is the colspan attribute:

<tr>
     <td colspan="2">Total:</td>
     <td>$12.34</td>
 </tr>

colspan has semantic meaning to the browser and thus has to be parsed. Given that pages weren’t very dynamic back then and attributes were generally treated like enums, IE created an attribute system that was optimized around eager parsing for use in formatting and layout.

Today’s app patterns, however, heavily use attributes like id, class, and data-*, which are treated less like browser directives and more like generic storage:

<li id="cart" data-customerid="a8d3f916577aeec" data-market="en-us">
     <b>Total:</b>
     <span class="total">$12.34</span>
 </li>

Thus, we’re deferring most work beyond the bare minimum necessary to store the string. Additionally, since UI frameworks often encourage repeated CSS classes across elements, we plan to atomize strings to reduce memory usage and improve performance in APIs like querySelector.

Though we still have plenty of work planned, with Windows 10 Creators Update, we’re happy to share that we’ve made significant progress!

Show me the money

Reliably measuring and improving performance is hard and the pitfalls of benchmarking are well documented. To get the most holistic view of browser performance possible, the Microsoft Edge team uses a combination of user telemetry, controlled measurement real-world scenarios, and synthetic benchmarks to guide our optimizations.

Venn Diagram with three labelled circles: "User telemetry," "Synthetic benchmarks," and "Performance Lab"

User telemetry “paints with a broad brush”, but by definition measures the most impactful work. Below is an example of our build-over-build tracking of the firstChild API across our user base. This data isn’t directly actionable, since it doesn’t provide all the details of the API call (i.e. what shape and size is the DOM tree) needed for performance tuning, but it’s the only direct measurement of the user’s experience and can provide feedback for planning and retrospectives.

Screen capture showing Build-to-build user performance telemetry for firstChild

Build-to-build user performance telemetry for firstChild (lower is better)

We highlighted our Performance lab and the nitty-gritty details of measuring browser performance a while ago, and while the tests themselves and the hardware in the lab has changed since then, the methodology is still relevant. By capturing and replaying real-world user scenarios in complex sites and apps like Bing Maps and Office 365, we’re less likely to overinvest in narrowly applicable optimizations that don’t benefit users. This graph is an example of our reports for a simulated user on Bing Maps. Each data point is a build of the browser, and hovering provides details about the statistical distribution of measurements and links to more information for investigating changes.

Screen capture showing build to build telemetry from the Performance Lab

A graph of build-over-build performance of a simulated user on Bing Maps in the Performance Lab

Our Performance lab’s fundamental responsibility is to provide the repeatability necessary to test and evaluate code changes and implementation options. That repeatability also serves as the platform for synthetic benchmarks.

In the benchmark category, our most exciting improvement is in Speedometer. Speedometer simulates using the TodoMVC app for several popular web frameworks including Ember, Backbone, jQuery, Angular, and React. With the new DOM tree in place and other improvements across other browser subsystems like the Chakra JavaScript engine, the time to run the Speedometer benchmark decreased by 30%; in the Creators update, our performance focus netted another improvement of 35% (note that Speedometer’s scores are a measure of speed and thus an inverse function of time).

Chart showing Microsoft Edge scores on the Speedometer benchmark over the past four release. Edge 12: 5.44. Edge 13: 37.83. Edge 14: 53.92. Edge 15: 82.67.

Release-over-release performance on the Speedometer benchmark (higher is better)

Of course the most important performance metric is the user’s perception, so while totally unscientific, we’ve been super excited to see others notice our work!

We’re not done yet, and we know that Microsoft Edge is not yet the fastest on the Speedometer benchmark. Our score will continue to improve as a side effect of our performance work and we’ll keep the dev community updated on our progress.

Conclusion

A fast DOM is critical for today’s web apps and experiences. Windows 10 Creators Update is the first of a series of releases focused on performance on top of a re-architected DOM tree. At the same time, we’ll continue to improve our performance telemetry and community resources like the CSS usage and API catalog.

We’re just beginning to scratch the surface of what’s possible with our new DOM tree, and there’s still a long journey ahead, but we’re excited to see where it leads and to share it with you! Thanks!

Travis Leithead & Matt Kotsenas, Program Managers, Microsoft Edge

Better battery life with Microsoft Edge

There’s a good chance you’ve noticed that Microsoft Edge and other popular browsers have recently been focused on improving battery life. We’ve been paying particular attention to this with Windows 10, and the response has been great. Windows users spend more than half their time on the web, so improvements here have a significant effect on your device’s battery life.

We’re committed to giving you the best, fastest, and most efficient browser possible. In this post, I’ll share some of the new energy efficiency improvements available with the Windows 10 Creators Update.

Comparing the latest versions of major browsers on Windows, the trends are similar to what we’ve seen with previous releases. According to our tests on the Windows 10 Creators Update – based on an open-source test which simulates typical browsing activities across multiple tabs – Microsoft Edge uses up to 31% less power than Google Chrome, and up to 44% less than Mozilla Firefox.

Bar chart measuring power consumed by Microsoft Edge and the latest versions of Chrome and Firefox. Microsoft Edge uses 31% less power than Chrome 57, and 44% less power than Firefox 52.

Direct measurements of average power consumption during typical browsing activities (source code).

Let’s dive in to some details of how we measure power consumption to optimize for battery life, and how we’re engineering Microsoft Edge to be the most efficient browser on Windows 10.

Our approach: open, transparent, and reproducible

Measuring and improving battery life are both complicated problems, and while we want to show off our leadership here, we also want to be a part of a constructive dialog that improves the entire web. That’s why we always share our measurements alongside filmed rundown tests, or through open source tests freely available on GitHub. These tests are repeatable by other browsers or curious users, backed by methodology documents and open source code.

One of the most important tools for our energy efficiency engineering is BrowserEfficiencyTest. It automates the most important tasks that people do with their browser, and runs through those tasks while measuring how much power a device is consuming, as well as how hard the CPU is working, how much traffic is being sent over the network, and more. It can be used to look at specific sites and patterns, or measure complex workloads composed of many different sites in multiple tabs. This test supports Microsoft Edge as well as Google Chrome and Mozilla Firefox, so we can compare results across browsers over time.

Surface Books instrumented for direct power measurement, running a looping browser test in a performance lab.

Surface Books instrumented for direct power measurement, running a looping browser test in a performance lab.

Using an open test has also enabled us to work closer with partners to deliver a better experience to you. As we built the Windows 10 Creators Update, we collaborated with hardware teams like Surface and Intel to understand what’s going on at the hardware level when you’re on the web. By designing the software and the hardware to work with each other, we can make your device run even faster and last even longer.

Battery life improvements in the Windows 10 Creators Update

Our improvements in EdgeHTML 15 are focused not only on improving the average power consumption in Microsoft Edge, but also making it more consistent. The below chart shows the 90th percentile power consumption during a multi-tab workload that went through email, social media, video, news, and more.

Bar chart comparing Edge power consumption in the Anniversary Update and in the Creators Update. In the Creators Update, Edge uses 17% less power at the 90th percentile.

As you can see, the 90th percentile has improved by 17% from the previous version of Microsoft Edge to the latest version. What does this mean for you? You can be more confident about getting consistent, all-day battery life with Microsoft Edge.

Let’s look at the specific things we’ve improved:

iframes are more efficient

Today, lots of web content is delivered using iframes, which allow web authors to embed documents (even from different origins) within their own webpages. This is a flexible, powerful, and secure tool used on many popular sites, often in the context of advertisements or embedded content. Iframes are essentially small webpages contained inside another web page.

Until now, these mini-webpages have been able to run JavaScript timers and code without restriction, even when you can’t see them. An iframe down at the bottom of an article could be running code, measuring if it’s visible, or performing animations while you’re still reading the headline at the top. With this release, we’ve made Microsoft Edge much more intelligent, throttling the JavaScript timers for iframes that aren’t visible, and stopping them from calculating animations that will never be seen. Users won’t notice any difference: the iframes still load and behave normally when you can see them. We’re simply reducing the resources they consume when they’re not visible.

Hit testing is more efficient

A common pattern we’ve found on sites is that pieces of a webpage want to know if they’re visible to the user or not, referred as hit testing. This is necessary for advertisers to judge the effectiveness of ads, as well as for creating infinite scrolling lists and other advanced layouts. In the past, this has been computationally expensive, especially since it’s done a lot. Sometimes, elements on a page will check to see if they’re visible on every frame, 60 times per second.

With the Creator’s Update, we’ve reworked what happens when the webpage needs to know if iframes or other elements are visible. We’ve added an additional layer of caching and optimizations to perform this common operation with less CPU and less power. Web developers don’t need to do anything different to take advantage of these improvements, and users won’t notice any difference, other than a faster experience and more battery life.

Intersection Observer

On top of these improvements, we’ve implemented a standards-based framework for webpages to accomplish the same thing without needing to constantly check for visibility themselves. This framework is called Intersection Observer; it’s supported by other major browsers and is documented with a working draft through the W3C.

When websites and ads take advantage of Intersection Observer, Microsoft Edge will do the work for them, calculating if they intersect with the main viewport or any other element. The page will be notified when any element’s intersection with the viewport changes, so constantly checking on every frame is no longer required. This is a much more efficient pattern, and will make the web better for everybody.

Encouraging HTML5 over Flash

In the Creator’s Update, we’re giving users even more control over their experience and helping transition the web to more secure, standards-based, and energy-efficient content by encouraging HTML5 over Flash and giving users control over where Flash is allowed to run. Not only is this good for battery life, but it will help improve security, speed, and stability.

Screen capture of a prompt in Microsoft Edge reading "Adobe Flash content was blocked."

Countless efficiency improvements based on telemetry

As with any release, we’re tweaking and improving what’s happening under the hood in Microsoft Edge. Recently, we’ve been using telemetry from real devices to measure how much time we’re spending responding to different APIs in JavaScript. This view tells us which functions we spend the most total time responding to across all devices, so we can improve those first and get the most bang for our buck.

Screen capture showing aggregated telemetry measuring how much time we’re spending responding to different APIs in JavaScript.

An interesting note: the top 10 functions account for about 50% of the total time that JavaScript spends waiting for Microsoft Edge to respond. Using this data, we’re improving not only battery life, but making webpages feel faster and snappier as well.

What’s next?

As always, this work is a step in our ongoing journey to improve your experience on the web and maximize what you can get out of your browser and your device. When it comes to making Microsoft Edge faster and more efficient, we’re never done! We look forward to continuing to push the limits of efficiency, speed, and battery life in upcoming releases.

– Brandon Heenan, Program Manager, Microsoft Edge

What’s new in Microsoft Edge in the Windows 10 Creators Update

Today, the Windows 10 Creators Update began rolling out to over 400 million Windows 10 devices. With the Creators Update, we’re upgrading Microsoft Edge with dozens of new features and under-the-hood improvements to make the best browser on Windows 10 faster, leaner, and more capable than ever.

This release updates the Windows web platform to EdgeHTML 15, the fourth release of EdgeHTML and a major step forward both in terms of the browser user experience, web platform capabilities, and fundamentals like performance, efficiency, and accessibility. In this post, we’ll share a quick overview of what’s new in each area, for both users and web developers. Stay tuned over the coming weeks, as we’ll be sharing a deeper look at many of these topics individually.

Web developers can start testing EdgeHTML 15 today by updating their Windows 10 device, or by downloading a free virtual machine from Microsoft Edge Dev. You can also test Microsoft Edge for free in BrowserStack, which offers instant cloud-based testing from a Mac or PC, including WebDriver automation. BrowserStack will be updated to include the final release of EdgeHTML 15 in the coming weeks.

Introducing Microsoft Edge in the Windows 10 Creators Update

Over the last eight months, the Microsoft Edge team has been focused on exciting new features to make the browsing experience better than ever:

Organize your web with new tab management experiences

Windows users spend more than half of their time on the web, and it’s all too easy to get tangled up in the chaos of search results, sites, and other content that can build up over hours, days, or weeks of browsing. In this update, we’ve introduced two new features to take the pain out of tab management.

Microsoft Edge now lets you set your tabs aside for later, sweeping them aside and organizing them neatly in a special section for easy access when you’re ready.


Set your tabs aside for later

Simply click the new “Set these tabs aside” button next to your row of tabs, and they are moved out of sight. When you’re ready to come back to them, just click the “Tabs you’ve set aside” icon, and you get a tidy, visual view of previous sessions. Restore one tab, or restore the full set!

If you have a lot of tabs open, it can be daunting to tell them apart, or to find a specific page in the sea of tiny icons and titles. Microsoft Edge now includes the ability to preview all your open tabs at once, so you can get back to what you’re looking for in a snap.


Show tab previews to scan your tabs more easily

Simply click the “Show tab previews” arrow to the right of your new tab button, and your tabs will expand to show a preview of the full page. You can scroll through this list to see as many tabs as you have open – when you find what you want, just click it to get back to browsing!

New reading experiences in Microsoft Edge

Microsoft Edge now lets you read books from right inside the browser, putting your favorite e-books from the Windows Store or from EPUBs on the web alongside your reading list and other content you expect to find in your browser.


Find ebooks in the Microsoft Edge Hub

You can find books in the new “Books” section of the Microsoft Edge Hub, and a wide selection of books for every taste in the Windows Store.

That’s just the beginning – you’ll find new features and extensions, and improvements to performance, usability, and more, all throughout Microsoft Edge. You can find tips on what’s new and how to get the most out of Microsoft Edge at Microsoft Edge Tips.

More efficient, more responsive, and more secure

We’ve made no secret of our ongoing obsession with making Microsoft Edge get more out of your battery, run the web faster, and keep you safer. We’ve been busy on these fronts, and EdgeHTML 15 is better than ever by any measure.

Pushing the frontier of energy efficiency

In the Creator’s Update, we’re taking the longest-lasting browser on Windows and supercharging it yet again. Thanks to major improvements in Microsoft Edge, like encouraging HTML5 content over Flash, improving the efficiency of iframes, and optimizing hit testing, Microsoft Edge on the Creators Update uses 31% less power than Google Chrome 57, and 44% less power than Mozilla Firefox 52, as measured by our open-source efficiency test that simulates real-world browsing.

These improvements translate into hours more browsing time for our customers – time to finish a crucial report while you’re at a coffee shop with no power, or to watch an extra movie on a long flight. In a head-to-head video rundown test, Microsoft Edge outlasted Google Chrome by more than three hours when streaming video!

There are countless enhancements to improve efficiency in the Creators Update, and we’re methodical about measuring the impact of each fix or new feature to make sure you get the most out of your browser. Watch this space for a detailed update on the engineering work that enables our greater power efficiency, and more on how we measure power consumption, coming early next week.

Responsiveness that puts the user first

In the past, we’ve been happy to share our leadership in synthetic JavaScript benchmarks like Google’s Octane benchmark, Apple’s Jet Stream, and others. Microsoft Edge continues to lead by those measures, but ultimately any single benchmark can only tell part of the story. In EdgeHTML 15, we’ve focused on making Microsoft Edge feel faster and more responsive, even when the page may be busy or hung, by prioritizing the user’s input above other activity, and optimizing rendering for real-world scenarios.


Comparing scrolling on a busy page, before and after the input responsiveness improvements in EdgeHTML 15.

These improvements dramatically reduce input blocking on busy sites – put simply, the browser responds much more quickly to user input like clicking links or scrolling with the keyboard, even when a page may be busy loading or executing JavaScript in the background.

That just scratches the surface – for example, over the past two releases, we’ve been working on an ongoing, multi-year refactoring of the Microsoft Edge DOM tree, which is now substantially complete. Together with a number of performance optimizations, this has resulted in a more than twofold improvement in performance in many real-world scenarios, as measured by the Speedometer benchmark, which simulates real-world app patterns using common frameworks.

Chart showing Microsoft Edge scores on the Speedometer benchmark over the past four release. Edge 12: 5.44. Edge 13: 37.83. Edge 14: 53.92. Edge 15: 82.67.

We’ll be exploring these performance and responsiveness improvements in more detail over the coming weeks – stay tuned!

Safer than ever

Microsoft Edge in the Creators Update includes two broad categories of security improvements which make the browser more resilient to typical attack strategies.

First, we’ve introduced a series of mitigations to prevent arbitrary native code execution: Code Integrity Guard and Arbitrary Code Guard. These mitigations make it much more difficult to load harmful code into memory, making it less likely and less economical for attackers to be successful in building a compete exploit. You can read more about this work in Mitigating arbitrary native code execution in Microsoft Edge.

Second, we’ve dramatically improved the resiliency of the Microsoft Edge sandbox. Microsoft Edge has always been sandboxed in a series of app containers on Windows 10 – in the Creators Update, we’ve tuned these app containers by reducing the access scope to only the capabilities that are directly necessary for Microsoft Edge to work properly. This work dramatically reduces Microsoft Edge’s attack surface area (including a 90% reduction in access to WinRT and DCOM APIs), and when combined with the exploit mitigations that apply to Microsoft Edge and its brokers, increases the difficult of exploiting any remaining vulnerabilities. You can read more about this work in Strengthening the Microsoft Edge Sandbox.

Modern capabilities for web developers

The Windows 10 Creators Update upgrades the Windows web platform to EdgeHTML 15, which introduces a number of new, modern capabilities for web developers. A few of these are highlighted below – you can find the full list of changes on the Microsoft Edge Dev Guide.

Simpler web payments with the Payment Request API

The new W3C Payment Request API enables simpler checkouts and payments on Windows 10 PCs and phones. In Microsoft Edge, the Payment Request API connects to the user’s Microsoft Account (with the user’s permission), allowing easy access to payment information. Because payment information is securely saved in a digital wallet, shoppers don’t have to navigate through traditional checkout flows and repeatedly enter the same payment and shipping address information repeatedly.

Screen capture of a Microsoft Wallet dialog box with shipping and payment information.

This can provide a faster and more consistent experience across websites, which saves shoppers time and effort by allowing them to securely share saved payment information. Learn more about the Payment Request API in our blog post, Simpler web payments: Introducing the Payment Request API, or see the Payment Request API samples on Microsoft Edge Dev.

CSS Custom Properties

CSS Custom Properties (formerly called CSS Variables) are a new primitive value type to fully cascade variables across CSS properties. Custom Properties enable the same fundamental use cases as variables in CSS pre-processors, but have the additional benefits of being fully cascaded, being interacted with via JavaScript, and not requiring the additional build step to work. Learn more about CSS Custom Properties in our blog post, CSS Custom Properties in Microsoft Edge, or see Custom Properties Pooch: a Microsoft Edge demo on Microsoft Edge Dev.

WebVR Developer Preview

Microsoft Edge now supports the WebVR 1.1 draft specification, which has been collaboratively authored by Mozilla, Google, Samsung, Microsoft, Oculus and others. Developers can now use this API to create immersive VR experiences on the web with the recently available Windows Mixed Reality dev kits. You can even get started without a headset using the Windows Mixed Reality Simulator. Acer, ASUS, Dell, HP, and Lenovo will ship the world’s first Windows Mixed Reality-enabled headsets later this year, starting at just $299 USD. Note that while WebVR is enabled by default in Microsoft Edge, using the Windows Mixed Reality Portal or Mixed Reality dev kits currently requires Developer Mode to be turned on in Windows settings.

Brotli

Brotli is a compression format that achieves up to 20% better compression ratios with similar compression and decompression speeds (PDF). This ultimately results in substantially reduced page weight for users, improving load times without substantially impacting client-side CPU costs. As compared to existing algorithms, like Deflate, Brotli compression is more efficient in terms of file size and CPU time. Learn more about Brotli in our blog post, Introducing Brotli compression in Microsoft Edge.

And lots more…

There’s simply too much to list in one post – the list goes on with features including WebRTC, async-await, TCP Fast Open, Intersection Observer, experimental support for WebAssembly, and more. You can find the full list of what’s new in the Microsoft Edge Dev Guide, or a comprehensive view of which standards are supported, planned, or in preview at Microsoft Edge Platform Status.

Built in the open

We’re proud to continue building Microsoft Edge in the open, using the voice of our community to drive product planning, and sharing our roadmap transparently. Windows itself is on an exciting journey with 10 million Insiders. These initiatives are better together – Windows Insiders are essential to building Microsoft Edge faster and with better quality, and Windows itself has been able to leverage tools like Microsoft Edge Platform Status and Microsoft Edge Platform issues – for the first time launching an open backlog and bug tracker for the Windows platform.

The voice of our community is helping us chart the course for 2017 and beyond. Nolan Lawson recently shared a look at the top highest-rated CSS features on the Microsoft Edge UserVoice:

At An Event Apart Seattle, we recently announced the development has begun on our updated CSS Grid implementation. With this announcement, every one of the features pictured are in development (or, in the case of CSS Custom Properties, shipping today!).

Beyond CSS, our roadmap for preview releases over the rest of 2017 is focused on three areas: doubling down on fundamentals like performance and reliability, delivering Progressive Web Apps on Windows, and continuing to innovate in the user experience of Microsoft Edge. We’re excited to share more about what the future holds soon!

Get started today on Windows 10, or test for free via BrowserStack

You can try Microsoft Edge on the Windows 10 Creators Update today! If you’re on a Windows 10 device, simply check for updates – see the instructions here for more details. If you’re on another platform, you can test EdgeHTML 15 instantly for free via BrowserStack, or download a free virtual machine from Microsoft Edge Dev.

Kyle Pflug, Senior Program Manager, Microsoft Edge

Announcing free Microsoft Edge testing in partnership with BrowserStack

Today, we’re thrilled to announce a partnership with BrowserStack, a leader in mobile and web testing, to provide remote virtual testing on Microsoft Edge for free. Until now, developers who need to test against a specific version of Microsoft Edge have been limited to local virtual machines, or PCs with Windows 10 installed. However, there are many developers that don’t have easy access to Microsoft Edge for testing purposes.

Screen capture showing Microsoft Edge running inside a browser on macOS.

BrowserStack Live Testing can run Microsoft Edge inside your browser on macOS, Windows, or Linux.

Today, we are excited to partner with BrowserStack, which provides the industry’s fastest testing on physical devices and browsers, so that you can focus on delivering customers the best version of your product or website. BrowserStack is trusted by developers at over 36,000 companies, including Microsoft, to help make the testing process faster and more accessible. Under this new partnership, developers will be able to sign into BrowserStack and test Microsoft Edge using their Live and Automate services for free.

Live testing provides a remote, cloud-based instance of Microsoft Edge streamed over the web. You can interact with the cloud-based browser just as you would an installed browser, within your local browser on any platform – whether it’s macOS, Linux, or older versions of Windows.

As testing setups are becoming more automated, we are excited to also offer BrowserStack’s Automate testing service under this partnership, for free. This method of testing allows you to run up to 10 Microsoft Edge test sessions via script, which can integrate with your local test runners via the standardized WebDriver API. You can even configure your machine so that the cloud-based browser can see your local development environment—see the Local Testing instructions at BrowserStack to learn more.


Testing Microsoft Edge in BrowserStack using WebDriver automation

To ensure you can test against all possible versions of Microsoft Edge that your users may be using, BrowserStack will be providing three versions of Microsoft Edge for testing: the two most recent “Stable” channel releases, and the most recent “Preview” release (via the Windows Insider Preview Fast ring).

You can test Microsoft Edge on the Windows 10 Anniversary Update (EdgeHTML 14) starting today. EdgeHTML 15 will be available in the Windows 10 Creators Update starting on April 11, 2017, and will come to BrowserStack in the following weeks.

BrowserStack currently serves more than 36,000 companies globally including Microsoft, AirBnB, and MasterCard. In addition to Microsoft Edge, the service provides more than 1100 combinations of operating systems and browsers and its Real Device Cloud allows anyone, anywhere to test their website on a physical Android or iOS device. With data centers located around the world, BrowserStack is trusted by over 1.6 million developers relying upon the service as it provides the fastest and most accurate testing on physical devices.

We’re very excited to partner with BrowserStack to make this testing service free for Microsoft Edge. Head over to BrowserStack and sign up to get started testing your site in Microsoft Edge today.

― Jason Weber, Director of Program Management, Microsoft Edge

Strengthening the Microsoft Edge Sandbox

In a recent post, we outlined the layered strategy that the Microsoft Edge security team employs to protect you from vulnerabilities that could be used to compromise your device or personal data. In particular, we showed how Microsoft Edge is leveraging technologies like Code Integrity Guard (CIG) and Arbitrary Code Guard (ACG) to break some of the techniques that hackers rely on when exploiting vulnerabilities to obtain Remote Code Execution (RCE). This is where the attacker seeks to escape from web code (JS and HTML) in the browser to run native CPU code of the attacker’s choosing. This lets the attacker violate all of the browser’s rules for the web, such as same-origin policy, and so it is important to web users that we try as hard as possible to block RCE attacks.

However, despite our best efforts, sometimes attackers get RCE anyway. In this post, we’ll explore some of the significant improvements we’ve made in the Windows 10 Creators Update to strengthen our next line of defense: the Microsoft Edge sandbox.

The history of the Microsoft Edge sandbox

Because RCE can happen, and in the past, often did, browser vendors have sought to sandbox the browser to defend the rest of the user’s PC from attack. In 2007, IE7 introduced Protected Mode, the first web browser sandbox. Windows 8 added app container to the OS, primarily to support the new Windows Store app model and support the confidence promise that apps are safe to use. IE10 and IE11 leveraged app container to create EPM (Enhanced Protected Mode) a stronger browser sandbox. However, the EPM sandbox restrictions were incompatible with older ActiveX controls that predated app container, and so EPM was provided as a security enhancing option.

Microsoft Edge does not support ActiveX, so it is able to run entirely inside app container sandboxes at all times. Since the beginning, Microsoft Edge has used several app containers. At first there was a parent app container for the Manager, which created a small number of additional app containers to host content from the internet separate from intranet content. The Windows 10 Anniversary Update moved Flash into its own, separate AC. Today the Microsoft Edge app container model looks like this:

Diagram of the Microsoft app container structure. A manager app container governs individual app containers for the Internet, Intranet, Extensions, Service UI, and Adobe Flash.

The Manager provides browser features such as the URL bar, the back button, tabs, and your favorites list. The other app containers are:

  • Internet AC: hosts content from Internet sites.
  • Intranet AC: hosts content from Intranet sites. For enterprise users, that is enterprise web sites. For consumers, that is “web sites” that are control interfaces for devices on your home network, such as your Wi-Fi router, or IoT devices. Separating this RAC from the Internet e.g. protects your home Wi-Fi router from Internet attackers.
  • Extensions AC: hosts the new extensions for Microsoft Edge.
  • Flash AC: hosts the Adobe Flash player, to isolate it from the main content processes.
  • Service UI AC: hosts special web pages, such as about:flags, and the default home page.

The Internet AC is where the action is. Its job is to host web pages from anywhere, including the JS code provided by that web page, images, and multimedia. Hosting web pages is extremely complex, due to the richness of the modern web; this is the platform of the Internet, and developers need to be able to create any application and run it in this environment. Because it is complex, and hosts web pages from anywhere, this is where web security attacks begin. A malicious web site presents content intended to exploit bugs in the content hosting system, to take over control of the content process.

If an attacker gains control of an Internet AC process, they need to find some way to achieve their goals. If their goals involve compromising the user’s device or personal data stored on the device, then they’ll need to contend with escaping from the sandbox first.

Reducing the attack surface of the Microsoft Edge sandbox

One of the most effective ways to eliminate vulnerabilities in complex applications is to minimize the amount of code that an attacker can try to find vulnerabilities in. This is often referred to as attack surface reduction and it is a key tactic in our overall strategy security. To this end, Microsoft Edge in the Creators Update of Windows 10 has significantly reduced the attack surface of the sandbox by configuring the app container to further reduce its privilege.

To understand how we tuned the Microsoft Edge AC, it is first necessary to know how app container itself works. An app container process is deny-by-default for any secured object unless the object security descriptor has an allow access control entry (ACE) that would permit the app container to have access. There are three kinds of SIDs that can be used in such ACEs:

  • Capabilities: if a Capability SID based allow ACE is in the security descriptor, and the requesting AC has that Capability SID in its token, then it gets access. E.g. Webcam-related devices are accessible to processes that have the WEBCAM Capability SID such as Microsoft Edge.
  • AppID SIDs: if a specific AppID SID based allow ACE is in the security descriptor, and the requesting AC is that specific AppID, then it gets access. The main use for this is per-app storage, which uses the AppID of that app in the security descriptor, ensuring that its storage is private to that app.
  • “ALL APPLICATION PACKAGES” (“AC” SID): this is the AC wild card, allowing all app containers to access the resource. The “AC” SID exists so that Windows can provide an app platform that is useful to developers, allowing rich UWPs in the Windows Store. For instance, most of the WinRT API surface is open to the “AC” SID, so that all UWP apps can access the WinRT APIs.

The Microsoft Edge AC has been made different in only one way: the “AC” SID is not sufficient to let a requesting process access a resource. To get access, the AC must either have a matching Capability SID, or be precisely one of the named AppIDs in the security descriptor.

Thus the AC loses access to the entire WinRT API set, and every other resource that app containers normally can access. That’s great for security, with the slight problem that it would break everything about the browser, turning it into a highly secure brick.

Diagram showing the AC access scope. The Edge content process only has access to a specific subset of the AC access scope, based on capabilities.

Microsoft Edge “Tuned” AC

Diagram of a normal app container, consisting of a full AC access scope authorized by the AC SID.

“Normal” app container

So to make Microsoft Edge work again, we used specific Capabilities to light up specific areas of functionality. For instance, we created a Capability that enables COM to work. We similarly added other new capabilities, granting access to specific resources, until Microsoft Edge worked again. Then we added some telemetry to detect access control failures for the content process and shared it to users in the Windows Insider Program (WIP) to ensure that we had granted access to all resources needed for all scenarios.

What we just did here was to create a tuned sandbox for the Microsoft Edge content process, with a much tighter fit to the functional needs of the software than a normal app container provides. That is a lot of work, which is why this is not how the UWP platform works. But because web browsers are among some of the most threatened software there is, it is worth it in this case.

We repeated this work of hand-tuning a sandbox for the Flash AC, because it also is subject to a lot of attacks. Placing Flash in a tighter sandbox complements our work in this release to make Flash be click-to-run.

Making it more difficult to exploit sandbox escape vulnerabilities

The main threats in a sandbox are the broker interfaces that provide access to resources according to a defined policy. So why have brokers at all? Brokers exist to grant access according to policy, e.g. the File broker allows a website to say “upload a file by browsing your files” and the user gets to pick the file to be uploaded, without giving the web site access to all of the user’s files.

Brokers are a threat to sandboxes because brokers are code (and therefore can have bugs) and because the brokers run outside the sandbox. If an attacker can hack a broker and run code in the broker, then the attacker can escape, similar to an inmate mugging a prison guard and then putting on the guard’s uniform to escape.

The tightened Microsoft Edge content process sandbox cuts off access to many brokers (reduced attack surface) but leaves the needed brokers accessible (residual threat). An attacker might try to exploit bugs in the accessible brokers to elevate privileges and execute arbitrary native code in the broker, and thus escape. To mitigate this threat, we have applied many of the same exploit mitigation technologies to the brokers that provide service to Microsoft Edge.

Microsoft Edge also has some surprising brokers, because the exploit mitigation work forced several components to move out-of-process (OOP), including the Chakra JIT code generator and the Flash runtime process. These components had to move out of process because they necessarily do code generation (JIT) and that is not compatible with the ACG mitigation applied to the content process. Thus, these components function as the “JS code generator” broker and the “Run Flash bytecode” broker.

They can be viewed as brokers precisely because they have permission to do something that the content process is not permitted to do for itself. They are also a threat, because an attacker that can gain control of OOP JIT or the Flash sandbox could e.g. create executable code and use that for further exploitation, bypassing ACG. Because they are a threat, we have also have put these processes into tuned, less privileged app containers, again with a custom-crafted container profile built from capabilities.

Impact to attackers

Making the Microsoft Edge content process run in this tighter sandbox reduces the sandbox attack surface, but by how much? As it turns out, the reduction is quite significant:

  • 100% reduction access to MUTEXes: allow a process to lock up a resource, causing hangs.
  • 90% reduction in access to WinRT and DCOM APIs: this is the large win here, dramatically reducing Microsoft Edge’s attack surface against the WinRT API set.
  • 70% reduction access to events and symlinks: symlinks are especially interesting, because they are often used in creative bait & switch attacks to escape sandboxes.
  • 40% reduction in access to devices: Windows supports many device drivers, and their quality is somewhat beyond Microsoft’s control. The tuned sandbox cuts off access to any device that Microsoft Edge does not explicitly need, preventing attackers from using vulnerabilities in device drivers to escape, or from abusing the devices.

While attack surface reduction does not guarantee that an attacker cannot escape the sandbox, it does dramatically reduce the opportunities for attack, much like reducing the number of windows and doors in a fortress. In addition, the enabling of additional exploit mitigations for the brokers that Microsoft Edge is legitimately able to access also increases the difficulty of exploiting vulnerabilities that remain.

Conclusion

Security is a process, not a destination, so we will continue to invest in both RCE and sandbox mitigations for Microsoft Edge. These exploit mitigations combined with the strengthened sandboxing should make Microsoft Edge significantly more work for attackers to exploit, and thus discourage attackers from trying in the first place.

Crispin Cowan, Senior Program Manager, Microsoft Edge