Category Archives: Tablet

Auto Added by WPeMatico

Improved JavaScript and WebAssembly performance in EdgeHTML 17 – Microsoft Edge Dev Blog

In every release of Microsoft Edge, we tune the Chakra JavaScript engine to provide better startup and execution performance, with a leaner memory footprint, and with improved responsiveness on real-world workloads.As EdgeHTML 17 rolls out to users as part of the Windows 10 April 2018 Update, we’d like to dive into some of the optimizations we’ve made in the Chakra engine in this release. These ongoing optimizations can have a dramatic impact on the day-to-day browsing experience for end users, resulting in faster sites and web apps.

(Re-)defer parsing for arrow functions and object literals methods
Over the past two Windows releases, we have been improving Chakra’s defer- and re-defer-parsing pipeline, allowing pages to start up faster while consuming less memory.
When given a script, Chakra performs a quick pre-parse check for syntax errors and defers the full parsing of any eligible function until it is first called. Re-deferring happens at a later point when Chakra heuristics determines that a fully parsed function is unlikely to be called again, in which case Chakra releases the memory holding the metadata generated during full parsing and leaves the function effectively in a state as if it had been just pre-parsed and deferred.
In EdgeHTML 17, we have continued to invest in this pipeline, and extended the list of functions eligible to include arrow functions and methods on object literals.

// parsing of these functions are deferred until called
// arrow functions
let addOne = (x) => {x + 1};

// object literal methods
let john = {
name: ‘John Doe’,
get name() {return this.name},
greet() {console.log(‘Hello’)}
};

The impact of this change can vary depending on the sites, but our early experiments show an average memory savings of 7% from this and a few other memory improvements in EdgeHTML 17.
RegExp bytecode refactoring
Many Microsoft Edge users rely on extensions for ad blocking and related scenarios to control their experience while browsing the internet. Some ad blocking extensions are built using a considerable amount of RegExp logic, which motivated us to make a series of bytecode refactoring changes for a leaner experience when running with these extensions enabled in Microsoft Edge.
Most significant among those changes is that Chakra condensed RegExp opcodes from 4 bytes to 1 and packed the structs. While the consequential unalignment might imply a performance slowdown, data collected on various scenarios indicates that it shouldn’t cause any visible performance regression.

As a result of this refactoring, Chakra was able to reduce RegExp bytecode memory in some popular extensions in this release by up to 10%, savings that should be reflected in other apps or sites using RegExp as well.

In addition to memory savings, EdgeHTML 17 brings improvements to several JavaScript built-ins, building on optimizations initially enabled in EdgeHTML 16.
Type sharing for Object.create
Object.create is used to support JavaScript inheritance and null is also often tossed in to create a lean and mean dictionary/property bag. Chakra has an internal type system, and each object in Chakra is represented with an internal dynamic type. Many Chakra optimizations depend on objects with similar layout sharing types with each other. For example, inline caches can store fast paths for various types encountered at call sites, and objects with the same or an equivalent type are able use the same fast path as the cached type.
Type sharing between {x: 1}, {x: 2, y: 2}, {x: 3, z: 3}
Previously, however, objects created by Object.create were associated with a special null type handler in Chakra that cannot share types with other objects, so these optimizations didn’t apply to objects created using Object.create.

let dict1 = Object.create(null);
let dict2 = Object.create(null);
let dict3 = Object.create(null);
dict1.x = 1;
dict2.x = 2; dict2.y = 2;
dict3.x = 3; dict3.z = 3;
// because Object.create cannot share types, o.x in 2nd/3rd calls are cache misses
foo(dict1);
foo(dict2);
foo(dict3);

Beginning with EdgeHTML 17, Object.create returns objects with sharable types. Object.create(Object) now has the normal Object type, and Object.create(null) uses a new null type handler sharable with other Object.create(null) and compatible objects. dict1, 2 and 3 in the above example can now share types and have equivalent types, hence o.x in foo(dict2) and foo(dict3) are cache hits. This change results in an up to 25% speedup in some AngularJS workloads.
Polymorphic inline cache for Object.assign
Object.assign is an ES2015 feature often used to merge or clone objects. In EdgeHTML 16, we improved bracket access (o[prop]) by deploying polymorphic inline cache, which is able to cache multiple types and their associated fast paths at a given call site. With EdgeHTML 17, we’ve propagated the same optimization to benefit Object.assign, which upon de-sugaring involves a sequence of o[prop] style calls.

// an illustrative Object.assign polyfill
function assign(target, …sources) {
sources.forEach(src => {
for (let prop in src) {
// multiple types and fast paths can now be cached at target/src call sites
// therefore improves Object.assign performance
target[prop] = src[prop]
}
});
return target;
}

This simple optimization results in a roughly 2% improvement in some React/Redux workflows, and we expect to further improve performance for this pattern in the next release.
JSON.parse/stringify optimizations
JSON.parse and JSON.stringify are your handy JSON serialization tools in JavaScript. Interestingly, it is also a fairly common pattern to make nested JSON.parse(JSON.stringify(obj)) calls to clone data objects.
Previously, Chakra implemented JSON.stringify by first scaning the object to be serialized, creating the necessary metadata, allocating a large enough buffer for the output string, creating intermediate sub-strings (for each quote, comma, key, value, etc.), and concatenating them together one-by-one.
The creation of intermediate strings caused a lot of redundancy in terms of both time and memory, so in EdgeHTML 17, Chakra skips creating those substrings altogether, and also delays filling up the output string from the metadata until it is actually needed. In the case of a JSON.parse(JSON.stringify(obj) call, the serialized object string is never actually created, and Chakra is able to construct the output object from the metadata generated during stringify.

let obj = {a: 1, b: 2};
let str = JSON.stringify(obj); // scans obj & create metadata
let objClone = JSON.parse(str); // re-construct obj from metadata, no string created
console.log(str); // JSON string creation is delayed until here

This change leads to JSON.stringify being roughly 40% faster in internal performance tests and roughly 70% faster for nested parse/stringify calls.
Rewriting Array Iterators in JavaScript and faster for…of
For…of performance on array also received a major boost in the EdgeHTML 17, and is up to 2.5x faster according to our testing. This speedup is achieved through rewriting the C++ Array Iterators implementation in JavaScript.
We had contemplated a feature rewrite in JS before―many JS optimizations didn’t apply to the C++ implementation, plus next() calls in C++ allocate objects on the heap, which is more expensive than JS stack allocation. The major challenge with a JS implementation is that de-sugared for…of involves a try/catch/finally block to handle cases of abrupt completion, which would have disabled most Chakra optimizations.
To work around those limitations, we made efforts to turn on JIT optimizations for functions with try/catch/finally in EdgeHTML 16, and later enabled inlining for the same as well. With those pre-requisites in place, we were able to rewrite for…of in JS, which runs much faster on non-excepting path.

Microsoft has been working closely with the WebAssembly Community Group (CG) to evolve this growing technology, and we shipped the WebAssembly MVP last year in EdgeHTML 16.
In EdgeHTML 17, WebAssembly (and asm.js) gets even faster with inlining support, which speeds up the workloads we’ve been tracking by about 4.5%. For ChakraCore embedders, WebAssembly is not only available on Windows, but also on Linux and MacOS, as we fixed calling convention issues.
A number of new and exciting WebAssembly features are being discussed within the CG, such as threads, reference types (for host interop), and ES modules integration. We look forward to continuing to collaborate with the CG to move this technology forward and to landing additional features as they progress on the standards track.

It’s always exciting to share more about performance enhancements to Chakra and Microsoft Edge. As always, we’ll continue to make enhancements in future releases, and your feedback is one of the key signals for us to decide what to do next.
We encourage you to dive in and try out these improvements for yourself, and be sure to share your thoughts with us on the ChakraCore repo, or via @MSEdgeDev and @ChakraCore on Twitter!
– Limin Zhu, Program Manager, Chakra
Updated June 19, 2018 12:36 pm

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

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

Introducing the Microsoft Edge DevTools Protocol

Today’s web developers face more challenges than ever before. New frameworks spring up left and right. The number of devices capable of running the web multiply by the day. And we strive as creators to enable an inclusive and trustworthy world where fundamentals like accessibility, privacy, performance, and security are key to success.
These challenges are an opportunity for builders and consumers of devtools, requiring our solutions to enable innovation and scale. We need to provide web developers and tool vendors targeting Microsoft Edge, including other Microsoft teams, flexibility in solving these tough problems.
With the Windows 10 April 2018 Update, we’re taking the first major step on our journey by introducing the Microsoft Edge DevTools Protocol, a set of REST and JSON-RPC/WebSocket APIs, which enable clients to diagnose and debug Microsoft Edge tabs. In addition, we’ve worked with our teammates from Visual Studio, Visual Studio Code, and the Microsoft Edge DevTools to integrate with, and validate the interoperability of, these new capabilities within those apps.
In this post, we’ll elaborate on why we’ve taken this approach and the exciting progress we’ve made so far. We’ll provide resources throughout to help you get started using these new technologies. At the end, we’ll look at our next steps and share the many ways you can provide feedback to help us shape the future of the Microsoft Edge DevTools Protocol.
Get started with the new local and remote debugging scenarios with the new documentation from aka.ms/edp-docs. Requries the Windows 10 April 2018 Update or the Microsoft Edge DevTools Preview app.
Rebooting the Microsoft Edge DevTools platform
A year ago, we set out to re-architect the Microsoft Edge DevTools platform with two general customer scenarios in mind: growing the number of devtools that work with Microsoft Edge, and expanding support for debugging Microsoft Edge on new device form factors.
Expanding opportunities in local and remote scenarios is a key motivator for the new architecture. More details on the components in the diagram above are provided below.
To tackle the realities described above and achieve both local and remote support, we came up with a short but impactful list of guiding principles:
Decouple the platform and client components and release the client separately to allow for faster UX improvements and innovations
Build the platform interfaces on standard technologies to foster a larger ecosystem of devtools with support for Microsoft Edge
Build the platform in a way which allows devtools running locally to target instances of Microsoft Edge on remote Windows devices
Align with other browser vendors to support ecosystem portability and efficiency
This work will span multiple releases, but we’ve already made some exciting progress. Let’s dive in.
Decoupling the Microsoft Edge DevTools platform and client
To enable us to deliver customer value more rapidly, we first looked to take the Microsoft Edge DevTools app and ship it separately from the Windows OS as a Store application.
But to ship via the Microsoft Store, we needed to build only on APIs which are publicly available to others. This lead to the creation of the new Edge DevTools Protocol (EDP). The protocol is comprised of two sets of APIs: REST and JSON-RPC via WebSocket. Through EDP, devtools can build experiences around invoking methods and subscribing to diagnostics and debugger events.
The REST APIs are primarily used to discover information about EDP such as the version, available targets, and the supported API surface. All response values are formatted as JSON objects.
https://gist.github.com/kypflug/969e26460cf5c90e66a0d5bbb0d6a456
The WebSocket APIs are used to issue debugger and diagnostics commands and subscribe to correlated events. The APIs are broken down into Domains, which further break down into Methods, Events, and Types. A simple example would be the Debugger.setBreakpointByUrl API. A client would issue a JSON-RPC command looking something like this to set a breakpoint based on a JS file URL and location:
https://gist.github.com/kypflug/24668bf10759b579c62022582fcc5937
By switching to this publicly documented APIs, we’ve begun the process of shipping a new Microsoft Edge DevTools Preview app which runs in part on EDP. You can read more about the new DevTools Preview app here.
Fostering an ecosystem of Microsoft Edge DevTools
By decoupling the client from the platform, we’ve started the work to achieve our second goal of enabling an ecosystem of devtools which support Microsoft Edge. HTTP and WebSocket are ubiquitous technologies in native and web development environments. This means clients written in many programming languages can integrate. We hope this vastly reduces the barriers to entry for those who want to build devtools for Microsoft Edge.
In addition to calling APIs, from within those tools developers will need a way to launch the Microsoft Edge DevTools Server. We’re excited to announce that in the April 2018 update, we’ve introduced a new command line parameter and Edge UX for doing that. Check out the capture below for a preview of that experience:
The animated gif above shows the new Microsoft Edge DevTools server command-line launching functionality added in the Windows 10 April 2018 update.
These command-line parameters for launching the Microsoft Edge DevTools Server, along with available HTTP and WebSocket APIs, can be found in the Microsoft Edge DevTools Protocol documentation. Combined, these capabilities enable developers to more easily build devtools which target Edge.
To prove the viability of this approach, we on the Web Platform team partnered with the Visual Studio and Visual Studio Code teams to support F5 debugging of JavaScript running in a Microsoft Edge tab. We look forward to sharing more on that front soon!
Supporting remote debugging
In addition to wanting to foster a community of devtools which target Microsoft Edge, we want to enable those tools to target Microsoft Edge running on a remote Windows device. Though this specific scenario is not yet supported, it shows our long-term thinking:
Imagine you’re a HoloLens developer working with WebVR. Trying to debug your web app in Microsoft Edge on the HoloLens would likely be a time-consuming activity. Without a mouse and keyboard, navigating of devtools would be a cumbersome experience. Much better would be to run devtools on your local dev machine and remotely target Microsoft Edge instances running directly on the HoloLens.
To accomplish that, we built a plugin for the Windows Device Portal (WDP) which hosts the same Microsoft Edge DevTools Server that runs locally when launched via the command-line utility explained above. When you enable WDP in the Windows For developer settings, this will automatically install and activate the EDP plugin.
With your device in Developer mode and the Windows Device Portal turned on, the EDP plugin is automatically installed and HTTP and WebSocket servers started.
Using the Remote tab in the new Microsoft Edge DevTools preview app, you can connect to a remote device, view its targets, and connect to and debug them. You can read more about that here and here.
Note: At this point we support remote devices (and virtual machines) running the Windows 10 April 2018 Update or higher on PCs.
Aligning with the devtools protocol community
When we set out to build the devtools protocol for Microsoft Edge, we had a choice: build something which aligns with industry precedents or create our own approach tailored for our browser. The choice was obvious to us so we opted to align with the Chrome DevTools Protocol (CDP).
In the early winter of 2017, we met with fellow web experts from Google, Mozilla, Apple, VS Code, and others to discuss how better to align our work around devtools protocols. The result of that discussion is the DevTools Protocol Web Platform Incubator Community Group (WICG). Through this new group, we hope to publicly explore what alignment looks like and how best we as devtools protocol vendors can benefit the community.
Participants from Google, Mozilla, Microsoft, and VS Code drove the first draft of the WICG goals.
Separate from the WICG, we’ve worked hard as we’ve implemented EDP to validate that our API surface and method/event semantics mirror CDP. By releasing version 0.1 with support for three clients (Visual Studio Code, Visual Studio, and Edge DevTools preview app), we’ve achieved a high degree of interoperability. Where needed due to platform differences, we’ve introduced Microsoft Edge-specific methods and properties, all prefixed with ms and safely ignorable by any client not requiring them.
Lastly, though we’ve committed to testable interoperability, we know there will be bugs, and we hope you will help us find them! We look forward to your feedback as you build great devtools using EDP.
Next steps
This release is the first major step on a multi-milestone journey. We’re passionately committed to building the best Microsoft Edge developer tools and platform APIs to enable our customers to be more efficient and to fix bugs in Microsoft Edge. In terms of what’s next for EDP, here’s a quick look:
More devtools: we have more features to migrate to EDP within the Microsoft Edge DevTools, and are actively migrating the most-used tools to the new APIs. In parallel, we’re investigating how tools like Sonarwhal and WebDriver can integrate, as well.
More devices: the first release supports Windows Desktop SKU devices (including VMs of that flavor), and we plan to expand the Windows SKUs and devices supported for remote debugging.
Interop improvements: as more devtools on-board and we grow our API surface, we’ll continue to invest in ensuring we’re working with the larger DevTools Protocol community to align our efforts.
That’s a rough and quick run through our thoughts about the future. We’ll continue to evolve these priorities as we interact with our developer communities to build new platform capabilities together.
Providing feedback
If you’d like to provide feedback, we’d love to hear it and recommend several channels:
Feedback Hub: You can file feedback using the Microsoft Edge category and the Developer tools sub-category in the Feedback Hub app on Windows 10—just press Win+F to get started. Whether it’s a bug or suggestion, this is the easiest way for us to receive, track, and communicate around issues you bring to our attention.
Edge DevTools UserVoice: We monitor and use requests as an important signal informing what we do, and to help prioritize the order in which we implement new features. Please add requests or upvote your favorites.
Thanks for taking the time to learn about the new Microsoft Edge DevTools Protocol and our vision for a rich ecosystem of Microsoft Edge devtools. We hope you’re as excited as we are. Happy coding!
– Brendyn Alexander, Senior Program Manager

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

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.
https://gist.github.com/kypflug/5d1e15bb33beb008a91a8bc789250255
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 https://issues.microsoftedge.com!
– Angelina Gambo, Senior Program Manager, Microsoft Edge
– Bernard Aboba, Principal Architect, Skype

Start developing on Windows 10 April 2018 Update today

We’re excited to announce that the Windows 10 April 2018 Update (build 17134.1) and SDK is now available. You may also know this as Windows 10, version 1803.
A few new features and APIs sure to become your favorites
Every major Windows 10 update always includes a wide range of APIs. These will surely be among your favorites.
Windows Machine Learning (WinML): WinML allows you to run ML ONNX models on any Windows 10 device on the April 2018 Update or greater. By just dragging your model into VS, loading the model, then executing it based on inputs, you can add machine learning into your application. If your model isn’t already in the ONNX format, there are converts for most formats.
Timeline, User Activities, and Adaptive Cards: User Activities and Timeline are amazing new ways for users to re-engage with your application and maintain context. To do your graphical representation, use Adaptive Cards, an open source card exchange format. Be sure your application has a URI schema, so you can enable deep linking. User Activities and Adaptive Cards will also become important APIs in Sets, which we’ll discuss more at Microsoft Build 2018.
New UX controls: Tree view, pull to refresh, and content links are just a few of the new controls added. These new controls can add new functionality and richness to your application.
Multi-instance for UWP applications: In the April 2018 update, you can create multi-instance applications. On top of launching new processes, it allows for customization in cases where you want to select whether a new instance of your app is launched or an instance that is already running is activated.
Update your dev environment in two simple steps
Update your system to Windows 10 April 2018 Update.
Get Visual Studio 2017 with the updated tooling and Windows 10 SDK.
How to update your device to Windows 10 April 2018 Update
There are multiple ways you can update, but the easiest way is to go to Windows Update in your settings and click “check for updates.” It’s that simple. You can also use the Update Assistant or the media creation tool also.
Acquire the Windows 10 SDK and Visual Studio 2017
Now that your system is on Windows 10 April 2018 Update, install Visual Studio and the new SDK.
• If you are currently running Visual Studio 15.6:
Download install the SDK from here: https://go.microsoft.com/fwlink/?linkid=870807
Install
• When Visual Studio 2017 15.7 is released:
Run the installer or go to https://www.visualstudio.com/downloads/ and download it.
Select “Universal Windows Platform development” under Workloads.
Verify Windows 10 SDK (10.0.17134) is checked
Click “Install.”
More useful tips
Do you want tools for C++ desktop or game development for UWP? Be sure one of these two are selected:
C++ Universal Windows Platform tools in the UWP Workload section
Desktop development with C++ Workload and the Windows SDK 10 (10.0.17134)

If you want the Universal Windows Platform tools:
Select the Universal Windows Platform tools workload.

Once your systems are updated and recompiled and your app is tested, submit your app to Dev Center.
Your take on the Update
Tell us what crazy things you’ve been working on with the new Update by tweeting @WindowsDev or @ClintRutkas.

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