Category Archives: Announcements

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~~~~0.0.1.0
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 example.com that make “cross-origin” requests to other domains such as microsoft.com have generally caused the browser to send microsoft.com’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.
https://gist.github.com/kypflug/907e03e236958cc2b0c01a29ce27c12b
https://gist.github.com/kypflug/87ef801f19c3af6d66aa39fee8092419
Programmatically adding WebView
The WPF version of the control is in the Microsoft.Toolkit.Win32.UI.Controls.WPF namespace.
https://gist.github.com/kypflug/43fb419dde0e12100f8d9861be932bdc
https://gist.github.com/kypflug/ff50b3d10de389c2cd559b4b073d86c0
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.
https://gist.github.com/kypflug/c43124825d1bc3a9622076b6e6dbb11e
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.
https://gist.github.com/kypflug/14e0738c80940bbb80babd626de7eef4
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

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 status.microsoftedge.com 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

Introducing the Microsoft Edge DevTools Preview app

Last fall at the Microsoft Edge Web Summit, we laid out our plans for rebooting the Microsoft Edge DevTools in response to your feedback.  Today we’re announcing the availability of the DevTools as a web app from the Microsoft Store. The new Microsoft Edge DevTools Preview app allows you to preview the very latest DevTools running side by side with the tools included in Microsoft Edge.
You can install the DevTools Preview app on Windows 10 Fall Creators Update or newer. Because the DevTools Preview app is based on the most recent Insider Preview version of the Microsoft Edge DevTools, this allows you to use the most recent updates to the Microsoft Edge DevTools without installing a full Insider release.
In addition, some new features will be exclusive to the app – such as debugging outside of the local browser, including web content in apps and remote debugging devices.
Debugging the web outside of the browser
When we think of the web, we largely think of browsers. But the web shows up on many more surfaces than just the browser in Windows: WebViews in apps, add-ins for Office, Cortana, Progressive Web Apps in the Microsoft Store, and many more places. The DevTools preview app gives you the ability to attach the tools to any instance of the EdgeHTML engine on Windows to debug.
The DevTools Preview app allows you to attach the Microsoft Edge DevTools to any local or remote EdgeHTML target.
Debugging remote devices
The web also runs on devices other than your dev machine. How would you debug the web on an Xbox, HoloLens, or an IoT device? One of the first features we’re previewing in the new DevTools app is remote debugging. By enabling Device Portal in the Settings app, you can now connect to that device over the network or via USB to debug remotely from the DevTools Preview app.

We’re previewing this with support for JS debugging of another instance of Microsoft Edge on another desktop device or VM. Over time, we’ll add support for the full set of DevTools against any EdgeHTML instance on any Windows 10 device. We’ll go into more detail on remote debugging in a future post.

Building a DevTools protocol for an ecosystem of tools
One of the biggest changes to the DevTools isn’t visible in a screenshot – the new Microsoft Edge DevTools Protocol. Previously, the Microsoft Edge DevTools worked via invasive native hooks into the EdgeHTML and Chakra engines.  This made it hard for other tools like VS, VS Code, Sonarwhal, and other open source tools in the ecosystem to support Microsoft Edge.
We started a conversation with other browsers last fall to incubate DevTools protocols at the W3C, with the goal of promoting interoperability between engines and allowing tools to support cross-browser debugging more easily.
The new DevTools app uses EDP to remotely debug Microsoft Edge today, and, eventually, all of our DevTools will use EDP. We’ll share more about EDP and our roadmap for additional tools in a future blog post.
The future of the Microsoft Edge DevTools
We’ve heard your feedback on the DevTools and we’re investing to make them great. Over the next several releases, we’ll evolve our tools based on your feedback. We encourage you to try out the DevTools Preview app, file feedback (just click the Smile icon in the DevTools), and reach out to us on Twitter with any comments!

We’ve got lots in store for the DevTools, including ongoing improvements in reliability and performance. With the Microsoft Edge DevTools Preview app, we can address your feedback faster and experiment with new ideas for the tools. We look forward to hearing what you think!
– Jacob Rossi, Principal PM Lead, Microsoft Edge DevTools

Introducing sonarwhal v1: The linting tool for the web

Just over one year ago, we started working on a best practices tool for the web called sonarwhal—a customizable, open-source linting tool, built for modern web developer workflows. Today, we are announcing the release of its first major version. With today’s launch, we’d like to talk you through a look back at how sonarwhal started, and the journey to v1 over the past few months.
It all started with feedback from web developers, partners, and from our own experiences building for the web. The web platform is becoming richer at a faster pace than ever before: we now have web experiences we couldn’t even imagine a few years back. Sites can work offline, push notifications (even when the user is not visiting the site), and even run code at native speeds with WebAssembly. On top of keeping up to date, developers also need to know about many other things like accessibility, security, performance, bundling, transpiling, etc.
Every day, we see sites that have a great architecture, built with the latest libraries and tools, but that don’t use the right cache policy for their static assets, or that don’t compress everything they should, or with common security flaws—and that’s just scratching the surface. The web is complex and it can be easy to miss something at any point during the development process.
Being a web developer can be overwhelming
What could we do to help web developers make their sites faster, more secure and accessible while at the same time making sure they remain interoperable cross browser? And that’s how all started. Picking the name was the easiest part: the team loves narwhals and they have one of the best echolocation beams in nature (or sonars) so it was an obvious choice.
We knew from the beginning that we wanted sonarwhal to be built by and for the web community. We didn’t want to indoctrinate our personal opinions into sonarwhal’s rules. We wanted sonarwhal to be backed by deep research, remain neutral, and allow contributions from any individual or company. Thus, we decided to make sonarwhal an open source project as part of the JS Foundation.
Since then, we’ve kept ourselves busy listening to your feedback and implementing many of the goals we had back then, while adding some new ones.
When creating a new rule, we follow the 80/20 principle:
80% of the time is research and 20% is coding
If there’s one thing we are most proud of, it’s the extensive research we do on each subject and how deep the rules go to check that everything is as it should be.
Just to give you some examples:
The http-compression rule will perform several requests for each resource with different headers and check the content to validate the server is actually respecting them. E.g.: When resources are requested uncompressed, does the server actually respect what was requested and serve them uncompressed? Is the server doing User-Agent sniffing instead of relying on the Accept-Encoding header of the request? Is the server compressing resources using Zopfli when requests are made advertising support for gzip compression?
The web manifest rules are also interesting. Does the web manifest point to an image? Does that image exist? Does the image meet the recommended resolution and file size? Does it have the right format to be used by any browser? Is the name of the web application short enough to be displayed on all platforms?
The web is full of lies (starting with the user-agent string). Just because a file ends with .png and has content-type: image/png doesn’t mean it’s a PNG. It could very well be a JPEG file, or something completely different. And the same goes for every downloaded resource. The content-type rule will look at the bytes of the resources and verify. the server is actually serving what it says it is, and where applicable, that is specifying the proper charset.
And the list goes on…
More than 30 rules in 6 categories (and counting!)
sonarwhal validates many different things: from accessibility and content types, to verifying your JavaScript libraries don’t have any known vulnerabilities and that you are using SRI to validate that no one has tampered with the code.
Some of the issues require developers to change their code, but others require tweaking to the server configurations. Changing the configurations might not be obvious, especially when targeting only certain resource types, or newer tools and techniques such as Brotli compression, which may not be as thoroughly documented. To make the developer experience easier, we’ve also added examples for Apache and IIS for the rules that require it.
Get started testing with our online scanner
sonarwhal runs on top of Node.js and is distributed via npm. But what happens if you want to check a site using your mobile phone? Or maybe your IT administrator doesn’t allow you to install any tool.
We needed a way to scale and make sonarwhal available anywhere with an internet connection.In November of last year we launched the online version. Since then, more than 160,000 URLs have been analyzed.
Each result page has its own permalink to allow you to go back to it later, or share it with anyone.The code for the online scanner is available on GitHub.
Scan results for https://example.com
Configure sonarwhal to your needs
We think tools should be helpful and should stay out of your way. We can tell you what we think is important, but at the end of the day, you are the one that best understands what you are building and what requirements you have.
We build sonarwhal with strong defaults, but with the flexibility to let you decide what rules are relevant to your project, what URLs should be ignored, what browser you want to use—essentially, we want everything to be configurable.
To make it easier to reuse configurations, you can now extend from one or more and tweak the properties you want.
For example, to use the configuration “web-recommended” you just have to:
npm install @sonarwhal/configuration-web-recommended
And tell your .sonarwhalrc file to extend from it:
{
  "extends": ["web-recommended"]
}
If you want to tweak it, you can do this:
{
  "extends": ["web-recommended"],
  "ignoredUrls": [{
    "domain": ".*.domain1.com/.*",
    "rules": ["*"]
  }],
  "rules": {
    "highest-available-document-mode: ["error", {
      "requireMetaTag": true
    }]
  }
}
The above snippet will use the defaults of “web-recommended”, ignore all resources that match the regular expression .*.domain1.com/.* and enforce the X-UA-Compatible meta tag instead of the header.
Without doubt, one of our favorite features is the adaptability of the rules. Depending on the browsers you want to support, some rules will adapt their feedback telling you the best approach for your specific case. We believe this is really important because not everybody gets to develop for the latest browser versions.
Easily extend sonarwhal with parsers to analyze files such as config files
Catching issues early in the development cycle is usually better than when the project is already shipped. To help with this we created the “local connector” that allows you to validate the files you are working with.
Building a website these days usually requires more than just writing HTML, JavaScript and CSS files. Developers use task managers, bundlers, transpilers, and compilers to generate their code. And each one of these needs to be configured, which in some cases is not easy. To tackle this problem, we came up with the concept of a parser. A parser understands a resource format and is capable of emitting information about it so rules can use it.
Parsers are a powerful concept. They allow sonarwhal to be expanded to support new scenarios we couldn’t imagine when we first started the project. In our ca se, we’ve started creating parsers for config files of the most popular tools used during the build process ( tsconfig.json, .babelrc, and webpack.config.js so far) and rules related to them:
By default TypeScript output is ES3 compatible, but maybe you don’t need to go all the way down and could be using ES5, ES6, etc. Using the information of your browserslist, we’ll tell you what target you should have in your tsconfig.json file.
 If you are using webpack, you should have “modules”: false in your .babelrc file to make sure you have better tree shaking and thus, less generated code.
These are just some relatively basic examples of what’s possible. Parsers allow you to create rules for virtually anything. For example, someone could create a parser that understands the metadata of image files and then a rule that checks that all the images have a valid “copyright status.”

sonarwhal analyzing configuration files for webpack and TypeScript
sonarwhal v1 is now available! Go get it while it’s fresh!
As you can see, we’ve been busy! After all that, we’re finally ready to announce the first major version of sonarwhal!
While this is a big milestone for us, it doesn’t mean we are going to remain idle. Indeed, now that GitHub organization projects can be public we’ve opened up ours so you can know the project’s priorities and what we are working on.
Some of the things we are more excited about are:
New rules: you can expect more rules around security, performance, PWA, and development very soon.
User actions for the browser: sometimes the page or scenario you need to test requires a bit of interaction to get to it. We are looking in ways to allow you to control the browser before a scan.
Custom configuration for the online scanner: the user should be capable of deciding everything, even when using the online scanner.
Notifications for the online scanner: some websites take longer than others to scan and is easy to forget you have something running on a background tab. We will add opt-in notifications to let you know when all the results are gathered.
sonarwhal is completely open source and community driven. Your feedback is really appreciated and helps us prioritize this list. And if you want to help developers all around the world, join us!
– Antón Molleda, Senior Program Manager, 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: 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