Tag Archives: Announcements

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

Read More

Disabling VBScript execution in Internet Explorer 11

VBScript is deprecated in Internet Explorer 11, and is not executed for webpages displayed in IE11 mode. However, for backwards compatibility, VBScript execution is currently still permitted for websites rendered in legacy document modes. This was introduced as a temporary solution. Document modes are deprecated in Windows 10 and not supported at all in Microsoft Edge.

To provide a more secure experience, both the Windows 10 Creators Update and Cumulative Security Update for Internet Explorer-April 11, 2017 introduce an option to block VBScript execution in Internet Explorer for all document modes. Users can configure this behavior per site security zone via registry or via Microsoft Easy fix solution. Enterprise customers can also configure this behavior via Group Policy.

Recommended Actions

As a security best practice, we recommend that Microsoft Internet Explorer users disable VBScript execution for websites in Internet Zone and Restricted Sites Zone. Details on how to configure this behavior can be found in KB4012494.

We also recommend that web developers update any pages that currently rely on VBScript to use JavaScript.

In subsequent Windows releases and future updates, we intend to disable VBScript execution by default in Internet Explorer 11 for websites in the Internet Zone and the Restricted Sites Zone. The settings to enable, disable, or prompt for VBScript execution in Internet Explorer 11 will remain configurable per site security zone, via Registry or via Group Policy, for a limited time. We will post future updates here in advance of changes to default settings for VBScript execution in Internet Explorer 11.

Staying up-to-date

Most customers have automatic updates enabled, and updates will be downloaded and installed automatically. Customers who have automatic updates turned off, will need to check for updates and install them manually.

― Maliha Qureshi, Senior Program Manager

Read More

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 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

Read More

Legacy web apps in the enterprise

Migrating legacy web apps to modern standards can be both costly and time consuming. IT departments are generally cost centers, and it makes sense for enterprises to want to maximize the ROI on their existing LOB apps. Many of these sites may continue to exist without being upgraded for a while yet, and it’s important to us that these apps do not block Windows customers as they adopt newer versions of Windows. This is why Windows 10 includes Internet Explorer 11 alongside Microsoft Edge, to provide a consistent and predictable level of compatibility with existing legacy applications.

In this blog post, we will discuss how Internet Explorer and Microsoft Edge can work together to support your legacy web apps, while still defaulting to the higher bar for security and modern experiences enabled by Microsoft Edge. Working with multiple browsers can be difficult, particularly if you have a substantial number of internal sites. To help manage this dual-browser experience, we are introducing a new web tool specifically targeted towards larger organizations: the Enterprise Mode Site List Portal.

The future of Internet Explorer

Naturally, this is a question we get quite frequently. With Microsoft Edge and the modern web representing the future, what will happen to Internet Explorer?

While we encourage everyone on Windows 10 to use Microsoft Edge—our modern web browser designed for faster, safer browsing—we are cognizant of the sizable investment that many of you have in legacy web apps. Our guidance to developers and IT administrators is simple. Upgrading web apps to modern standards is the best long-term solution. With that said, you can still use Internet Explorer 11 for backward compatibility and upgrade web apps on your own schedule.

Internet Explorer 11 supports Document modes and Enterprise Mode, which are essential tools for maintaining this backward compatibility. Internet Explorer, and the aforementioned tools, are considered components of the Windows operating system. They follow the Lifecycle Policy for the product on which they are installed. For Internet Explorer 11, this includes the lifespan of Windows 7, Windows 8.1, and Windows 10.

Cataloging your internal sites

Show of hands: who knows the exact number of internal sites and web apps your company has today? The answer to this is, of course, dependent on the size of your organization and many other factors. However, if we were in a large room of IT professionals, chances are there wouldn’t be many hands up.

As your organization grows, it’s only natural that the number of web apps should grow proportionally. It’s tough to have a firm grasp of what constitutes your “intranet”, in the non-networking sense of the word. This is an inherent problem that most will face when modernizing their web apps. In order to determine your dependency on legacy technologies, you first need to identify all the sites that must be tested, then learn their optimal configuration. There are a few ways you can go about this. If you attended our session at Microsoft Ignite in Atlanta last September, you should be familiar with these approaches.

Let’s go through them one-by-one:

Screen capture showing the F12 Developer Tools open to the "emulation" tab and configured to emulate "Internet Explorer 11"

F12 developer tools. The first method is by far the most manual approach. With the F12 developer tools in Internet Explorer 11, you can emulate any site with different Document modes and Enterprise Modes. Cycling through these different options will help you determine the appropriate compatibility setting. There’s some user training required to understand the technology behind the process, but fortunately little configuration is needed. One-by-one, you can build a list of sites and the legacy technologies they require. You can learn more about this approach here.

Screen capture showing an Enterprise Site Discovery report with an inventory of visited URLs.

Enterprise Site Discovery. The next approach is much more automated. Enterprise Site Discovery automatically collects inventory data on any set of computers you designate, effectively crowdsourcing the information you would learn from the F12 developer tools. Any time a user browses the web, data—such as the URL, domain, document mode, browser state reason, and number of visits—is captured. This information can be scoped to particular domains and zones for privacy. The more data you collect, the clearer of a picture you will have. Over enough time and with enough devices, the list will begin to build itself with increasing accuracy. You can learn more about this approach here.

Screen capture showing the Windows Upgrade Analytics dashboard

Windows Upgrade Analytics. The final method is based on Enterprise Site Discovery, and is the most scalable solution. Windows Upgrade Analytics is a free service that helps IT departments easily analyze their environment and upgrade to Windows 10 through the Operations Management Suite. As a part of this solution, the same site discovery data is collected, which can be similarly scoped for privacy. Going one step further, the raw inventory data is automatically analyzed and snapshot reports, like the one pictured below, are generated. You can learn more about this approach here.

Now that we have all this site information, what do we do with it?

Dual-browser experience

Microsoft Edge and Internet Explorer 11 work better together on Windows 10. Based on the size of your legacy web app dependency, determined by the data collected above, there are several options from which you can choose to configure your enterprise browsing environment:

  • Use Microsoft Edge as your primary browser
  • Use Microsoft Edge as your primary browser and use Enterprise Mode to open sites in IE11 that use IE proprietary technologies
  • Use Microsoft Edge as your primary browser and open all intranet sites in IE11
  • Use IE11 as your primary browser and use Enterprise Mode to open sites in Microsoft Edge that use modern web technologies
  • Use IE11 as your primary browser

This blog post goes into more detail on when to use which option, and which option is best for you.

Now that we have a catalog of legacy web apps, let’s define an experience where you can use a modern browser but still maintain compatibility with your older apps.

Managing your Enterprise Mode Site List

The Enterprise Mode Site List is an XML document where you can specify a list of sites, their compat mode, and their intended browser. With this schema, you can automatically launch a page in a particular browser. In the case of IE11, that page can be launched in a particular compat mode to always render correctly. You can also restrict IE11 to only the legacy web apps that need it, automatically sending sites not included in the Enterprise Mode Site List to Microsoft Edge, as of the Anniversary Update last year. Once implemented, users can easily view this site list by visiting “about:compat” in either browser.


There are equivalent Enterprise Mode Site List policies for both Microsoft Edge and Internet Explorer 11. The former list is used to determine which sites should open in IE11; the latter list is used to both (1) determine with which compat mode to load a site, and (2) determine which sites should open in Microsoft Edge. We recommend using one list for both browsers, where each policy points to the same XML file location.

The most straightforward way to build and manage your Enterprise Mode Site List is by using any generic text editor. However, we’ve provided a couple tools to make that process even easier.

Enterprise Mode Site List Manager

The first tool is called the Enterprise Mode Site List Manager. There are two versions: one for the old, v.1 XML schema, and one for the new, v.2 XML schema. This tool helps you create error-free XML documents, with simple n+1 versioning and URL verification. If your site list is of a relatively small size, this is the easiest way to manage your Enterprise Mode Site List.

On the other hand, if your site list is relatively large, you may encounter some difficulties with the client tool. It is not very scalable; it is designed for a single user. If you have more than one user managing your site list, there is the potential for overlap, among other complications.

Enterprise Mode Site List Portal

Today we are proud to announce a new tool specifically targeted for larger organizations: The Enterprise Mode Site List Portal.

Screen capture showing the Enterprise Mode Site List Portal dashboard

The Enterprise Mode Site List Portal is a web tool originally built by our own IT department, now made open-source on GitHub. The web app is designed for IIS with a SQL Server backend, leveraging Active Directory for employee management. In addition to all the functionality of the client tool, the Enterprise Mode Site List Portal helps enterprises:

  1. Manage site lists from any device supporting Windows 7 or greater;
  2. Submit change requests;
  3. Operate offline via an on-premise solution;
  4. Provide role-based governance;
  5. Test configuration settings before releasing to a live environment.

This new tool allows you to manage your Enterprise Mode Site List, hosted by the app, with multiple users. Updates are made by submitting new change requests, which are then approved by a designated group of people. Those updates are first made to a pre-production environment for testing, which can be rolled back if necessary. The final production changes can be deployed immediately, or scheduled for a later date. Users are notified of any updates in the request process via e-mail.

Already being used internally here at Microsoft, the Enterprise Mode Site List Portal has reduced site list management time by 65%. For some enterprises, processing a single change to their site list can take an entire week. What’s more, some enterprises have upwards of tens of thousands of entries in their site list. Using this new web tool can save you valuable time and expedite your modernization process.

As the tool is open-source, the source code is readily available for examination and experimentation. We encourage you to fork the code, submit pull requests, and send us your feedback!

Hopefully this helps illustrate the array of options to help manage legacy web apps in the enterprise. If you have any questions or concerns, please do not hesitate to reach out and ask. We are always looking for ways to improve your enterprise browsing experience!

– Josh Rennert, Program Manager, Microsoft Edge

Read More

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

Read More

CSS Custom Properties in Microsoft Edge

Beginning with EdgeHTML 15 in the Windows 10 Creators Update, Microsoft Edge introduces support for CSS Custom Properties, a new primitive value type to fully cascade variables across CSS properties. You can preview CSS Custom Properties in Windows Insider Preview builds beginning with EdgeHTML 15.15061. Check out our Custom Properties Pooch demo to see them in action!

Illustration of a dog wearing a sweater in an urban park

Check out our Custom Properties Pooch demo to see CSS Custom Properties in action!

What are CSS Custom Properties?

SASS/LESS and other pre-processors have been offering variables in CSS for years, which is one of the reasons why, in an informal poll, ~75% of polled web developers incorporate these tools in their day to day workflow. However, the biggest downfall of these tools is that they are effectively a “find & replace” of the specified value. This means that the variables can’t be updated without needing to recompile the stylesheets.

Enter CSS Custom Properties (née CSS Variables). While Custom Properties enable the same fundamental use cases, they have the additional benefits of being fully cascaded, being interacted with via JavaScript, and not requiring the additional build step to work.

How to use Custom Properties

Here’s a practical example: setting up primary and secondary colors for your site.


Let’s look at what is happening here, to declare a new custom property you precede a valid ident with two dashes. In our example, we are setting up our color scheme by creating custom properties for our --primary and --secondary colors. Then to utilize these properties, we need to reference them using the var() function.

It’s worth noting that a custom property can store any valid CSS, so feel free to get creative with how you utilize them! For example, the following is a valid custom property:


Note: We utilized this methodology of color math extensively in our Custom Properties Pooch demo—check it out here!

Creating a fallback

A common use case for custom properties is in components. You may design a component, and you want to provide sensible defaults for all of your custom properties. Custom Properties follows the same pattern as other CSS values and allows you to set fallback values. Here’s an example:


In this case, if the --primary custom property doesn’t exist when substitution occurs we’ll use blue instead of transparent.

Note: This does not allow a fallback for a value that doesn’t work for the given property. For example:


This doesn’t work because blue is not a valid value for margin-top, but Custom Properties don’t know the syntax rules for properties they’re use in. All that matters is whether we have a value for --primary or not. Since we do have a value, we substitute it in, try to parse margin-top: blue, and discard it as invalid per normal CSS rules.

Custom property scoping

Custom Properties are scoped like other CSS properties, by harnessing the cascade. This is valuable when, for instance, a team might be collaborating to build components or aspects of a site. To illustrate, let’s take our previous example, and add in a component we’re building that also has its own --primary custom property:


This will result in a blue background for the body and a yellow background for the .my-component.

Detecting support for Custom Properties

It’s important to remember that CSS is designed to fail silently, so if a browser doesn’t support Custom Properties, you’ll only be able to see this if your styles have visual implications. An easy way to progressively enhance your site with Custom Properties is to provide different styles to browsers that don’t support Custom Properties. You can do this by wrapping your custom property work in a @supports declaration block.


It’s important to note that @supports only checks that --foo is syntactically correct, not that the property and value match what has been declared. For example, both the previous and following examples will result in the body having a green background in browsers that support Custom Properties, even though the current value for --foo is not false.


Modifying a custom property via script

One of the primary benefits of native support for Custom Properties is the capability of dynamically modifying them via script. In order to do this you need to modify custom properties using the setProperty() and getPropertyValue() APIs. For example, to modify our --primary color on .my-component, we can do the following:


Then, to retrieve the computed value of the custom property, you utilize getPropertyValue() from getComputedStyle():


Animating a custom property

You can animate custom properties, but you can’t interpolate them. What exactly does it mean to be able to animate but not interpolate a custom property? Well, let’s take the following example:

Remember that you can store any valid ident in a custom property, so think of it as being stored as a string in an engine. The browser understands how to interpolate color: green to color: blue but it doesn’t know how to interpolate between “hello” and “world.” So, what does the browser do in the previous example? The browser takes the duration and assigns the possible values amongst the frames. For this example, that would result in a value of 50px for 500ms and 0 for the other 500ms; this is referred to in the spec as doing a 50% flip.

But I want them to interpolate!

We do too! The CSS Houdini Task Force is actively working on ways to make this happen with the Properties & Values API. If this work pans out, you’ll be able to register your custom property and inform the engine of its type, so that it can correctly interpolate values. Keep a look out for this API to start making its way into the wild, as browsers begin to experiment with these APIs to test their viability and help evolve the specification.

Improvements beyond Custom Properties

While working on our implementation of Custom Properties, we looked at a few demos that web developers had built. While some of them worked, others didn’t. When we reduced the broken demos to look for bugs, we narrowed the problems down to other gaps in our engine – not necessarily as a result of bugs in our Custom Properties implementation. For example, the largest gap we found was support for calc() within color functions (eg: rgb(), hsl()). Because this is an exciting use case where custom properties can be very powerful, we addressed this issue in our parser.

“A rising tide lifts all boats”

As we worked to fill gaps in our engine, we also wanted to be sure that web developers can rely on interoperable implementations for the feature to be useful. As we began our implementation efforts, we found that no browser had implemented the 50% flip behavior suggested in the specification for animating custom properties. Additionally, we found that no browser supported the capability of referencing variables via the var() function, within a keyframe at-rule. We worked with the CSSWG to resolve upon these issues and provide an implementation in Microsoft Edge.

Of course, the work in Edge is only one part of making sure the feature is interoperable. As we worked on our implementation, we found bugs in the implementations in existing browsers. As a result of this, we opened bugs against Blink, Gecko, and WebKit, and look forward to improved implementations across the board – including fixes shipping as early as Chrome 56 that will make Custom Properties more interoperable.

–in: “conclusion”

CSS Custom Properties not only solve a common developer request and makes your code more manageable, but it also unlocks a lot of potential for more creative work on the web. The future of the web looks bright and we’re just getting started. We’re excited to have CSS Custom Properties in the Windows 10 Creators Update, and can’t wait to see what you create!

Greg Whitworth, Program Manager, Microsoft Edge

Read More

Introducing WebRTC 1.0 and interoperable real-time communications in Microsoft Edge

We’re excited to announce the preview availability of the WebRTC 1.0 API, and support for the H.264/AVC and VP8 video codecs for RTC in Microsoft Edge, enabling plugin-free, interoperable video communications solutions across browsers and platforms.

These features are enabled by default in Windows Insider Preview builds starting with last week’s release, 15019, and will be in stable releases beginning with the Windows 10 Creator’s Update.

Background and Object RTC

Microsoft Edge introduced support for ORTC beginning in EdgeHTML 13 (Windows 10 version 1511), providing the initial foundation for real-time communications in Edge. Our priority with the WebRTC 1.0 API support is to provide interoperability with legacy implementations on existing websites, which leverage the WebRTC API as previously deployed in other browsers.

Our WebRTC 1.0 API implementation provides support for peer-to-peer audio and video based on a subset of the W3C WebRTC-PC API circa 2015, prior to the addition of the WebRTC object model.  Because this implementation is focused on legacy interoperability (including mobile applications built from early versions of the WebRTC.org source code), we don’t plan to further update the native WebRTC 1.0 API beyond this release.

To utilize the most advanced features in the Microsoft Edge RTC stack, we recommend that considering the ORTC API, especially in situations where it is desirable to control individual transport, sender, and receiver objects directly, or to set up group audio and video calls. If you need support for objects or advanced features such as multi-stream and simulcast with the current WebRTC 1.0 API, we recommend the adapter.js library, which now supports Microsoft Edge.

Codec interoperability

The H.264/AVC and VP8 video codecs are supported in the Microsoft Edge RTC stack, which means video communications are now interoperable between Microsoft Edge and other major WebRTC browsers and RTC services. We have implemented the following congestion control and robustness mechanisms for both H.264/AVC and VP8 video codecs:

These features are available within both the ORTC API and native WebRTC 1.0 API, so you can make API and video codec decisions independently.

Note that while the Edge H.264/AVC implementation supports hardware offload within both the encoder and decoder, VP8 is implemented purely in software, and as a result may exhibit higher power consumption and CPU load.  If your application uses VP8, we recommend testing on lower-end devices to ensure acceptable performance.

What’s next

As we continue to chart our roadmap for real-time communications, our next priorities are adding support for the W3C Screen Capture specification, as well as improved support for enterprise scenarios. We look forward to sharing updates and preview builds as the work progresses.  Meanwhile, we look forward to your feedback on WebRTC and our current RTC roadmap. You can try out WebRTC 1.0 in preview builds today, and if you encounter any bugs, share feedback on Microsoft Edge Platform Issues, via Twitter at @MSEdgeDev, or in the comments below.

― Shijun Sun, Principal Program Manager, Microsoft Edge
― Bernard Aboba, Principal Architect, Microsoft Skype

Read More

Introducing support for Content Security Policy Level 2

We are happy to introduce support for Content Security Policy Level 2 (CSP2) in Microsoft Edge, another step in our ongoing commitment to make Microsoft Edge the safest and most secure browser for our customers. CSP2, when used correctly, is an effective defense-in-depth mechanism against cross site scripting and content injection attacks.

This is available in the Insider Fast ring now starting with EdgeHTML 15.15002, and will ship to stable builds with the Windows 10 Creators Update.

Screen capture of the Content Security Policy Browser Test loaded in Edge, with CSP and CSP Level 2 both passing.

Microsoft Edge 15.15002 on the CSP Browser Test

Content Security Policy, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent cross-site scripting attacks that remain a common vulnerability on the web. However, the first version of Content Security Policy was difficult to implement on websites with inline script elements that either pointed to script sources or that contained script directly.

CSP2 makes these scenarios easier by adding support for nonces and hashes for script and style resources. A nonce is a cryptographically strong random value generated on each page load that appears in both the CSP policy and in the script tags in the page. Using nonces can help to minimize maintaining a list of allowed source URL values, while also allowing trusted script declared in script elements to run.

In order to use a nonce in an existing template based web application a developer adds a nonce token for each of the trusted inline scripts:

<script nonce="NonceToken">alert("Allowed since NonceToken is declared")</script>
<script nonce="NonceToken" src="https://trustedscriptsource.com.script"></script>

When the page is dynamically generated on load, the server generates a nonce value, inserts it into the NonceToken in the page and also declares it in the Content Security Policy HTTP header:

Content-Security-Policy: default-src 'self';
     script-src 'self' https://example.com 'nonce-NonceToken'

This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from https://example.com. If a script source declaration in the page includes the correct nonce value, regardless of the source URL, that script can be downloaded and executed.

Script that does not meet these requirements would not even be downloaded by Microsoft Edge. In addition, any inline script that had the correct nonce value would be allowed to execute, but no other inline script would run.

CSP2 also adds support for the following:

  • The new directives base-uri, child-src, form-action, frame-ancestors and plugin-types are now supported. See supported CSP directives for more.
  • Background worker scripts are governed by their own policy, separate from the policy of the document loading them. As with host documents, you can set the CSP for a worker in the response header.
  • A new event, SecurityPolicyViolationEvent, is now fired upon CSP violations. As well, several new fields have been added to the violation report object including effectiveDirective (the policy that was violated), statusCode (the HTTP response code), sourceFile (the URL of the offending resource), lineNumber, and columnNumber.

We worked closely with Chrome and the W3C Web Platform Tests to build an interoperable implementation, and continue to work closely with the W3C Web Application Security Working Group on Content Security Policy Level 3.

What’s next?

CSP2 is an important step for Microsoft Edge to continue to improve the security stance and defense-in-depth capabilities of web application developers, but there’s plenty still to do. Next, we’ll focus on adding support for strict-dynamic from the CSP3 spec to enable developers and site administrators to reduce their reliance on whitelists and tighten their CSP implementations.

Another CSP directive on our radar is upgrade-insecure-requests. This directive is meant to make it even easier for a site administrator to move towards using all secure transports, while avoiding having to make massive updates to URL’s in their web applications.

The work for strict-dynamic and upgrade-insecure-requests is currently under consideration for a future version of Microsoft Edge.

A more secure web is better for developers, users, and browser vendors alike, and we would love to see more web applications taking advantage of the protections that CSP offers. A good resource for thinking through an implementation is Implementing Content Security Policy. Give it a try and let us know if you run into any issues in Microsoft Edge!

― Ted Dinklocker, Program Manager, Microsoft Edge

Read More

Introducing Brotli compression in Microsoft Edge

Beginning with EdgeHTML 15.14986, Microsoft Edge supports Brotli as an HTTP content-encoding method. This change will be released to stable builds with the Windows 10 Creator’s Update early next year, but you can preview it now via the Windows Insider Program. With this release, Brotli will be broadly interoperable across browsers, with support in the latest versions of Microsoft Edge, Firefox, and Chrome.

Brotli is a compression format defined in RFC 7932, previously available as part of the WOFF2 font format. When used as an HTTP content-encoding method, Brotli 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.

In the current preview release, Microsoft Edge supports Brotli on HTTPS and HTTP connections. In a future preview release, we will update this behavior to only advertise Brotli support on HTTPS connections. Like Chrome, we will continue to decode Brotli content on HTTP connections. Note that in the current preview release, there is a known issue which results in the F12 Developer Tools incorrectly not showing the accept encoding response header. This is tracked as issue 9771399 on issues.microsoftedge.com.

As always, we welcome your feedback on Brotli in Microsoft Edge! Let us know on Twitter or in the comments below if you have any questions or issues. We’re very much looking forward to making the web just a little bit lighter with Brotli!

― Rob Trace, Senior Program Manager, Microsoft Edge

Read More

Simpler web payments: Introducing the Payment Request API

We’re thrilled to introduce a preview implementation of the Payment Request API in Microsoft Edge, enabling simpler checkout and payments on the web on Windows 10 PCs and Phones. Support for Payment Request in stable builds will be coming to EdgeHTML 15 in the Creators Update early next year.

Payment Request works with Microsoft Wallet on Windows 10 PCs and phones to make ecommerce faster and simpler for customers and merchants alike. You can begin to develop for the Payment Request API today in Microsoft Edge on preview builds, starting with Windows Insider Preview build 14986. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon.

Screen capture showing an example Microsoft Wallet checkout dialog. The dialog reads "Confirm and Pay," with dropdown menus for "Pay with," "Ship to," "Shipping options," and "Email receipt to," with the total amount and a "Pay" button.

Conversion rates in the checkout flow are a key measure for ecommerce sites. 46% of e-commerce shoppers abandon the checkout process during the payment phase, signaling frustration with the complexity and redundancy of re-entering form data or tracking down payment information. Even a small increase in the success rate of checkout make a direct impact on your site’s bottom line, while improving the shopping experience for customers.

In Microsoft Edge, the Payment Request API connects to Microsoft Wallet (with the user’s permission), allowing easy access to payment information associated with the user’s Microsoft Account. 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. The wallet 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.

How does it work?

Microsoft and the other members of the W3C Web Payments Working Group designed the API with the goal of standardizing communication across merchants, browsers, and payment methods to provide a better experience for users, and a single, consistent API for developers.

With the Payment Request API, payment information is provided by the wallet (once the user has granted consent), as opposed to being collected via a checkout form in the website. The browser mediates all the information passed between the wallet and the merchant.

Flow chart illustrating the browser mediating a payment from a user to a merchant via a wallet app on the local system.

Let’s look at how to implement the Payment Request API into a sample site.


We start with the constructor. The PaymentRequest object is constructed by passing the following parameters:

  • methodData: an array of dictionaries that contains the payment method identifiers and any pertaining data; a payment method identifier is a string that identifies a supported payment method
  • details: information about the transaction, such as the line items in an order
  • options: additional information that the Wallet may need to collect


In the snippet above, we are allowing users to pay with any debit or credit card that belongs to Visa, MasterCard, or Amex networks. The details object contains the subtotal amount, the sales tax, and the total due. These details will be shown to the user in the wallet. Please note that the API will not add up items or calculate the sales tax – it’s up to the merchant to provide the correct information. In this example, we are selling a physical good, so we’ll ask the wallet to collect the customer’s shipping address.

Showing the UI, processing the payment, and displaying the results

Once the PaymentRequest object is created, you can trigger the browser to display the wallet with request.show(). In Microsoft Edge, this will present the user with a checkout dialog from Microsoft Wallet:

Screen capture showing an example Microsoft Wallet checkout dialog. The dialog reads "Confirm and Pay," with dropdown menus for "Pay with," "Ship to," "Shipping options," and "Email receipt to," with the total amount and a "Pay" button.

Customers can then select the appropriate payment information, shipping address, and other fields, then click Pay when ready. At this point, the users will have to verify their identify. If successful, this will fulfill the request.show() promise and return  to the website all the information that the customer provided to the Wallet. For the basic card payment method, the result object will contain the card holder name, card number, expiry month and other relevant fields. The merchant can then use this information to process the transaction on the backend.

After the response comes back from the server, you can use result.complete(‘success’) to display the success screen in the Wallet and result.complete(‘fail’) to indicate a failed transaction.


Listening for events

The price might change according to the shipping address and shipping options that the customer selects. You can listen to those changes with the shippingaddresschange and shippingoptionchange events to recalculate the prices accordingly.


Feature detection

Sites can feature detect for the Payment Request API, forward the user to a legacy, form-based experience if it is not available.


Here’s an example of a minimal implementation of this code:


Testing & Availability

The Payment Request API is on by default starting with the most recent Windows Insider Preview release (14986 or higher) on phone and desktop. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon. During this preview period, Microsoft Wallet’s response for the basic card payment method will be a fake payment card response, to help developers perform early-integration testing without having to deal with the constraints of PCI.

Starting next Spring, the API will begin to return real payment card responses. Initially, the Wallet will support US billing and shipping addresses and the English language (en-US locale). Support for additional geographies and languages will be added in 2017.

Wrapping it up

Microsoft Wallet and the Payment Request API combine to provide a powerful tool for merchants to improve checkout conversion on the web, and to give customers a more pleasant and convenient shopping experience. This API is a great example of the power and flexibility of the web platform, and is on the road to broad interoperability, with Chrome for Android supporting the API starting with Chrome 54.

More details and full documentation for the Payment Request API in Microsoft Edge are available at the Payment Request Developer Guide on Microsoft Edge Dev, and the Payment Request API Reference on MSDN. You can preview Payment Request today, along with other new features coming to EdgeHTML 15, by joining the Windows Insider Program, or by downloading preview virtual machines from Microsoft Edge Dev for your Mac or PC.

If you encounter issues, you can file bugs on bugs.microsoftedge.com, or connect with us on Twitter at @MSEdgeDev. We look forward to hearing from you!

Andy Pavia, Program Manager, Microsoft Edge

Read More