Category Archives: Announcements

Auto Added by WPeMatico

Welcoming Progressive Web Apps to Microsoft Edge and Windows 10

A little over a year ago, we outlined our vision to bring Progressive Web Apps (PWAs) to the more than half a billion devices running Windows 10. We believe PWAs are key to the web’s future, and couldn’t be more excited about their potential to enable more immersive web app experiences across all device form factors.
Today, we’re excited to take a major step from vision to reality, starting with some updates on previewing PWAs in Windows and our roadmap to bring PWAs to the Microsoft Store.
Beginning with EdgeHTML 17.17063, we have enabled Service Workers and push notifications by default in preview builds of Microsoft Edge—you can learn more about those features in Ali’s post, “Service Worker: Going beyond the page.” This completes the suite of technologies (including Fetch networking and the Push and Cache APIs) that lays the technical foundation for PWAs on Windows 10.
Over the coming weeks, we’re also kicking off some experiments with crawling and indexing quality PWAs from the Web to list them in the Microsoft Store, where users can find them just like any other app on Windows 10.
In this post, we’ll give a quick introduction to Progressive Web Apps – what they are, the problems they solve, and how we’ll be enabling them across Windows 10. We’ll explore how our indexing experiments will ramp to an end-to-end PWA discovery experience later this year, and how we’ll empower developers to differentiate their PWAs on Windows – including allowing developers to claim and monetize their PWAs in the Store, interact with customers via reviews and telemetry, and enhance the app with WinRT capabilities.
Let’s dive in!
What’s a Progressive Web App, anyway?
The excitement about PWAs in the developer community is almost palpable – but amongst all that excitement, it can be hard to pin down a single, concise, authoritative definition of a “Progressive Web App.” For the purposes of this discussion, here’s how we define a PWA:
Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.
Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.
Unlike a “packaged” web app experience, PWAs are hosted on your servers and can be updated without issuing new updates to an app store. Additionally, new web standards (such as Service Worker) enable interoperable ways to implement push notifications, support for offline scenarios, background refreshing, and more, without platform-specific code.
It’s beyond the scope of this post to give a full crash course in the component technologies of a PWA (for that, we highly encourage you to check out Progressive Web Apps on MDN for a starter). But at a high level, these features are built to enable native-like capabilities – offline, background wake/refresh, instant loading, push notifications, and installability.
Progressive Web Apps in Microsoft Edge and Windows 10
So what about PWAs in Microsoft Edge and Windows 10?
We’ve announced before in several venues that we’re all-in on PWAs. In fact, as hinted above, we want to take PWAs on Windows to the next level, by making them first-class app citizens in Windows. This follows from our general philosophy that the web platform, powered by EdgeHTML, is a core part of the Universal Windows Platform on Windows 10. Because of this any device running EdgeHTML 17 gets full access to the technologies and characteristics of Progressive Web Apps.
On other platforms, PWAs primarily originate from inside the browser, and can escape the browser in response to various prompts or menu options. We’re taking things one step further on Windows! Because a PWA can be a first-class citizen in the Windows Store, a user will be able to engage fully with an installed PWA—from discovery, to installation, to execution—without ever opening the browser.

Just for kicks, here is @davatron5000’s @godaytrip as a #PWA on a preview build of Windows 10! ????(inspired by: https://t.co/Flm63mmu6K) pic.twitter.com/t2Kr5MlTOX
— Kirupa ???? (@kirupa) February 1, 2018

On the other hand, in the browser context, all the benefits of being a PWA should still accrue to the web site, empowering the user to choose how and where they want to engage with the experience.
Progressive Web Apps in the Microsoft Store
The first and most obvious distinction here is that we believe PWAs should be discoverable everywhere apps are discoverable – this means they should appear in the Microsoft Store alongside native apps.
In the next release of Windows 10, we intend to begin listing PWAs in the Microsoft Store. Progressive Web Apps installed via the Microsoft Store will be packaged as an appx in Windows 10 – running in their own sandboxed container, without the visual or resource overhead of the browser.
This has a number of benefits to users: PWAs installed via the store will appear in “app” contexts like Start and Cortana search results, and have access to the full suite of WinRT APIs available to UWP apps. They can differentiate their experience on Windows 10 with enhancements like access to local calendar and contacts data (with permission) and more.
It also has exciting benefits to developers! Listing a PWA in the Store gives developers the opportunity to get more insight into their users with channels like reviews and ratings in the Store, analytics on installs, uninstalls, shares, and performance, and more. It also provides more natural and discoverable access to your web experience on devices where the browser is a less natural entry point, such as Xbox, Windows Mixed Reality, and other non-PC form factors.
The road from the Web to the Microsoft Store
PWAs provide a natural signal of intent to be treated as “app-like” in the Web App Manifest, which allows us to leverage Bing’s web crawler in combination with our Store catalog to identify the best candidates for indexing.
The Microsoft Store has a two-pronged approach to publishing Progressive Web Apps:
Developers can proactively submit Progressive Web Apps to the Microsoft Store
The Microsoft Store, powered by the Bing crawler, will automatically index selected quality Progressive Web Apps
Submitting to the Microsoft Store with PWA Builder
Proactively submitting a PWA to the Microsoft Store requires generating an AppX containing your PWA and publishing it to your Dev Center account.
The easiest way to generate an AppX with your PWA is the free PWA Builder tool. PWA Builder can generate a complete AppX for publishing using your existing site and Web App Manifest – both website and CLI options are available.
PWA Builder takes data from your site and uses that to generate cross-platform Progressive Web Apps.
Publishing manually gives you full access to the benefits above—fine-grained control over how your app appears in the Microsoft Store, access and the ability to respond to feedback (reviews and comments), insights into telemetry (installs, crashes, shares, etc.), and the ability to monetize your app. This also gets you access to all the other benefits of the Microsoft Dev Center, including promotion and distribution in the Microsoft Store for Business and the Microsoft Store for Education.
Automatically indexing quality Progressive Web Apps with the Bing Crawler
We’ve been using the Bing Crawler to identify PWAs on the web for nearly a year, and as we’ve reviewed the nearly 1.5 million candidates, we’ve identified a small initial set of Progressive Web App experiences which we’ll be indexing for Windows 10 customers to take for a spin over the coming weeks.
We will crawl and index selected PWAs from the web to be available as apps in the Microsoft Store
Over the coming months, we’ll be ramping up our automatic indexing in the Microsoft Store from a few initial candidates to a broader sample. Throughout this process, we’ll continue to vet our quality measures for PWAs, to make sure we’re providing a valuable, trustworthy, and delightful experience to our mutual customers on Windows devices.
Whether automatically indexed by the Store or manually submitted by the site owner, the Web App Manifest provides the starting set of information for the app’s Store page: name, description, icons, and screenshots. Developers should aim to provide complete and high-quality information in the manifest. Once in the Store, the publisher will have the option of claiming their apps to take complete control of their Store presence.
Quality signals for Progressive Web Apps
We’re passionate about making the Microsoft Store a home to trustworthy, quality app experiences. With that in mind, we’ve identified a set of quality measures for developers to keep in mind as you build PWAs.
We won’t ingest every app that meets these criteria, but will be including them in our considerations for candidates as we gradually expand our program.
Web App Manifests should suggest quality: In our initial crawl of sites looking for PWAs, we discovered over 1.5 million manifests across 800k domains. Looking at a selection of these sites, we discovered that not all are good candidates for ingestion. Some aren’t PWAs at all, and others have a boilerplate manifest generated by tools like favicon generators. We will be looking for non-boilerplate manifests that include a name, description, and at least one icon that is larger than 512px square.
Sites should be secure: Access to the Service Worker family of APIs requires an HTTPS connection on Windows and other platforms.
Service Workers should be an enhancement: We’ll look for a Service Worker as a signal for ingesting PWAs, but we also expect experiences to degrade gracefully if Service Worker is unsupported, as it may be on older browsers or other platforms. You can get started building a basic Service Worker with PWA Builder; Mozilla also has great recipes if you are looking for somewhere to start.
Sites should consider automated testing for quality: There are a number of tools out there for this, including our sonarwhal, Lighthouse, aXe, and more.
PWAs must be compliant with Microsoft Store policies: PWAs will need to meet the standards of the Microsoft Store, just like any other app. We will not ingest PWAs that violate laws or Store policies.
Once we have shipped these technologies to mainstream Windows customers with EdgeHTML 17, we will gradually expand our indexing of high-quality Progressive Web Apps into the Microsoft Store based on quality measures and the value they add to the Windows ecosystem.
PWA or UWP?
Given the overlap in terms of capabilities, we often get asked about the recommended approach: PWA or UWP. We see this as a false dichotomy! In fact, on Windows 10, the Universal Windows Platform fully embraces Progressive Web Apps, because EdgeHTML is a foundational component of UWP.
For developers who are building a fully-tailored UWP experience, building from the ground up with native technologies may make the most sense. For developers who want to tailor an existing web codebase to Windows 10, or provide a first-class cross-platform experience with native capabilities and enhancements, PWA provides an on-ramp to the Universal Windows Platform that doesn’t require demoting or forking existing web resources.
When evaluating native app development in relation to Progressive Web Apps, here are some of the questions we recommend asking:
Are there native features the Web can’t offer that are critical to the success of this product?
What is the total cost (time and money) of building and maintaining each platform-specific native app?
What are the strengths of my dev team? or How easy will it be to assemble a new team with the necessary skills to build each native app as opposed to a PWA?
How critical will immediate app updates (e.g., adding new security features) be?
In other words, the choice between PWA and native should be evaluated on a case-by-case basis. For example:
If you are looking to craft an experience that takes full advantage of each platform you release it on and you want to agonize over every UX detail in order to differentiate your product… native might be the best choice for you.
If you are maintaining a product on multiple native platforms in addition to the Web and they are all largely the same in terms of look & feel and capabilities, it may make more sense to focus all of your efforts on the Web version and go PWA.
If you are planning a brand-new product and the Web provides all of the features you need (especially when you also consider the additional APIs provided via the host OS), building a PWA is probably going to be a faster, more cost-effective option.
For a more in-depth discussion, check out our video from Microsoft Edge Web Summit 2017: PWA, HWA, Electron, oh my! Making sense of the evolving web app landscape.

Testing your Progressive Web Apps in Microsoft Edge and Windows 10
Service Worker, Push, and other technologies are enabled by default in current Insider builds in Microsoft Edge, and we intend to enable them by default when EdgeHTML 17 ships to stable builds of Windows 10 next year.
You can get started testing your PWA in Microsoft Edge today by downloading a recent build of Windows 10 via the Windows Insider Program, or using a free VM. We’ll be sharing more about Service Worker debugging features in the Microsoft Edge DevTools in a future post—stay tuned!
Service Worker features will be enabled for the UWP platform (including installed PWAs) with the upcoming release of Windows 10, but are currently not available to published apps in the Store, including on Windows Insider Preview builds. In the meantime, you can test them in Insider builds by sideloading your AppX using the install script provided by PWA Builder tools, or by running your PWA inside Microsoft Edge.
What’s next for Progressive Web Apps on Windows?
Over the coming months, we’re laser focused on polishing our initial implementation of the core technologies behind PWAs in EdgeHTML and the Universal Windows Platform—Service Worker, Push, Web App Manifest, and especially Fetch are foundational technologies which have a potentially dramatic impact to compatibility and reliability of existing sites and apps, so real-world testing with our Insider population is paramount.
In our initial implementation, we’ll be focused on those two components—the Service Worker family of technologies in Microsoft Edge, and PWAs in the Microsoft Store. Looking forward, we’re excited about the potential of PWA principles to bring the best of the web to native apps, and the best of native apps to the web through tighter integrations between the browser and the desktop. We look forward to hearing your feedback on our initial implementation and experimenting further in future releases.
In the meantime, we encourage you to try out your favorite PWAs in Microsoft Edge today, and get started testing your installable PWA on Windows, both via PWA Builder and in Microsoft Edge! We look forward to hearing your feedback and to digging in to any bugs you may encounter.
Here’s to what’s next!
– Kyle, Kirupa, Aaron, and Iqbal

Building a great touchpad experience for the web with Pointer Events

Most web pages don’t fit on one screen, so good scrolling behavior is an integral part of a good web browser. It’s so crucial to the user experience that we have spent a lot of time optimizing page scrolling, with great results.
Since launching Microsoft Edge, we’ve optimized most scrolling experiences — scrolling via touchscreens, page and content scrollbars. One particular focus in previous releases has been improving touchpads, specifically precision touchpads (PTPs), to provide a smooth, fluid, intuitive experience by default.
In this post, we’re introducing a new optimization coming in EdgeHTML 17 to allow developers to customize scrolling behaviors and gestures with Precision Touch Pads, without impacting scrolling performance: PTP Pointer Events.
Background
Precision touchpads are high-end touchpads that ship in Surface devices (Surface Pro 2 and later) and modern Windows 10 devices from our OEM partners. Windows 10 takes advantage of this hardware to enable system-wide gestures and better, more responsive scrolling than what was possible with older technology.
Microsoft Edge also utilizes PTPs to enable back/forward swipe and to enhance users’ scrolling experience via off-thread (aka independent) scrolling. Since PTP input is processed differently by the input stack in Windows 10, we wanted to ensure that we took advantage of this and that we gave users a scrolling experience that felt as natural as their experience with touchscreens everywhere on the web.
However, the web has traditionally had a bit of a design flaw when it comes to scrolling, in the form of scroll jank — that ‘glitchy’ feeling that the page is stuck, and not keeping up with your finger while you’re scrolling.
Often, scroll jank is caused by mousewheel or Touch Event listeners on the page (these are often used for tracking user interactions or for implementing custom scrolling experiences):

// Examples of event listeners that can negatively affect scrolling performance
document.addEventListener("wheel", handler);
document.addEventListener("touchstart", handler);

If one of these listeners is going to modify the default scrolling behavior of the browser, the browser has to cancel its optimized default scroll altogether (accomplished by web developers calling preventDefault() within handlers). Since browsers don’t always know if the listener is going to cancel the scroll, however, they always wait until the listener code executes before proceeding with the scroll, a delay which manifests itself as scroll jank:
An example page showing scroll jank due to a mousewheel handler with a 200ms duration.
Browsers identified this issue and shipped passive event listeners as a mitigation (available in Chrome 51+ and EdgeHTML 16+) to help reduce its scope:
The same example with smooth scrolling thanks to passive event listeners
Intersection Observers also help get around this issue by providing web developers with a mechanism to track user interactions with the page (to trigger lazy loading of infinite scrollers, for example) without affecting scrolling performance. These two approaches, however, still do not solve the cases where active event listeners are necessary, and require developers to be aware of the issues explained above and to change their sites in order for users to see improvements.
Given that we wanted to enable the best scrolling experience with PTP on as many sites as possible while minimizing developer work, we made the decision to not fire mousewheel events in response to PTP gestures (such as two finger pans). While this greatly reduced scroll jank and gave users a scrolling experience akin to the one they get on touchscreens, the lack of mousewheel events being fired unfortunately also meant that users were unable to zoom on sites such as Bing Maps and pan on sites that use custom scrolling controls (both of which expect mousewheel events coming from touchpads in order to operate).
Developers on our public issue tracker have made it clear that this has been a top pain point, however, the Microsoft Edge team wanted to ensure that the solution built to address these broken experiences not only fixed them, but also preserved the functional and performance benefits accrued by not firing mousewheel events.
PTP Pointer Events
As of EdgeHTML 17, Microsoft Edge will fire Pointer Events with a pointerType of “touch” in response to PTP gestures. While this is a departure from the mousewheel events of the past, we believe that the advantages to this approach more than justify the departure:
No additional overhead for modern websites
If your website already supports Pointer Events and touch, there is no additional work you need to do to take advantage of PTPs in Microsoft Edge; your site will just work!
If you have not yet implemented Pointer Event support, we strongly recommend you check out the MDN documentation for Pointer Events to prepare your site for the modern web. Pointer Events are available on Internet Explorer 11, Microsoft Edge, and Google Chrome and are in development in Firefox.
Enhanced scrolling performance
Scrolling with PTPs in Microsoft Edge will never cause scroll jank since Pointer Event handlers (unlike mousewheel and Touch Event handlers) are designed so that they cannot block scrolling.
With these new changes in Microsoft Edge, you can be certain that you are getting the best possible scrolling experience on PTP-enabled devices thanks to Pointer Events.
Improved Gesture Recognition/Site Functionality
Since PTP Pointer Events emulate touch Pointer Events, PTP gestures such as pinch to zoom and two finger panning will light up on sites that already support touch Pointer Events. This will allow developers to build near-native gesture experiences on the web, complete with the smooth animation and inertia curves that users have come to expect from interacting with pages via touch.
Using PTP Pointer Events
Using PTP Pointer Events on your site is as simple as registering for Pointer Events and using the touch-action CSS property to control how touches are handled by the browser:
In HTML, add the touch-action CSS property to your target element to prevent the browser from executing its default touch behavior in response to gestures (in Microsoft Edge, for example, this will prevent two finger swipes from triggering back/forward swipe behavior):

<canvas height=400 width=400 id="canvas" style="touch-action: none;"></canvas>

In JavaScript, attach a Pointer Event listener to your target element. You can determine the type of pointer that caused the handler to be invoked using the pointerType property of the event object passed into the event listener callback:

document.getElementById(‘canvas’).addEventListener(‘pointermove’, function(event) {
console.log(‘pointermove!’);
});

More detailed information on Pointer Events can be found on MDN here.
Once you have added Pointer Event support to your site, the only step that remains is understanding how Microsoft Edge exposes PTP gestures to sites as Pointer Events. Note that for both of the gestures below, the Pointer Events generated in EdgeHTML will be sent to the element that is directly under the cursor when the PTP gesture begins.
Two Finger Panning
The two finger PTP panning gesture is converted within EdgeHTML to a single contact gesture (identical to a single-fingered touch pan gesture) and is exposed to sites as such. The gesture originates at the cursor location and any movement of the fingers on the touchpad is translated to a scaled delta which results in a pan action. The CSS touch-action property can be used to control the way that a specific region can be manipulated by the user.
Zooming
The pinch to zoom PTP gesture is converted within EdgeHTML to a gesture that originates at the cursor location. Two contacts are placed at a scaled distance away from the cursor location and any movement of the fingers on the touchpad is translated into scaled deltas which results in a zoom action.

Rotation
PTP Pointer Events in Microsoft Edge introduce support for two-finger Rotation gestures for the first time, due to the fact that raw pointer data is exposed directly from the touchpad in all cases other than panning (where the two contacts on the touchpad are combined into one). Existing sites with Pointer Event handlers for touch that support rotation will light up with Precision Touchpads in Microsoft Edge as well.
What’s next
You can try out PTP Pointer Events in Microsoft Edge starting with our next Windows Insider release on any site that currently supports Pointer Events for touch gestures, including Bing Maps or Google Maps, on any device with a Precision Touchpad. The broader Windows 10 community will see PTP Pointer Events when EdgeHTML 17 ships with the next major release of Windows 10.
We are excited to enable jank-free and near-native touchpad experiences across the web using Pointer Events, and look forward to feedback on this feature from developers and end users alike! You can share any bugs you encounter in testing via Microsoft Edge Platform Issues or the Feedback Hub app on Windows 10, or give your feedback directly @MSEdgeDev on Twitter or in the comments below.
Try it out and let us know what you think!
— Scott Low

Introducing the Web Media Extension Package with OGG Vorbis and Theora support for Microsoft Edge

We’ve heard requests from many of our customers to support additional open-source formats in order to access a broader set of content on the web. To address this, ,we recently added support for the WebM container format and the VP9 and Opus codecs on supported hardware.
Today, we’re excited to announce a new mechanism which will allow our customers to add more formats on demand and increase our agility to add new formats in the future: Media Extensions. Alongside this mechanism, we’re releasing the Web Media Extensions package to the Microsoft Store as a free Media Extension for Microsoft Edge.
Media Extensions
Media on the web has been evolving at a furious rate for the last few years. Adaptive video streaming is now common, providing a simpler mechanism for professional-quality video under changing network and device conditions; HTML5 Premium Media provides the tools for interoperable, plugin-free protected media; plugin-free video and audio conferencing is now routine with tools like WebRTC and ORTC.
We’re proud to be at the leading edge of these features, providing a modern set of capabilities with more efficient and higher quality video in Microsoft Edge. At the same time, we’re always looking to make sure Microsoft Edge meets the needs of our customers and web developers alike, and to provide a seamless playback experience on the web.  The rapid growth in media capabilities has naturally resulted in a need to support more media formats in web browsers.
Media Extensions are Media Foundation components designed to extend the core Windows platform and enable Windows apps including Microsoft Edge to support an ever-increasing range of formats. Media Extensions, much like browser extensions, allow customers to extend their device beyond the core experience shipped as part of Windows 10. It also allows the developers of media technologies to update and enhance media components independently of the Windows 10 release schedule. This allows us to work with the community to deliver high quality, interoperable codecs to Edge customers quickly and reliably.
The Web Media Extensions Package
The Web Media Extensions package adds support for the open source OGG container and the Theora and Vorbis codecs, and it expands support for WebM VP9 to work with Theora in simple video elements.  Our support for these formats is based on proven implementations from the well-known FFmpeg codecs using the FFmpeg Interop library. We expect this set of formats to be useful for enthusiasts and customers with specific format needs and we’re excited to bring support for these FFmpeg formats to Microsoft Edge!
Our initial release of the Web Media Extension package is focused on supporting these developers and customers who know they need support for these formats – the seekers and enthusiasts on the web. In the spirit of flighting, this will allow us to learn and improve based on your feedback before we expand support to the broader range of Edge customers on the market today. Long-term, we expect to expand distribution of the Web Media Extension package to all Windows 10 devices so that these formats become a trusted and reliable part of the web platform available to developers.
Getting started
Developers and customers can get started with these new formats in Microsoft Edge by simply installing the Web Media Extension Package from the Microsoft Store. You can also find the package under the Microsoft Edge Extensions collection in the store. This package extends the base media platform in Windows, so the formats will be available to Windows apps and Microsoft Edge with no further action from the user.
We encourage you to install the extension and try it out today! Going forward, we intend to expand distribution, release more formats as Extensions and work with third parties on new formats for Microsoft Edge – your usage will help validate this approach and help us identify potential issues as we evaluate opportunities to provide these capabilities to our customers.
We’re passionate about providing a high-quality, interoperable media experience in Microsoft Edge. This extension package is a first step forward broadening Microsoft Edge’s playback capabilities while providing new mechanisms for us to deliver expanded support in response to the diverse needs of customers, devices, and different browsing contexts. We look forward to hearing your feedback as we work with the community to move our media platform forward!
— David Mebane, Senior Program Manager, Windows Media Platform— Jerry Smith, Senior Program Manager, Microsoft Edge

Breaking on DOM Mutations in the Microsoft Edge DevTools

Editor’s note: This continues the series we began last week, highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
As the web platform evolves, the line between web and application developers continues to blur. It’s common now for a web site to be more like a web app, with complex, single-page user interfaces built up by a combination of libraries and custom JavaScript code. This in turn has led to a web platform that requires more sophisticated tools to efficiently debug.
As we rely more and more on JavaScript to build up the DOM, and rely on tools that interact with and abstract away from us the nuances of DOMs across browsers, we lose the ability to easily know what caused a change to an interface node, especially if that change is unexpected. In EdgeHTML 16 (available with the Windows 10 Fall Creators Update), we’ve introduced the ability to break on mutations caused by any of the 450+ DOM APIs in the EdgeHTML platform and jump directly to the script that triggered the change.
For those who use Chrome DevTools, this will be a familiar and welcome addition to Edge debugging. It was our goal to implement and advance on a similar experience to make jumping between the two tools as seamless as possible. Read on for the changes you can expect in the Fall Creators Update (and can preview now via Windows Insider builds).
Breakpoint types
There are three breakpoint types:
Subtree modifications: when a node is added or removed from the subtree of the element on which the breakpoint is set
Node removal: when the node the breakpoint is set on is removed from the DOM tree
Attribute modifications: when an attribute of the node on which the breakpoint is set is modified
Setting and managing breakpoints
To set a breakpoint, right-click on a node in the DOM tree in the Elements tool. Under the DOM breakpoints item, you’ll see options to set and unset the supported breakpoint types.
Add new breakpoints by right-clicking a node in the DOM tree and selecting “DOM breakpoints.”
When you add a breakpoint, a red breakpoint indicator appears next to the node in the DOM tree. The breakpoint is also listed in the DOM breakpoints pane which exists in both the Elements and Debugger tools. You can disable and delete breakpoints by using the mouse to click the checkbox and delete icons, respectively. You can also right-click, or use the keyboard, on a breakpoint to invoke a context menu to apply the same actions:
Disable or delete breakpoints in the new DOM Breakpoints pane.
Triggering a breakpoint
A breakpoint is triggered whenever one of over 450+ DOM APIs are called by JavaScript. When the breakpoint triggers, you’ll jump to the Debugger tool with the file containing the triggering script opened and the line with the API call highlighted.
When a DOM API triggers a breakpoint, the Debugger tool will open with the API call highlighted.
In the Debugger tab, you’ll notice at the top of the call stack is an entry with the selector for the node the breakpoint was triggered on, and the type of breakpoint triggered.

Breakpoint persistence
We store breakpoints as part of your Edge DevTools settings and scope them to the URL of the page they’re set within. When you close and re-open Edge DevTools, or refresh the page, we’ll restore and attempt to automatically rebind the breakpoints to their respective DOM nodes. If we’re unable to automatically rebind them, we’ll indicate that they’re unbound in the UI with a warning icon on the breakpoint circle.
Breakpoints that cannot be rebound when the session is restored will show an alert icon in the Breakpoints pane.
You can use the context menus or shortcut icons in the DOM breakpoints panes to manually rebind any breakpoints we were unable to automatically rebind.
What’s next for DOM Breakpoints
We’re excited to launch this feature and hope to solve for as many developer scenarios as we can, but want to highlight a few gaps in the current implementation:
We don’t currently support rebinding breakpoints inside iframes. If you set a breakpoint in an iframe and close Edge DevTools or refresh the page, the breakpoint will be lost.
If your script encounters a synchronously-executed breakpoint before the DOM readyState is completed, you won’t be able to set a DOM breakpoint while the debugger is paused. You can typically remedy this situation by setting the defer or async script attributes.
For synchronous scripts, we trigger automatic rebinding of breakpoints when the window.onload event is called. In this case, we may miss binding breakpoints that would trigger during initial script-driven build-up of the DOM. For asynchronous scripts, we trigger a rebind attempt before the first script executes, so your breakpoints may rebind and trigger as desired.
We’re evaluating closing these gaps in future releases, as we continue to evaluate the prevalence of these scenarios. If you have feedback and find these unsupported areas to be blockers, please let us know!
Tell us what you think
We hope you enjoy this new addition and find it improves your productivity as you go about your developer workflows. If you find any bugs, please report them via the Feedback Hub. If you have questions or feature requests, don’t hesitate to leave a comment here, or reach out to us on UserVoice or Twitter.
— ­Brendyn Alexander, Senior Program Manager, Microsoft Edge DevTools

New and improved Event and CSS inspection for Microsoft Edge DevTools

Editor’s note: This is the first post in a series highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
EdgeHTML 16 is now rolling out to devices around the world as part of the Windows 10 Fall Creator’s Update—and with it, some great improvements to the Microsoft Edge DevTools.
In this post, we’ll walk through a slew of new updates to the Elements tab (formerly known as the DOM Explorer) with improvements to CSS at-rules, Event Listeners, Pseudo-Elements and the overall user experience.
CSS at-rules
In EdgeHTML 16, we’ve completely redesigned how at-rules appear in the Elements tab. Previously, usage of CSS at-rules were either missing or incorrectly displayed. The DevTools now show @supports, @media and @keyframes styles in separate sections within the Styles pane:

The new at-rules interface inspecting @keyframes on the CodePen example above
We also added a new pane for inspecting the rendered font of an element. In the Fonts pane, you can now see whether a font is served from the local machine or over the network and what, if any, fallback font face was used. If over the network, the DevTools will show the correlating @font-face rule:

You can now inspect the rendered font of an element in the Fonts pane.
Ancestor Event Listeners
The DevTools now allow you to inspect all event listeners on ancestor elements up to the current Window with the Ancestors option. You can also group event listeners by Element to see how the events will fire at each level of the element tree. This enables you to determine where a rogue event listener might be firing higher up the tree.

You can now inspect all event listeners on ancestor elements up to the current Window with the Acnestors option.
Ancestor Event Listeners can be grouped by Element or Event.
Pseudo-Elements
In the Styles pane, the DevTools now group styles by their respective pseudo-element, supporting ::before, ::after, ::first-letter, ::first-line and ::selection. This should make it easier to determine which style is winning the cascade.

Styles are now grouped by their respective psuedo-element.
User Experience
This release also includes some tweaks to the user experience of the DevTools to make it easier for developers who work in multiple browsers.
In particular, Layout pane has been removed and the box model is now at the top of the Computed pane, freeing up space for two new panes: Fonts and DOM breakpoints.

The box model is now at the top of the Computed pane.
Finally, to make it easier on developers who switch between multiple browsers, we’ve added two new ways to launch the DevTools: Ctrl+Shift+I and Ctrl+Shift+J. Ctrl+Shift+I will launch the DevTools just as the F12 keybinding does today. Ctrl+Shift+J will launch the DevTools (if not already open) and take you directly to the Console.
You can try out and file feedback for these new features starting with EdgeHTML 16, and find us on Twitter @EdgeDevTools to let us know what you think!
— Clay Martin, Program Manager, Microsoft Edge DevTools

Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16

JavaScript performance has always been a core area of focus for our team. Every release, we look for opportunities to improve end users’ browsing experience on real workloads with shorter start-up time, faster execution, and leaner memory usage. These efforts are guided by invaluable ongoing customer feedback and telemetry data.
In this blog post, we will share a few new performance enhancements in the Chakra JavaScript engine, as well as updates on the availability of on-by-default WebAssembly, SharedArrayBuffer and Atomics support in Chakra and Microsoft Edge in EdgeHTML 16 with the Windows 10 Fall Creators Update.
More memory savings from deferring/re-deferring functions
In EdgeHTML 15, Chakra introduced the capability to re-defer functions. To briefly recap Chakra’s deferral/re-deferral pipeline, at start-up time Chakra performs a quick pre-parsing pass to check for syntax errors, and then defers the full parsing of eligible functions until they are first executed. At a later point, if heuristics determine that a fully-parsed function will most likely never be executed again, Chakra dumps its metadata generated since full-parsing and returns to a lean state as if the function is just pre-parsed and being deferred (hence the name re-deferral).

The deferral/re-deferral feature helps sites boost start-up time and save memory on redundant functions (imagine pulling a bunch of libraries and only just using 30% of the code, sound familiar?).
In EdgeHTML 16, we’ve addressed the feature’s previous limitation on handling functions in lexical and parameter scopes, and allowed functions in all scopes to be deferred and re-deferred. For example, it is common to have large chunks of scripts wrapped in giant try blocks for error handling, and functions enclosed in a block are now eligible for deferral/re-deferral.

// foo can be deferred/re-deferred after the Fall Creators Update
// example 1 – lexical/block scope
try {
  function foo() {…}
  var bar = foo();
}

// example 2 – parameter scope
function bar(foo = function(){…})) {…}

This change further improves memory savings made possible by deferral/re-deferral. The exact effect varies depending on the coding patterns of the sites. According to our experiment on a small sample of popular sites, this change along with others in the past update typically reduce the memory allocated by Chakra by 4-9%. The impact can also be much larger in some cases―such as a ~35% memory saving on Gmail.
Polymorphic inline cache for property access using square brackets (object[‘property’])
Polymorphic inline cache (PIC) is an optimization technique employed in Chakra (and many other runtimes) since Chakra’s inception. Chakra has an internal type system that maps each value to its type. When the Chakra Just-In-Time compiler (JIT) generates optimized code for hot code paths, Chakra may deploy an inline cache at each call site (location for function/subroutine calls such as property access) to memorize and store fast paths for the types encountered.
Polymorphic inline cache is a kind of inline cache that can remember multiple types at a given call site. In EdgeHTML 16, Chakra added the ability to place polymorphic inline cache for the object[‘property’] syntax, allowing cases where object may be of different types to be optimized.

// example – obj can be of {a: Number} or String type
let arr = [{a: Math.random()}, Math.random().toString()];
arr.forEach(obj => {
  for (propNames in obj) {
    if (obj.hasOwnProperty(propNames)) {
      // without PIC, multiple types lead to generic slow path
      // with PIC, both types for obj
      console.log(obj[propNames]);
    }
  }
});

This change should benefit typical users browsing sites using bracket notation and shows up as up to 8% speedup on tests utilizing Angular and React frameworks.
Enable optimizations for functions with try/finally
In JavaScript, it is a best practice to use the finally clause to gracefully clean up resources following a try block. Until the latest update, Chakra did not optimize functions that include a try/finally block because it was a non-trivial job to account for exceptions and unwinding in JIT optimizations.
Starting with EdgeHTML 16, when the Chakra JIT analyzes functions and builds the flow graph, it separates the excepting and non-excepting cases and creates two paths for a try/finally block, allowing general optimizations to be applied on the non-excepting path and forcing a bailout in case of an exception.

More optimizations for try/catch/finally are just on the horizon. ChakraCore recently added support for inlining in functions with try/catch/finally and you can expect this change to propagate to Chakra and Microsoft Edge in the next major Windows update.
WebAssembly, SharedArrayBuffer, and Atomics on by default
In the previous update, Chakra and Microsoft Edge debuted WebAssembly Minimum Viable Product (MVP), SharedArrayBuffer and Atomics support behind the “Experimental JavaScript Features” flag. With a bit of tuning in the past few months, these features are now stable and enabled by default in EdgeHTML 16.
Several changes also help improve WebAssembly performance in Chakra by 20-25% on workloads we have been tracking. Try it out for yourself! Point Microsoft Edge at a fun WebAssembly game like Funky Karts to see the improvement with no flags required!

Demo of Funky Karts in WebAssembly in Microsoft Edge (demo by Ross Smith)
Microsoft has been and will continue to work closely with Mozilla, Google, Apple and others in the WebAssembly community to move the technology forward. Impactful post-MVP features such as threads and GC are currently being explored in the WebAssembly Community Group.
Get involved
We are excited to share these new performance optimizations as well as on-by-default WebAssembly, SharedArrayBuffer, and Atomics support in Chakra and Microsoft Edge.
As always, we’re making more enhancements in future releases, and your feedback is one of our key signals for what to do next. So stay tuned and be sure to share your thoughts with us on the ChakraCore repo, or via @MSEdgeDev and @ChakraCore on Twitter!
― Limin Zhu, Program Manager, Chakra

sonar: Linting the web forward

In addition to building a great browser and dependable web platform for Windows, we’re passionate about empowering developers to build great websites. With that goal in mind, we launched modern.IE in 2013 featuring a static scan tool to detect optimizations for old versions of IE, outdated libraries, missing prefixes, and more. The web has moved on since then, and it’s time to update our tools accordingly!
Introducing sonar
Today, we are excited to announce the next evolution of the static scan tool: sonar, a new linting tool and site scanner for the modern web.

sonar brings many improvements compared to previous scanners: execution of websites code instead of static analysis, a more flexible and modernized set of rules, parallel test execution, integration with other services, a completely open source code base from day one, and more. Additionally, sonar can also be used as a command line tool (CLI) that you can integrate directly into your local web development workflows.
Web development is more than HTML, JavaScript, and CSS: developers are expected to have a grasp of accessibility, performance, security, emerging standards, and more, all while refreshing this knowledge every few months as the web evolves.
Web development can be complex.
Linting the web forward
Simply put, the web is complex, and we want sonar to make it a bit easier for you to write great websites. To make sure that sonar can be helpful not only now, but in the future, we started with a set of guiding principles before we wrote a single line of code.
Put the user at the center
Rather than just telling developers what was wrong, sonar had to also say why. It is important to know the reason for an issue so developers can decide if that really applies to their work. The requirements from website to website can change a lot, for example, an intranet website and an online shopping experience will have vastly different needs. Therefore, sonar should also be easy to use, configure, and expand.
Build for the community’s best interests
The web belongs to everyone, and this project should too. Everything had to be open sourced since the beginning, but that wasn’t enough―we wanted to go even further and make it easier for the web community to get involved, and remove any possible doubt that this project has the community’s best interest in mind. For that reason, we decided to donate the project to the JS Foundation early during the summer.
Collaborate with existing tools and services
sonar should avoid reinventing the wheel, instead leveraging and integrating existing tools and services that help developers build for the web. We are happy to say that sonar now integrates with aXe Core, AMP validator, snyk.io, SSL Labs, and Cloudinary.

You can hear more about sonar’s history and guiding principles in our session at Microsoft Edge Web Summit.
sonar today, and what’s next
We’ve come a long way since we wrote down those principles a few months ago: sonar is now available as an open sourced command line utility, built on node, that you can install via npm. Additionally, it has an open-source online service, deployed on top of Azure, using docker containers, that can scan any publicly available website. sonar’s rules are backed by a collection of best practices for the web, with links to more detailed documentation that keeps growing with each new rule.
But this is just the beginning. We’re hard at work on a backlog of exciting features for future releases, such as:
A plug-in for Visual Studio Code: We want sonar to help you write better websites, and what better moment than when you are in your editor.
Configuration options for the online service: As we fine tune the infrastructure, the rule configuration for our scanner is locked, but we look forward to adding customization options here in the near future.
New rules for a variety of areas like performance, accessibility, security, Progressive Web Apps, and more.
If you are excited about sonar, making a better web, and want to contribute, we have a few issues where you might be able to help. Also, don’t forget to check the rest of the sonarwhal GitHub organization. PRs are always welcome and appreciated!
Take a few moments to try the sonar scanner and the CLI, and let us know what you think at @narwhallnellie on Twitter or in the comments below!
– Antón Molleda, Senior Program Manager, Microsoft Edge
 

Documenting the Web together

Today, we’re excited to share some big news for developers around the world wide web: We’re committing our resources towards making MDN Web Docs the best place to go for web API reference. To kick things off, today we started redirecting over 7,700 MSDN pages to corresponding topics in the MDN web docs library powered by Mozilla.
In conjunction with similar commitments from Mozilla, Google, the W3C, and Samsung, we’re teaming up to make MDN Web Docs the best place for web developers to learn and share information about building for the open web.

MDN is a core part of Mozilla’s overarching mission: to ensure the Internet is a global public resource, open and accessible to all. We believe providing web developers the best possible information will enable them to deliver great web experiences that adhere to established standards and work across platforms and devices. We are excited to have Microsoft, Google, The W3C, and Samsung on board as we continue on our journey to make MDN the premiere resource for developers.
— Ali Spivak, Head of Developer Ecosystem at Mozilla
Representatives from each of these organizations will also be serving on the MDN Product Advisory Board, a committee dedicated to making MDN your definitive place for useful, unbiased, browser-agnostic documentation for current and emerging standards-based web technologies. The MDN Product Advisory Board is also looking for active individuals from the web community to serve on the board. If you’re interested, find more details on MDN web docs.
Web docs should just work for everyone
Redirecting our API reference library to MDN is the next step towards consolidating our compatibility info in the same place you probably already frequent for general web documentation. Earlier this year, we began the effort to backfill the MDN browser Compatibility tables with a column representing the Microsoft Edge browser.
Over 5000 MDN edits later, the entire web API surface of Microsoft Edge (as of the 10/2017 Windows 10 Fall Creators Update, Build 16299) is now documented on MDN, and will continue to be kept up-to-date with each new release of Windows and our EdgeHTML browser engine.
Example of a Browser compatibility table on MDN Web Docs
One of our guiding principles in developing Microsoft Edge is that end users should never have to worry about which sites work in which browsers. This philosophy—”the Web should just work for everyone“—led to our choice to target the “interoperable intersection” of web APIs in our browser engineering.
Just like with end users, we think it’s well overdue for developers to have a simpler view of web standards documentation. Developers shouldn’t have to chase down API documentation across standards bodies, browser vendors, and third parties—there should be a single, canonical source which is community-maintained and supported by all major vendors.
For these reasons we’re all-in on making MDN the home of web standards documentation. Not only is MDN a veritable encyclopedia and thriving community of all things web development, it’s also an institution in itself–a living monument to our collective history—as web developers and enthusiasts, web standards advocates, and browser engineers–of developing the web forward.
Documenting the web forward
MDN was founded over 10 years ago in 2005 as the Mozilla Developer Center and later become known as the Mozilla Developer Network. Just as the Mozilla Organization was founded out of Netscape, the Mozilla Developer Center grew from the original Netscape Navigator browser docs.
Similarly, the Internet Explorer Developer Center was first published online from the Microsoft Developer Network (MSDN) several years before that in the late 90s to help introduce and showcase Dynamic HTML (“DHTML”), Microsoft’s precursor to the modern DOM and CSS object model.
Microsoft Internet Explorer Developer Center on MSDN Online, circa 2000. Courtesy of the Internet Archive Wayback Machine
Fast forward to the modern web platform of today. The competing Netscape and Internet Explorer browsers from the bygone era of the early web are now subjects of tech archaeology, not site compatibility testing. From the final releases of IE culminating with the birth of Microsoft Edge, we replaced earlier Microsoft technologies with emerging industry standards–the modern DOM and ECMAScript standards for DHTML and VBScript, HTML5 for ActiveX, a common browser extension model for Browser Helper Objects (“BHOs”).
Through all this change, MDN has grown up alongside the web, and today has over 34,500 documents, 6 million monthly users and 20,500 contributors. From its initial Netscape product docs, the breadth and depth of MDN’s content has radically expanded to encompass the state of the art of modern web development—so much so that recently the site was restructured and rebranded to reflect MDN’s commitment to being a browser-neutral community resource. We are excited to join Mozilla, Google, The W3C, and Samsung in making MDN our home for web standards documentation and dedicated to helping it grow even further to meet your needs.
We will continue to maintain Microsoft- and Windows-focused documentation on Microsoft Docs (docs.microsoft.com/microsoft-edge), including Windows-specific test guidance, information on the Edge DevTools, and upcoming details about Progressive Web Apps in the Windows Store. And you’ll still find the latest Microsoft Edge status, changelogs, and news at our Microsoft Edge Developer site (dev.microsoftedge.com).
Please join us in supporting and contributing to MDN web docs! We’re all building this Web together; let’s document our hard work!
— Erika Doyle Navara, Senior Dev Writer

What’s New in Microsoft Edge in the Windows 10 Fall Creators Update

Today, we’re beginning to roll out the Windows 10 Fall Creators Update to Windows 10 customers around the world. This release upgrades Microsoft Edge to EdgeHTML 16, the best version of Microsoft Edge yet. The Fall Creators Update also includes new enhancements like improved favorites management and pinned sites, new developer APIs like CSS Grid Layout and WebVR 1.1, and better-than-ever reliability and performance.
To get started with EdgeHTML 16, simply update your devices to the Windows 10 Fall Creators Update today. Developers on other platforms can get started testing with free remote testing via BrowserStack today. In this post, we’ll walk through some of what’s new in Microsoft Edge for Windows 10 customers and developers alike.
Stay productive and organized with new features
The Fall Creators Update introduces a set of new features to make you more productive as you browse and read web pages, PDFs, and books. We’re also previewing new features to let you browse on your phone in the new Microsoft Edge preview apps for iOS and Android, with Continue on PC functionality. You can learn more about everything that’s new by selecting the “…” menu in the top-right corner of Microsoft Edge and selecting “What’s new and tips.”
A refreshed look inspired by the Fluent Design System
In the Fall Creators Update, Microsoft Edge gets a subtle makeover inspired by the Fluent Design System.
A subtle use of Acrylic material provides depth and transparency to the tab bar and other controls, and we’ve improved button animations to feel more responsive and delightful.
Annotate your e-books and PDFs
When you’re reading an e-book or PDF, you now have a whole lot of new options to personalize your books.

You can add highlights in four colors, underline, add comments or copy text. You also have the ability Ask Cortana to find more information about the content you are reading without leaving the reading experience. To get started, simply select some text and choose one of the annotation options from the menu that pops up!
Or, if you’re reading a PDF, you can select the “Add notes” button next to the address bar to mark the PDF up with Windows Ink.

This feature lets you take notes with a pen or highlighter right on the page – perfect for marking up a draft, signing a document, or filling out a form!
Pin your favorite websites to the taskbar
Pinned Sites, a top-requested feature from our Windows Insider community, are now available in Microsoft Edge! You can now pin a website to the Windows taskbar for instant access in the future. The site will be saved with its icon so it’s just a click away.

To pin a site, go to More … > Pin this page to the taskbar and the site will be pinned for you to come back to again and again.
Hear the web read out loud
Microsoft Edge can now read web pages, e-books, and other documents out loud to make reading accessible to more people. To hear an e-book or PDF out loud, click or tap anywhere on the page and select the “Read aloud” button from the top-right corner.

For sites, right click where you want to start reading and select “Read aloud.” You can adjust the playback speed, pause, skip between paragraphs, or even change the voice from the Voice Settings menu at the top of the page.
Edit URLs for favorites
By popular demand, we’ve added the ability to edit the address for individual favorites in the Favorites Hub or on the Favorites bar.

To do this, simply right-click or press and hold a favorite and select “Edit URL.”
See and manage website permissions
New features like web notifications and location services mean more sites may ask for your permission to access your location, webcam, or to send notifications, among other things. To help make it easier to keep track of what permissions you’ve granted, we’ve added a new “Show site information” pane for every website you visit.

To see the permissions you’ve granted for any site you visit, simply click the icon to the left of the URL bar (either a lock icon or an “i” icon, depending on the site’s security configuration).
Or, to see and manage all the permissions you’ve set, select More … > Settings > View advanced settings > Manage under Website Permissions.
Browse in full screen
Another popular request from our Windows Insiders was to introduce a true full screen browsing experience to Microsoft Edge.

To browse in full screen mode, select the More … menu and click the “Full screen” arrows icon, or press “F11” on your keyboard. Full screen mode hides things like the address bar and other items from view so you can focus on your content.
To exit full screen mode, move your mouse near top of the screen or swipe down with your finger and select the “restore” icon in the top-right, or press “F11” again.
Browse on your phone and continue on your PC
The Fall Creators Update adds support for a new feature currently in preview on iOS and Android Devices, which allows you to start from a website on your phone and send it to your Windows 10 PC.

This feature requires the preview of Microsoft Edge for iOS or Android. Learn how to install the preview on your phone here.
New features for web developers
The Windows 10 Fall Creators Update upgrades Microsoft Edge and the Windows web platform to EdgeHTML 16, with major new features for web apps, modern layouts, payments, and more.
New CSS features: Grid Layout, object-fit, and object-position
Microsoft Edge now supports the unprefixed implementation of CSS Grid Layout. Grid Layout defines a two-dimensional grid-based layout system which enables more layout fluidity than possible with positioning using floats or scripts. The example below uses CSS Grid Layout to create the structure for a basic web page.

EdgeHTML 16 also introduces support for the CSS properties object-fit and object-position. These properties control the position and size of replaced content within the content box.
Improvements to the Microsoft Edge DevTools
EdgeHTML 16 marks the beginning of a major renewed investment in our DevTools, beginning with a new refactoring effort for improved robustness and performance.

We’ve also introduced a number of new features to the DevTools, including the ability to view ancestor event listeners, set DOM mutation breakpoints, view CSS “at” (@) rules on the Styles pane, and more – along with major improvements to the Console and Debugger and early support for debugging Progressive Web Apps.
We’ll be sharing more details on what’s new in F12 in separate posts coming soon – in the mean time, you can see everything that’s new in the Microsoft Edge F12 DevTools page on the Microsoft Edge Dev Guide.
Payment Request API
The Payment Request API is an open, cross-browser standard that enables browsers to act as an intermediary between merchants, consumers, and payment methods (e.g. credit cards) that consumers have stored in the cloud. The API in EdgeHTML 16 has been updated to match the latest W3C Payment Request API specification. This includes:
Support for the canMakePayment() method
Support for the requestId property
Support for the id property
The default value for the complete() method’s result parameter changed from ” ” to “unknown”
Service Worker preview
Service Workers are event-driven scripts that run in the background of a web page. Service workers enable functionality previously only available with native apps like intercepting and handling requests from the network, managing and handling background sync, local storage, and push notifications.
Support for service workers is still in development, but you can test out your Progressive Web App in Microsoft Edge with our experimental service worker support by enabling the service worker feature in about:flags.
Motion Controllers in WebVR
WebVR for Microsoft Edge has added support for motion controllers. These controllers have a precise position in space, allowing for fine grained interaction with digital objects in virtual reality.

The release of the Windows 10 Fall Creators Update also marks the beginning of the era of Windows Mixed Reality, with the first wave of consumer Windows Mixed Reality headsets coming to market to enable immersive, low-cost experience with WebVR in Microsoft Edge.
In anticipation of this upcoming release, we’re excited to announce (with big thanks to the community and contributors involved) that the popular WebVR frameworks A-Frame, BabylonJS, ReactVR and three.js have now added support for the Windows Mixed Reality platform to their current and upcoming releases.

Version
Immersive View
WebGL context switching
Motion Controllers

master


0.7.0


R88*


2.0.0



You can learn more about getting started with WebVR and Windows Mixed reality in our post on the Microsoft Edge Dev Blog: Bringing WebVR to everyone with the Windows 10 Fall Creators Update.
… and more!
There’s too much in EdgeHTML 16 for one blog post; fortunately, you can find our full documentation, including a list of all the new APIs in EdgeHTML, over at the Microsoft Edge Dev Guide. Or, see what’s new in a given preview build at the Microsoft Edge Changelog.
If you’d like to learn more about a given topic, check out our recorded sessions from Microsoft Edge Web Summit 2017, where we shared more about our plans for the future of Microsoft Edge and gave a detailed look at what’s shipping today.
Test for free with BrowserStack or free virtual machines
The Windows 10 Fall Creators Update is rolling out to Windows 10 customers starting today – you can learn how to get the update on your PC here.
In case you don’t have a Windows 10 PC, we’ve partnered with BrowserStack to offer remote testing via a streaming instance of Microsoft Edge. Just set up a free account on BrowserStack for unlimited cloud testing, or download a free virtual machine from Microsoft Edge Dev, to get started testing EdgeHTML 16 today.
As always, we’re passionate about building in the open, and encourage you to review our open platform roadmap and provide feedback on features that matter to you. We’re always listening here in the comments, or @MSEdgeDev on Twitter. We can’t wait for you to try it out and let us know what you think!
— Kyle Pflug, Senior Program Manager, Microsoft Edge
— Libby McCormick, Dev Writer, Microsoft Edge

Bringing WebVR to everyone with the Windows 10 Fall Creators Update

Last April, we introduced the WebVR 1.1 API in Microsoft Edge as part of the Windows Creators Update, providing a foundation for developers to create immersive virtual reality experiences with Windows Mixed Reality developer kits. We have been hard at work building on this foundation to provide an end-to-end mixed reality experience with Microsoft Edge, WebVR, and Windows Mixed Reality, in line with our goal to democratize virtual reality this holiday.
On October 17th, EdgeHTML 16 will be released with Windows 10 Fall Creators Update, and the era of Windows Mixed Reality begins as headsets and motion controllers become widely available, enabling low-cost, immersive experiences with WebVR in Microsoft Edge.
In anticipation of this upcoming release, we’re excited to announce (with big thanks to the community and contributors involved) that the popular WebVR frameworks A-Frame, BabylonJS, ReactVR and three.js have now added support for the Windows Mixed Reality platform to their current and upcoming releases.

Version
Immersive View
WebGL context switching
Motion Controllers

master


0.7.0


R88*


2.0.0



* Upcoming release
In EdgeHTML 16, we’ve made a few updates to our WebVR 1.1 implementation that you should be aware of, starting with added support for Windows Mixed Reality motion controllers.
New support for motion controllers
Developers now have the tools to create fully interactive, immersive experiences on the web with our new support for Windows Mixed Reality motion controllers.

When a site is presenting to a headset, connected motion controllers will be available via the Gamepad API.
Adding support to the browser is only half of the story. We have been working with 3rd party middleware libraries to make sure that integrating support for motion controllers into your experience is as seamless a process as possible.
Current releases of both BabylonJS and A-Frame have full support for Windows Mixed Reality headsets and motion controllers.
Controller support includes detection of connected motion controllers, rendering accurate representations of the controllers into the scene, mapping button presses to actions and casting pointing rays into the scene for point-and-commit interactions. For added realism, the controller models animate the buttons and thumbsticks as the devices are manipulated:

Image: Hotel Room, Reno, Nevada / Bob Dass / Creative Commons 2.0
Added support for more Windows Mixed Reality PCs
Windows Mixed Reality supports a wide range of desktop and laptop hardware, with many graphics card configurations. Microsoft Edge has extended support for running WebVR experiences on this broad range of hardware – including machines with multiple graphics cards.
To leverage this support as a WebVR application developer, make sure that you are using the most up to date version of BabylonJS, A-Frame (0.7.0), three.js (r87), ReactVR (2.0.0).
If you are using WebGL directly rather than through one of these libraries, you’ll need to handle the WebGL Context Lost and Context Restored events to take advantage of this wider range of hardware.
The first immersive experience that lets you enjoy the entire Web
Microsoft Edge is now the first stable browser to ship comprehensive support for Virtual Reality.  From within your headset you can view traditional 2D websites, manage your favorites, create new tabs (including InPrivate tabs), and seamlessly transition into WebVR experiences.  And when browsing with Microsoft Edge on the Desktop, you’re still only one click away from launching WebVR content directly into your headset.
Because Microsoft Edge is built on the Universal Windows Platform, it can be used alongside the thousands of other apps supported by Windows Mixed Reality out of the box.

When you encounter a WebVR experience in Microsoft Edge within Mixed Reality, you can seamlessly transition from a 2D page to an immersive experience and back again without ever switching apps or leaving your headset.
Start developing today!
Our updated WebVR implementation is coming in EdgeHTML 16 with the Windows 10 Fall Creators Update, which will be released alongside new Windows Mixed Reality headsets and motion controllers on October 17th. Developers can get started building for WebVR today (no headset required!) via the Windows Insider Program, using the built-in Mixed Reality Simulator. Or, if you have an Acer or HP developer kit, you can try out Mixed Reality today!
You can learn more about the WebVR API with our documentation online, where you’ll find everything you need to get started, including a checklist of things to consider when creating a WebVR experience.
More Information
Finally, check out the talk that Nell Waliczek and Lewis Weaver recently gave at the Microsoft Edge Web Summit for an overview of WebVR, a deep dive into how to use the APIs, and some more good practices and resources:

We can’t wait to see what you build!
Lewis Weaver, Program Manager, WebVR
Nell Waliczek, Principal Software Engineering Lead, WebVR