Category Archives: New Platform Features

Auto Added by WPeMatico

Enhancing automated testing in Microsoft Edge with new WebDriver capabilities, W3C protocol support, and automatic updates – Microsoft Edge Dev Blog

Just last week, the WebDriver specification officially became a W3C Recommendation, defining a standard way for web developers and browser engineers to automate the browser. This is a major step forward for web site and web app testing, as well as cross-browser interoperability initiatives like web-platform-tests.Over the past few months we’ve been working to implement the updated W3C dialect for WebDriver in Microsoft Edge—a generational improvement to automated testing on the web. Today’s Windows Insider Preview release (17692) includes our updated implementation, as well as making it a Feature on Demand, so it’s easier than ever to get started.

WebDriver needs to match the version of Microsoft Edge you’re testing against, which has historically required manually matching a standalone download of WebDriver to the appropriate version of Windows on your device.
Beginning with today’s preview release, we’ve made WebDriver a Windows Feature on Demand (FoD), which ensures that it’s always up to date automatically, and enables some new ways to get Microsoft WebDriver.
The simplest way to get started is simply to enable Developer Mode. Simply open the Settings app and go to “Update & Security,” “For developers,” and select “Developer Mode.” The appropriate version of WebDriver will be automatically installed.
You can also install a standalone version of WebDriver in one of two ways:
Search “Manage optional features” from Start, then select “Add a Feature,” “WebDriver.”
Install via DISM by running the following command in an elevated command prompt: DISM.exe /Online /Add-Capability /CapabilityName:Microsoft.WebDriver~~~~
This also means that we will no longer be providing standalone downloads for Microsoft WebDriver going forward, however we will keep previous releases (RS4 and down level) available on our download page.

Actions API and new commands
The Actions API allows for low level input into the browser via action sequences, allowing developers to send multiple streams of input to test complex scenarios. Our implementation currently supports both mouse and keyboard input.
We’ve also added support for new commands including Get Timeouts, Get Window Rect, Set Window Rect and Get Element Property.
Improved interoperability
We’ve also implemented new logic for a number of commands, in order to improve interoperability and reduce test flakiness when running in Microsoft Edge:
Supporting CSS pixels for Set Window Rect, so that we scale properly for high-DPI devices when resizing
Adding calculations for in-view center point to impact what is/isn’t clickable and requires scrolling
Adding proper support for implicit wait to commands that were missing it
Using the Selenium implementation for Get Element Text
Testing PWAs and WebViews
These updates also apply to automated testing of PWAs and WebViews. So if you’ve been using WebDriver to test your web app you should now be able to enjoy these new benefits and bug fixes. We’ve also enabled WebDriver support for out of process WebViews.

As we move forward, we are working our way through the WebDriver web platform tests, fixing failures, and making sure our implementation is up to spec. As of our latest run we’re now passing 783 web platform tests out of 951. We’re tracking most of the  remaining failures being as interoperability bugs or as missing features, and look forward to continuing to close the gap in future releases.
This is the most significant update since we first brought automated testing to Microsoft Edge with WebDriver. With these changes, it’s easier than ever to build interoperable web sites through cross-browser testing.
We encourage you to get started with the implementation in Windows Insider Preview build 17692 or higher, and share your feedback on Twitter or in the Feedback Hub app on Windows. Let us know what you think!
– Clay Martin, Program Manager, Microsoft Edge

Updated June 14, 2018 10:12 am

New features for extensions in the Windows 10 April 2018 Update – Microsoft Edge Dev Blog

The Windows 10 April 2018 Update includes several incremental improvements to API support, functionality, and end-user discoverability for the extensions platform in Microsoft Edge. In this post, we’ll walk through the biggest improvements, and how you can get started enhancing your extensions with new features.Extensions can now be enabled for InPrivate browsing
In previous releases, extensions could not be enabled during an inPrivate browsing session. Beginning with this release, users can now choose to allow extensions to run during inPrivate browsing on a case-by-case basis – either when the extension is initially installed (by selecting the “Allow for inPrivate browsing” checkbox), or at any later time by visiting the Settings page for a given extension.
When running inPrivate, extensions can run in either split or span mode as specified by the WebExtensions API. In span mode (the default), the extension spans both inPrivate and non-private windows; windows and tabs from an inPrivate instance are indicated to the extension with an incognito property. In split mode, a separate instance of the extension is created for inPrivate and normal browsing, and the two copies are isolated (the inPrivate copy cannot see non-private windows, and the non-private copy cannot see inPrivate windows).
Extensions are now available when browsing inPrivate
Extensions in span mode can be debugged as with a normal extension. Extensions in split mode can be debugged separately for each instance, as the background script is separate for normal and InPrivate sessions.
The background script is separate for normal and inPrivate sessions.
Introducing the Notifications API for extensions
Extensions can now display interactive notifications , including basic messages, progress indicators, lists, and more. Developers can customize the appearance of these notifications by configuring the icon, text, buttons, and button icons.
Examples of progress, list, image and basic notifications
In the sample below, we’ll demonstrate the process to create a basic notification. The first step is to define the notification options:

Next, we’ll add event listeners for various user interactions:

The notification can now be invoked:

Notifications sent from an extension use the standard Windows notification service, appearing in Action Center until an action is taken. Users have full control over notifications, and can choose to suppress notifications originating from a specific extension using either the extension’s menu in Microsoft Edge or by acting on an individual notification in the Windows Action Center.
Users can suppress notifications for an extension from the Action Center or the extension settings
Extension developers can determine if notifications are enabled or disabled using the getPermissionLevel() method:

The event onPermissionLevelChanged will be raised if the user changes the notification permission:

Support for Tabs.reload()
Microsoft Edge extensions now support the tabs.reload() method in the tabs API class, allowing extensions to directly reload a specific tab using this method.

We are continuing to make enhancements to extensions platform for future releases. You can see a snapshot of our current roadmap on Microsoft Docs at Microsoft Edge Extension API roadmap. To get started building your extension for Microsoft Edge, check out Getting started with extensions.
We look forward to your feedback on these improvements! You can vote on the most important features for your extension development on the Microsoft Edge Developer UserVoice, or share your feedback in the comments below.
– Balaje Krishnan, Senior Program Manager, Microsoft Edge
Updated May 24, 2018 10:29 am

Get started with web push notifications

Microsoft Edge now supports web push notifications via the Push API, beginning with the Windows 10 April 2018 Update. Web push notifications allow you to build re-engaging experience by delivering timely, relevant notifications to users, even when your browser or web app is closed.
To help you get started with push messages and to demonstrate how they work across different browsers, we’re happy to introduce a new Microsoft Edge tutorial: Web Push Notifications.

Push notifications expand your reach to your users in a timely, power-efficient and dependable way. Users are re-engaged with customized and relevant content that will have them coming back for more.
Our tutorial is inspired by astrology, drawing parallels between the idea of messages from the zodiac being stored in the cloud and the way the architecture of push notifications is structured. Take a look to learn to set up your site for push notifications – both the front-end and the back-end.

As with all our demos, you can fork the tutorial itself on GitHub and even set it up locally for your own experimentation. To learn more about building with Push and Service Worker, check out Ali Alabbas’ session from Microsoft Build 2018: Building performant and re-engaging web apps with Service Worker.

To try out push notifications in Microsoft Edge, visit the tutorial and click on the button that says, “Initiate push”, accept the permission prompt, and immediately close the tab (or browser). You should get a notification within 5 seconds after clicking the button below. When you click the notification, it will take you right back to the web push tutorial, so you can continue learning about push messages.
Try it out and let us know what you think!
— Ali Alabbas, Program Manager, Microsoft Edge
— Stephanie Drescher, Program Manager, Microsoft Edge

Previewing support for same-site cookies in Microsoft Edge

Yesterday’s Windows Insider Preview build (build 17672) introduces support for the SameSite cookies standard in Microsoft Edge, ahead of a planned rollout in Microsoft Edge and Internet Explorer. Same-site cookies enable more protection for users against cross-site request forgery (CSRF) attacks.
Historically, sites such as that make “cross-origin” requests to other domains such as have generally caused the browser to send’s cookies as part of the request. Normally, the user benefits by being able to reuse some state (e.g., login state) across sites no matter from where that request originated. Unfortunately, this can be abused, as in CSRF attacks. Same-site cookies are a valuable addition to the defense in depth against CSRF attacks.
Sites can now set the SameSite attribute on cookies of their choosing via the Set-Cookie header or by using the document.cookie JavaScript property, thus preventing the default browser behavior of sending cookies in cross-site requests either in all cross-site requests (via the “strict” value) or only in some less sensitive requests (via the “lax” value).
More specifically, if the strict attribute is specified for when a same-site cookie is set, it will not be sent for any cross-site request, which includes clicking on links from external sites. Since the logged-in state is stored as a SameSite=Strict cookie, when a user clicks such a link it will initially appear as if the user is not logged in.
On the other hand, if the lax attribute is specified for when a same-site cookie is set, it will not be sent for cross-origin sub-resource requests such as images. However, the SameSite=Lax cookies will be sent when navigating from an external site, such as when a link is clicked.
This feature is backwards compatible―that is, browsers that don’t support same-site cookies will safely ignore the additional attribute and will simply use the cookie as a regular cookie.
We continuously work to improve our support of standards towards a more interoperable web. Although same-site cookies is not yet a finalized standard at the Internet Engineering Task Force (IETF), we believe the feature is stable and compelling enough to warrant an early implementation as the standardization process progresses.
To broaden the security benefits of this feature, we plan to service Microsoft Edge and Internet Explorer 11 on the Windows 10 Creators Update and newer to support same-site cookies as well, allowing sites to rely on same-site cookies as a defense against CSRF and other related cross-site timing and cross-site information-leakage attacks.
— Ali Alabbas, Program Manager, Microsoft Edge
— Gabriel Montenegro, Program Manager, Windows Networking
— Brent Mills, Program Manager, Internet Explorer

Bringing a modern WebView to your .NET WinForms and WPF Apps

One of the founding principles of Microsoft Edge is that it is evergreen, with automatic updates to Windows 10 continually refreshing both Microsoft Edge itself and web content throughout Windows 10. However, until recently, WinForms and WPF apps didn’t have access to the Microsoft Edge-powered WebView.
Earlier this week at Build 2018, Kevin Gallo previewed a new WebView for Windows 10, bringing the latest Microsoft Edge rendering engine to .NET WinForms and WPF apps for the first time in an upcoming release of Windows 10. In today’s post, we’ll provide more details on the benefits this brings to developers, and how you can preview this new capability in the Windows 10 April 2018 Update.
A WebView for the modern web
In our recent blog post on Progressive Web Apps (PWAs), we described the powerful experiences enabled by bringing a modern web platform to UWP, allowing developers to write HTML, CSS, and JS that seamlessly spans both browser as well as native app experiences.
As the growth of the web platform in general, and EdgeHTML in particular, have accelerated in recent releases, this has resulted in an increased performance and compatibility gap with the Trident-powered WebBrowser control, and many of our customers have asked for a way to incorporate the latest version of EdgeHTML into WinForms and WPF apps. We’re happy to address this feedback with a preview of the all-new EdgeHTML-powered WebView, bringing the last three years of performance, reliability, and security enhancements to WinForms and WPF apps for the first time.
Getting started
Working with the WebViewControl and WebView API may feel foreign to native .NET developers, so we’re building additional controls to simplify the experience and provide a more familiar environment. These controls wrap the WebViewControl to enable the control to feel more like a native .NET WinForms or WPF control, and provide a subset of the members from that class.
The WinForms and WPF controls are available today as a preview in the 3.0 release of the Windows Community Toolkit in the Microsoft.Toolkit.Win32.UI.Controls package. This means that upgrading from the Trident-powered WebBrowser control to the EdgeHTML-powered WebView in your WinForms or WPF app can be as easy as dragging in a new control from the toolbox.
Using WebView for WPF
Once you install the NuGet package, the WebView control appears in Windows Community Toolkit section of the Toolbox when the WPF Designer is open in Visual Studio or Blend.
Using the Designer
Drag the control from the Toolbox as you would any other control.
Programmatically adding WebView
The WPF version of the control is in the Microsoft.Toolkit.Win32.UI.Controls.WPF namespace.
Using WebView for WinForms
Using the Designer
First, we’ll need to add a WinForms control from a NuGet package to the Toolbox in Visual Studio. In a future release, Visual Studio will do this automatically.
First, open the Visual Studio Toolbox, then right-click anywhere in the toolbox, and select the Choose Items
In the .NET Framework Components tab of the Choose Toolbox Items dialog box, click the Browse button to locate the Toolkit.Win32.UI.Controls.dll in your NuGet package folder.
For help finding that folder, see Managing the global packages, cache, and temp folders.
After the DLL is added to the list of Toolbox controls, WebView is automatically
Close the Choose Toolbox Items dialog box.
The WebView control appears in the All Windows Forms section of the Toolbox when the Windows Forms Designer is open.
Programmatically adding WebView
After installing the NuGet package, you can add the WebView to your application like any other control. The WinForms version of the control is in the Microsoft.Toolkit.Win32.UI.Controls.WinForms namespace.
We’re just getting started!
The current WinForms and WPF WebView implementations are an early preview, with some limitations when compared to the UWP WebView control. For the complete list of these limitations, see Known Issues of the WebView control for Windows Forms and WPF applications on GitHub.
You can get started with WebView today using the Windows 10 April 2018 update or the latest Windows Insider Preview builds, where we’ll be adding more improvements as we continue towards a stable release. Please share your feedback or suggestions via @MSEdgeDev on Twitter, in the Windows Community Toolkit project on GitHub, or in the comments below.
Happy Coding!
– Kirupa Chinnathambi, Senior Program Manager, Microsoft Edge
– Richard Murillo, Principal Architect, Microsoft Edge

Bringing Screen Capture to Microsoft Edge with the Media Capture API

Beginning with the EdgeHTML 17, Microsoft Edge is the first browser to support Screen Capture via the Screen Capture API. Web developers can start building on this feature today by upgrading to the Windows 10 April 2018 Update, or using one of our free virtual machines.
Screen Capture uses the new getDisplayMedia API specified by the W3C Web Real-Time Communications Working Group The feature lets web pages capture output of a user’s display device, commonly used to broadcast a desktop for plugin-free virtual meetings or presentations. Using Media Capture, Microsoft Edge can capture all Windows applications–including including Win32 and Universal Windows Platform applications (UWP apps).
In this post, we’ll walk through how Screen Capture is implemented in Microsoft Edge, and what’s on our roadmap for future releases, as well as some best practices for developers looking to get started with this API today.
Getting started with the Screen Capture API
The getDisplayMedia() method is the heart of the Screen Capture API. The getDisplayMedia() call takes MediaStreamConstraints as an optional input argument.  Once the user grants permission, the getDisplayMedia() call will return a promise with a MediaStream object representing the user-selected capture device.
The MediaStream object will only have a MediaStreamTrack for the captured video stream; there is no MediaStreamTrack corresponding to a captured audio stream. The MediaStream object can be rendered on multiple rendering targets, for example, by setting it on the srcObject attribute of MediaElement (e.g. video tags).
While the operation of the getDisplayMedia API is superficially very similar to getUserMedia, there are some important differences. To ensure users are in control of any sensitive information which may be captured, getDisplayMedia does not allow the MediaStreamConstraints argument to influence the selection of sources. This is different from getUserMedia, which enables picking a specific capture device.
Our implementation of Screen Capture currently does not support the use of MediaStreamConstraints to influence MediaStreamTrack characteristics (such as framerate or resolution). The getSettings() method can’t be used to obtain the type of display surface that was captured, although information such as the width, height, aspect ratio and framerate of the capture can be obtained. Within the W3C Web Real-Time Communications Working Group there is ongoing discussion of how MediaStreamConstraints influences properties of the captured screen device, such as resolution and framerate, but consensus has not yet been reached.
User permissions
While screen capture functionality can enable a lot of exciting user and business scenarios, removing the need for additional third-party software, plugins, or manual user steps for scenarios such as conference calls and desktop screenshots, it also introduces security and privacy concerns. Explicit, opt-in user consent is a critical part of the feature.
While the W3C specification recommends some best practices, it also leaves each browser some flexibility in implementation. To balance security and privacy concerns and user experiences, our implementation requires the following:
An HTTPS origin is required for getDisplayMedia() to be called.
The user is prompted to allow or deny permission to allow screen capture when getDisplayMedia() is called.
While the user’s chosen permissions persist, the capture picker UI will come up for each getDisplayMedia() call. Permissions can be managed via the site permissions UI in Microsoft Edge (in Settings or via the site info panel in the URL bar).
If a webpage calls getDisplayMedia() from an iframe, we will manage the screen capture device permission separately based on its own URL. This provides protection to the user in cases where the iframe is from a different domain than its parent webpage.
As noted above, we do not permit MediaStreamConstraints to influence the selection of getDisplayMedia screen capture sources.
Sample scenarios using screen capture
Screen capture is an essential step in many scenarios, including real-time audio and video communications. Below we walk through a simple scenario introducing you to how to use the Screen Capture functionality.
Capture photo from a screen capture device
Let’s assume we have a video tag on the page and it is set to autoplay.  Prior to calling navigator.getDisplayMedia, we set up constraints and create a handleSuccess function to wire the screen capture stream to the video tag as well as a handleError function to log an error to the console if one occurs.
When navigator.getDisplayMedia is called, the picker UI comes up and the user can select whether to share a window or a display.
The Picker UI allows the user to select whether to share the entire display, or a particular window.
While being captured, the chosen application or display will have a yellow border draw around it which is not included in the capture frame. Application windows being captured will return black frames while minimized (though they will still be enumerated in the picker); if the window is restored, rendering will resume.
If an application window includes a privacy flag (setDisplayAffinity or isScreenCaptureEnabled) the application is not enumerated in the picker. Application windows being captured will not include overlapping content, which is an improvement on snapshotting the entire display and cropping to window location.
What’s next for Screen Capture
Currently the MediaStream produced by getDisplayMedia can be consumed by the ORTC API in Microsoft Edge.  To optimize encoding in screen capture scenarios, the  degradationPreference encoding parameter is used.  For applications where video motion is limited (e.g. a slideshow presentation), degradationPreference should be set to “maintain-resolution” for best results. To limit the maximum framerate that can be sent over the wire, the maxFramerate encoding parameter can be used.
To use the MediaStream with the WebRTC 1.0 API in Microsoft Edge, we recommend the adapter.js library, as we work towards support for getDisplayMedia along with the WebRTC 1.0 object model in a future release.
You can get started with the Screen Capture API in Microsoft Edge today on EdgeHTML 17.17134 or higher, available in the Windows 10 April 2018 Update or through the free virtual machines on the Microsoft Edge Developer Site. Try it out and let us know what you think by reaching out to @MSEdgeDev on Twitter or submitting feedback at!
– Angelina Gambo, Senior Program Manager, Microsoft Edge
– Bernard Aboba, Principal Architect, Skype

What’s new in Microsoft Edge in the Windows 10 April 2018 Update

The next update to Microsoft Edge is now available with the Windows 10 April 2018 Update! This update includes EdgeHTML 17, the next major version of Microsoft Edge’s rendering engine, as well as new features and everyday improvements across the product.
You can get your hands on the April 2018 Update today by checking for updates on your Windows 10 device, or, if you don’t have one, by downloading a free virtual machine from the Microsoft Edge Developer Site. You can also test Microsoft Edge for free in BrowserStack, which offers instant cloud-based manual and automated testing from a Mac or PC. BrowserStack will be updated to include the final release of EdgeHTML 17 in the coming weeks.
In this post, we’ll highlight what’s new in Microsoft Edge for users, and the new capabilities for site developers in EdgeHTML 17.
Better browsing: What’s new in Microsoft Edge
In every release, it’s our goal to make the web sing on Windows by making Microsoft Edge the fastest, easiest, and most productive place for you to enjoy your favorite sites and web apps. Below, you’ll find the biggest new features for Microsoft Edge.
Mute tabs with a click
We hear feedback every day that it’s too hard to find where audio is coming from, especially with lots of tabs open. In the April 2018 Update, the hunt to mute videos is over! When you hear unwanted audio playing in the browser, just press This tab is playing media  on the tab to turn the audio on or off.
Mute tabs with a single click
Our goal is to put users in control of autoplay content on the Web, so we’re continuing to explore more features to intelligently restrict autoplay audio and video content in future releases.
Automatically fill forms and credit card details
Microsoft Edge can now remember your name, credit card details, and other info when you’re signed in with a Microsoft Account. With your permission, we’ll save your form entries and give you the option to complete forms automatically.

Better reading with annotations, grammar tools, and more
We’ve overhauled the reading and Books experiences in Microsoft Edge, bringing a new, consistent, more powerful experience across all your documents, whether they’re EPUB or PDF books, documents, or web pages in Reading View.
The new reading experience uses Fluent Design System elements like motion and Acrylic material to provide a fluid, delightful experience that keeps the focus on the page.
In EPUB books and the Reading View for websites, you can now use the new Grammar Tools button to enable new comprehension aids. Grammar Tools can break the words on the page into syllables, as well as highlight different parts of speech such as nouns, verbs, and adjectives.

You can now also save EPUB books—whether downloaded from the web or purchased from the Microsoft Store—add bookmarks, and manage them all at the Books tab in the Microsoft Edge ”Hub” menu. You’ll also find suggestions there based on your reading habits.
For a distraction-free reading experience, you can now take books, PDFs, and Reading view pages full-screen. To enable full screen reading, just click the double arrow icon on the reading bar or press F11 on your keyboard.
Clutter-free printing
When printing a web page, you can now save paper by only printing the content you need. Select the “Clutter-free printing” option to print webpages without pop-ups and other unnecessary clutter.
Improved support for touchpad gestures
Microsoft Edge now supports custom multi-touch gesture support on devices with a precision touchpad, such as modern Surface laptops. On supported sites like Bing Maps, you can now use pinch-to-zoom and two-finger panning gestures to navigate maps just like you would on a touch screen.
Offline web sites and push notifications
Microsoft Edge now supports new web standards that allow web pages to send push notifications to your Action Center, even when the browser is closed. In addition, certain web pages can now work offline and improve performance, by using locally cached data when the cache is up to date, or when your device has a poor connection. You can learn more about these features in our post Service Workers: Going beyond the page.
New features for Extensions
We’re adding new extensions for Microsoft Edge every day, allowing users to customize their browsing experience with their favorite ad blockers, password managers, and more. To make it easier to find the extensions you’re looking for, Microsoft Edge will now show a dynamic list of suggested extensions under the “Extensions” menu.
Improvements for everyone
That’s just scratching the surface of what’s new in Microsoft Edge – you can learn more about these features at Microsoft Edge Tips, and see a list of everything that’s new over at the Microsoft Edge Changelog.
In every release, we make changes based on your feedback. Once you’ve tried out Microsoft Edge in the April 2018 Update, we want to hear what you think! You can send feedback on these features and suggestions for future improvements by selecting “Send feedback” from the “…” menu in Microsoft Edge.
Better basics: Improved performance and power efficiency
Windows users spend more time in web content than in any other activity on Windows. The Microsoft Edge engine powers not only the browser, but also powers web content throughout Windows—including in Windows apps and throughout the Windows shell itself—so performance and power efficiency is a major area of focus for the Microsoft Edge team in every release.
In the April 2018 update, we’re introducing dozens of optimizations that improve real, day-to-day performance and efficiency in every area of the product.
Making the browser more responsive
Input responsiveness is key to making the browser feel fast even when interacting with heavy websites or running on a busy system. In the April 2018 update, we’ve made improvements to make Microsoft Edge much more responsive on busy systems—such as when lots of other apps or background tasks are running.
Users will notice this most dramatically when something outside the browser such as a game or other high-impact application is busy in the background, which previously could cause input (such as typing) to be delayed, sometimes substantially dramatically.
Thanks to improved thread management in the April 2018 Update, this input will be more aggressively prioritized above background tasks, so Microsoft Edge will be much more responsive even when resources are limited.
We’ve also made improvements to responsiveness on busy pages. When the browser is busy with work that blocks user interactivity, we’ll more aggressively interrupt those tasks to put the user’s input first.
Better efficiency for an internet of GIFs
Regardless of how you pronounce them, GIFs are here to stay! In this update, we’ve dramatically reduced the power efficiency impact of rendering animated GIFs, especially on pages with lots of GIFs. Around 20 percent of pages loaded in Microsoft Edge include at least one GIF, so these improvements add up to even more battery life for Microsoft Edge compared to previous versions and to other browsers.
We’ve also made overall improvements to how we load images—on webpages with lots of images, we’ll now load the page noticeably faster by laying out page content without waiting to download the image in most cases.
Using resources more intelligently
Many web pages use resources continuously even when the user is not interacting or when the window is not in the foreground. When a tab is open for long periods of time, especially when lots of tabs are open, this impact adds up to reduced performance and battery life.
To prioritize the user experience, Microsoft Edge now intelligently suspends background tabs after the user has not interacted with them for a while, caching the content and suspending all CPU activity on that tab. This means improved performance and reduced power usage over time, with a minimal impact to the user experience. Tabs are then rapidly rehydrated when the user clicks on them. Our data from Windows Insiders previewing this feature shows that most suspended tabs are restored in less than half a second.
We’re also making foreground tabs more efficient. If a page is focused, but the user is not interacting with it (for example, scrolling or clicking links), Microsoft Edge will reduce the frame-rate of the tab to conserve power. This doesn’t impact video or 3D content on the page, and the browser will restore the full 60fps frame-rate as soon as the user interacts again.
New developer features for more engaging sites and web apps
The April 2018 Update brings with it EdgeHTML 17, our fifth major version of the Microsoft Edge rendering engine. This release brings powerful new developer capabilities for web sites and web apps, including the foundation for full-featured Progressive Web Apps on Windows.
A foundation for Progressive Web Apps
Starting in EdgeHTML 17, Service Workers and push notifications are enabled by default; you can learn more about these features in the blog 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 progressive Web Apps (PWAs) on Windows 10.

PWAs are simply web apps that are progressively enhanced with native app-like features on supporting platforms and browser engines, such as installation / home screen launch, offline support, and push notifications. On Windows 10 with the Microsoft Edge (EdgeHTML) engine, PWAs enjoy the added advantage of running independently of the browser window as Universal Windows Platform apps.
Beyond PWAs, Service Workers and the Cache API allow developers the ability to intercept network requests and respond from the cache. A website need not even been a full-blow web app to take advantage of the Service Worker cache for fine-tined page load performance and reliability, as well as the ability to provide an offline experience during periods of no internet or poor-quality connection.
Head over to our Progressive Web Apps docs to learn more about Service Workers and details about PWAs on Windows 10.
Expressive, performant typography with Variable Fonts
Full support for Variable Fonts, including CSS font-variation-settings and font-optical-sizing is available in EdgeHTML 17. Variable fonts enable developers to achieve the look of seemingly different typefaces with a single font by adjusting various axes – reducing the need for multiple font files and bettering performance.

Learn more about variable fonts and how to use them on your site at our Test Drive guide: Variable Fonts: An exploration of expressive, performant typography.
More powerful extensions
Microsoft Edge now supports the Notification API which displays notifications from extensions. Extension developers can now create different types of notifications (basic, list, image etc.) which support full user interaction. The notifications are also automatically logged into the Action Center. EdgeHTML 17 now also supports the Tabs.reload() method as part of the standard tabs API class.
Visit the notifications sample on how to use this API in your extension.
Improved accessibility via ARIA 1.1 Roles, States, and Events
EdgeHTML 17 now includes support for roles, states, and properties from the Accessible Rich Internet Applications (WAI-ARIA) 1.1 specification, including banner, complementary, aria-haspopup, aria-placeholder, and many more. Check out the Accessibility docs for more information about accessibility in Microsoft Edge.
Customizable multi-touch scrolling and gestures with Pointer Events
On devices with a Precision Touch Pad (PTP), Microsoft Edge will now fire Pointer Events with a pointerType of “touch” in response to PTP gestures.

This allows site developers to provide a customized multi-touch experience on modern Windows devices, including pinch-to-zoom and two-finger panning gestures, while preserving the highly optimized scrolling behaviors that users have come to expect from Precision Touch Pad devices.
CSS transforms on SVG elements
EdgeHTML 17 now supports CSS transforms on SVG elements and presentation attributes. This allows SVG elements to be visually manipulated, including rotating, scaling, moving, skewing, or translating.
More powerful developer tools
The tools have been updated with a number of major features, including basic support for remote debugging (via our new DevTools Protocol), PWA debugging features, IndexedDB cache management, vertical docking and more! We also continued the overall refactoring effort started last release as part of ongoing investments in performance and reliability.
You can learn more about what’s new in the Microsoft Edge DevTools at DevTools in the latest Windows 10 update (EdgeHTML 17).
Plugin-free screen sharing via the Media Capture API
Microsoft Edge now supports Screen Capture in RTC via the Media Capture API. This feature lets web pages capture output of a user’s display device, commonly used to broadcast a desktop for plugin-free virtual meetings or presentations. We’ll be sharing more about the Media Capture API in Microsoft Edge in an upcoming blog post.
Improved Web Security
EdgeHTML 17 introduces support for Subresource Integrity (SRI). Subresource Integrity is a security feature that allows browsers to verify that fetched resources (e.g. images, scripts, fonts, etc.) are delivered without unexpected manipulation.
Also new in EdgeHTML 17, the Upgrade-Insecure-Requests request header allows browsers to request a secure browsing experience. This header tells the server that the browser supports upgrading any insecure requests and the user should be redirected to a secure version of the site if available.
And lots more!
There’s too much EdgeHTML 17 for one blog post—you can see the full list of everything that’s new, including the full list of new APIs exposed in the DOM, over at the Microsoft Edge Dev Guide for EdgeHTML 17.
Get started testing EdgeHTML 17 today
You can get the April 2018 Update in a couple different ways. If you have automatic updates enabled, the update will be delivered to you when it’s ready for your device, starting today. Developers and advanced users who would like to get the update today can visit this blog post to learn how.
You can get started testing EdgeHTML 17 today on any device using free virtual machines from Microsoft Edge Dev. We’ve also partnered with BrowserStack to offer unlimited remote manual and automated testing in Microsoft Edge—BrowserStack will be adding EdgeHTML 17 in the coming weeks.
As with every release, we want to build our web platform in the open. We’ve updated our open platform roadmap at to reflect EdgeHTML 17, and encourage you to review and provide feedback on the features that matter to you.
You can reach our team directly via @MSEdgeDev on Twitter, or via the Feedback Hub app on Windows. We look forward to hearing what you think!
— Kyle Pflug, Senior Program Manager, Microsoft Edge
— Libby McCormick, Dev Writer, Microsoft Edge

Bringing expressive, performant typography to Microsoft Edge with Variable Fonts

For years, rich typography has been the envy of many web designers, who long for the typographic variety, texture, and precision available in print media. Now, with the recent innovations of OpenType Variable Fonts―pioneered in collaboration between Microsoft, Adobe, Apple, Google, and others―and new standards allowing for developers to control font variations in CSS, things are about to change.
In this example from our Variable Fonts demo, the Decovar font is animated along an astounding 15 axes using variable fonts.
Full support for Variable Fonts (including CSS font-variation-settings and font-optical-sizing) is coming to Microsoft Edge starting with EdgeHTML 17, available to preview in Windows Insider Preview builds as of Build 17120. To demonstrate how variable fonts enable expressive, performant experiences, we’ve built a new immersive developer guide on Test Drive: Variable Fonts.
Join us on an expedition to learn about Variable Fonts, and how to use them on your site.
Join us on an expedition to learn about what variable fonts provide web developers and designers, and how to use them on your site. For the best experience, visit the Test Drive in a modern browser that supports font-variation-settings and font-optical-sizing, such as Microsoft Edge on Windows Insider Preview build 17120 or higher.
― Greg, Melanie, and Francois

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:
— 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.
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.
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) {

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

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