Category Archives: Tablet

Auto Added by WPeMatico

Introducing Web Authentication in Microsoft Edge – Microsoft Edge Dev Blog

Today, we are happy to introduce support for the Web Authentication specification in Microsoft Edge, enabling better, more secure user experiences and a passwordless experience on the web.With Web Authentication, Microsoft Edge users can sign in with their face, fingerprint, PIN, or portable FIDO2 devices, leveraging strong public-key credentials instead of passwords.

Staying secure on the web is more important than ever. We trust web sites to process credit card numbers, save addresses and personal information, and even to handle sensitive records like medical information. All this data is protected by an ancient security model—the password. But passwords are difficult to remember, and are fundamentally insecure—often re-used, and vulnerable to phishing and cracking.
For these reasons, Microsoft has been leading the charge towards a world without passwords, with innovations like Windows Hello biometrics and pioneering work with the FIDO Alliance to create an open standard for passwordless authentication – Web Authentication.
We started this journey in 2016, when we shipped the industry’s first preview implementation of the Web Authentication API in Microsoft Edge. Since then, we have been updating our implementation to as we worked with other vendors and the FIDO alliance to develop the standard. In March, the FIDO Alliance announced that the Web Authentication APIs have reached Candidate Recommendation (CR) status in the W3C, a major milestone for the maturity and interoperability of the specification.

Beginning with build 17723, Microsoft Edge supports the CR version of Web Authentication. Our implementation provides the most complete support for Web Authentication to date, with support for a wider variety of authenticators than other browsers.
Windows Hello allows users to authenticate without a password on any Windows 10 device, using biometrics—face and fingerprint recognition—or a PIN number to sign in to web sites. With Windows Hello face recognition, users can log in to sites that support Web Authentication in seconds, with just a glance.

Users can also use external FIDO2 security keys to authenticate with a removable device and your biometrics or PIN. For websites that are not ready to move to a completely passwordless model, backwards compatibility with FIDO U2F devices can provide a strong second factor in addition to a password.
We’re working with industry partners on lighting up the first passwordless experiences around the web. At RSA 2018, we shared a sneak peak of how these APIs could be used to approve a payment on the web with your face. Passwordless authentication experiences like this are the foundation of a world without passwords.

We’re excited to get implementation into the hands of more developers to see what you build. To get started with Web Authentication in Microsoft Edge, check out more information on our implementation in the Web Authentication dev guide, or install Windows Insider Preview build 17723 or higher to try it out for yourself!
– Angelo Liao, Program Manager, Microsoft Edge– Ibrahim Damlaj, Program Manager, Windows Security
Updated July 30, 2018 10:12 am

Getting started with IndexedDB inspection in the Microsoft Edge DevTools – Microsoft Edge Dev Blog

The Windows 10 April 2018 Update introduced an all-new IndexedDB manager for the Microsoft Edge DevTools, allowing you to inspect your database, sort your data, and delete it—all from the Debugger. In this post, we’ll walk you through getting started with the new IndexedDB manager, and some improvements we have planned for the future!IndexedDB in the DevTools
Once you have created your database and added an object store, you can expand the IndexedDB node in the Resource picker in the Debugger to see a list of origins (the domain, application layer protocol, and port of a URL of the document where the script is being executed) from the resources loaded by the page. Your new database (or databases if you’re creating more than one) will be listed under the origin that created it, along with its object stores.

You can check out what’s in each object store by clicking on it, which will open it as a tab in the Debugger.

Managing IndexedDB data
When your app changes your IndexedDB data, you won’t see those changes in the DevTools in real time. You’ll need to click the Refresh button (or press Ctrl+F5) to update your object store or index.
The simple sample app searches images using the Bing Search API and saves those images as Base64 strings to an object store in an IndexedDB database. In the animation below, note that when we save an image, it won’t appear in our object store until we refresh (Ctrl+F5) in the IndexedDB manager.

Data in your object store or index can be deleted per row via the keyboard (Del) and context menus (right-click and select Delete item). You can also delete all IndexedDB data stored for the current user in Microsoft Edge using the Microsoft Edge Settings menu under “…” > Settings > Clear browsing data > Cookies and saved website data.
What’s next for the IndexedDB manager
In future releases, we’re planning to take all of the data storage solutions currently housed in the Resource picker in the Debugger—Local Storage, Cache, IndexedDB, etc.—and move them to a new tool we’re calling Storage. We think this change will make it easier and more intuitive to find, inspect, and manage web storage on your page in the DevTools.
Further our on our backlog, we’re evaluating a number of features for the IndexedDB manager:
Adding new data to an object store or index
Editing your existing key-value pairs directly
Making it easier to clear object stores or indices
Making it easier to clear all web storage solutions on your page
Adding blob support for IndexedDB in Microsoft Edge
Tell us what you think
We hope the IndexedDB manager makes the DevTools easier to use and improves your productivity in Microsoft Edge. If you encounter any bugs or have feature suggestions, the best way to flag them for our attention is via the Feedback Hub. You can launch the Feedback Hub straight from the DevTools using the icon (pictured below) in the top-right corner of the DevTools.

These features are available beginning with the Windows 10 April 2018 Update. If you want to get your hands on these (and other) improvements but aren’t yet on the April 2018 Update, check out the Microsoft Edge DevTools Preview App!
You can learn more in our docs, as well as in the IndexedDB content on MDN. As always, reach out to us with any questions, feedback, or feature requests on Twitter, Feedback Hub, or UserVoice.
– Zoher Ghadyali, Program Manager, Microsoft Edge DevTools
Updated July 11, 2018 10:42 am

Chakra documentation is joining MDN web docs – Microsoft Edge Dev Blog

Last fall, along with other browser vendors and web platform stakeholders, the Edge platform (EdgeHTML) team adopted MDN web docs as our official web API reference library. In the process, we redirected over 7700 MSDN pages for HTML, CSS, SVG and DOM APIs to corresponding reference content on MDN and joined the community in helping maintain it, including making over 5000 edits to the browser compatibility tables to reflect the latest Edge API surfaceToday the Microsoft Edge JavaScript engine, Chakra, joins the community-wide effort to make MDN web docs the web’s one-stop, premiere development reference, starting by redirecting all 500+ pages of Microsoft’s JavaScript API reference from to their MDN counterparts and porting our legacy JS extensions reference for historical and servicing purposes.

We want to thank our community for enthusiastically embracing MDN web docs, and special kudos to everyone who helps to improve the docs, edit by edit. In the previous year alone, you helped the MDN web docs community grow monthly users by over 50%! Let’s keep documenting the web forward together.
– Erika Doyle Navara, MDN Product Advisory Board representative for Microsoft Edge

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

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

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 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.
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:
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.
Programmatically adding WebView
The WPF version of the control is in the Microsoft.Toolkit.Win32.UI.Controls.WPF namespace.
Using WebView for WinForms
Using the Designer
First, we’ll need to add a WinForms control from a NuGet package to the Toolbox in Visual Studio. In a future release, Visual Studio will do this automatically.
First, open the Visual Studio Toolbox, then right-click anywhere in the toolbox, and select the Choose Items
In the .NET Framework Components tab of the Choose Toolbox Items dialog box, click the Browse button to locate the Toolkit.Win32.UI.Controls.dll in your NuGet package folder.
For help finding that folder, see Managing the global packages, cache, and temp folders.
After the DLL is added to the list of Toolbox controls, WebView is automatically
Close the Choose Toolbox Items dialog box.
The WebView control appears in the All Windows Forms section of the Toolbox when the Windows Forms Designer is open.
Programmatically adding WebView
After installing the NuGet package, you can add the WebView to your application like any other control. The WinForms version of the control is in the Microsoft.Toolkit.Win32.UI.Controls.WinForms namespace.
We’re just getting started!
The current WinForms and WPF WebView implementations are an early preview, with some limitations when compared to the UWP WebView control. For the complete list of these limitations, see Known Issues of the WebView control for Windows Forms and WPF applications on GitHub.
You can get started with WebView today using the Windows 10 April 2018 update or the latest Windows Insider Preview builds, where we’ll be adding more improvements as we continue towards a stable release. Please share your feedback or suggestions via @MSEdgeDev on Twitter, in the Windows Community Toolkit project on GitHub, or in the comments below.
Happy Coding!
– Kirupa Chinnathambi, Senior Program Manager, Microsoft Edge
– Richard Murillo, Principal Architect, Microsoft Edge

Bringing Screen Capture to Microsoft Edge with the Media Capture API

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