Tag Archives: Windows Insiders

Announcing free Microsoft Edge testing in partnership with BrowserStack

Today, we’re thrilled to announce a partnership with BrowserStack, a leader in mobile and web testing, to provide remote virtual testing on Microsoft Edge for free. Until now, developers who need to test against a specific version of Microsoft Edge have been limited to local virtual machines, or PCs with Windows 10 installed. However, there are many developers that don’t have easy access to Microsoft Edge for testing purposes.

Screen capture showing Microsoft Edge running inside a browser on macOS.

BrowserStack Live Testing can run Microsoft Edge inside your browser on macOS, Windows, or Linux.

Today, we are excited to partner with BrowserStack, which provides the industry’s fastest testing on physical devices and browsers, so that you can focus on delivering customers the best version of your product or website. BrowserStack is trusted by developers at over 36,000 companies, including Microsoft, to help make the testing process faster and more accessible. Under this new partnership, developers will be able to sign into BrowserStack and test Microsoft Edge using their Live and Automate services for free.

Live testing provides a remote, cloud-based instance of Microsoft Edge streamed over the web. You can interact with the cloud-based browser just as you would an installed browser, within your local browser on any platform – whether it’s macOS, Linux, or older versions of Windows.

As testing setups are becoming more automated, we are excited to also offer BrowserStack’s Automate testing service under this partnership, for free. This method of testing allows you to run up to 10 Microsoft Edge test sessions via script, which can integrate with your local test runners via the standardized WebDriver API. You can even configure your machine so that the cloud-based browser can see your local development environment—see the Local Testing instructions at BrowserStack to learn more.


Testing Microsoft Edge in BrowserStack using WebDriver automation

To ensure you can test against all possible versions of Microsoft Edge that your users may be using, BrowserStack will be providing three versions of Microsoft Edge for testing: the two most recent “Stable” channel releases, and the most recent “Preview” release (via the Windows Insider Preview Fast ring).

You can test Microsoft Edge on the Windows 10 Anniversary Update (EdgeHTML 14) starting today. EdgeHTML 15 will be available in the Windows 10 Creators Update starting on April 11, 2017, and will come to BrowserStack in the following weeks.

BrowserStack currently serves more than 36,000 companies globally including Microsoft, AirBnB, and MasterCard. In addition to Microsoft Edge, the service provides more than 1100 combinations of operating systems and browsers and its Real Device Cloud allows anyone, anywhere to test their website on a physical Android or iOS device. With data centers located around the world, BrowserStack is trusted by over 1.6 million developers relying upon the service as it provides the fastest and most accurate testing on physical devices.

We’re very excited to partner with BrowserStack to make this testing service free for Microsoft Edge. Head over to BrowserStack and sign up to get started testing your site in Microsoft Edge today.

― Jason Weber, Director of Program Management, Microsoft Edge

Introducing Brotli compression in Microsoft Edge

Beginning with EdgeHTML 15.14986, Microsoft Edge supports Brotli as an HTTP content-encoding method. This change will be released to stable builds with the Windows 10 Creator’s Update early next year, but you can preview it now via the Windows Insider Program. With this release, Brotli will be broadly interoperable across browsers, with support in the latest versions of Microsoft Edge, Firefox, and Chrome.

Brotli is a compression format defined in RFC 7932, previously available as part of the WOFF2 font format. When used as an HTTP content-encoding method, Brotli achieves up to 20% better compression ratios with similar compression and decompression speeds (PDF). This ultimately results in substantially reduced page weight for users, improving load times without substantially impacting client-side CPU costs. As compared to existing algorithms, like Deflate, Brotli compression is more efficient in terms of file size and CPU time.

In the current preview release, Microsoft Edge supports Brotli on HTTPS and HTTP connections. In a future preview release, we will update this behavior to only advertise Brotli support on HTTPS connections. Like Chrome, we will continue to decode Brotli content on HTTP connections. Note that in the current preview release, there is a known issue which results in the F12 Developer Tools incorrectly not showing the accept encoding response header. This is tracked as issue 9771399 on issues.microsoftedge.com.

As always, we welcome your feedback on Brotli in Microsoft Edge! Let us know on Twitter or in the comments below if you have any questions or issues. We’re very much looking forward to making the web just a little bit lighter with Brotli!

― Rob Trace, Senior Program Manager, Microsoft Edge

Simpler web payments: Introducing the Payment Request API

We’re thrilled to introduce a preview implementation of the Payment Request API in Microsoft Edge, enabling simpler checkout and payments on the web on Windows 10 PCs and Phones. Support for Payment Request in stable builds will be coming to EdgeHTML 15 in the Creators Update early next year.

Payment Request works with Microsoft Wallet on Windows 10 PCs and phones to make ecommerce faster and simpler for customers and merchants alike. You can begin to develop for the Payment Request API today in Microsoft Edge on preview builds, starting with Windows Insider Preview build 14986. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon.

Screen capture showing an example Microsoft Wallet checkout dialog. The dialog reads "Confirm and Pay," with dropdown menus for "Pay with," "Ship to," "Shipping options," and "Email receipt to," with the total amount and a "Pay" button.

Conversion rates in the checkout flow are a key measure for ecommerce sites. 46% of e-commerce shoppers abandon the checkout process during the payment phase, signaling frustration with the complexity and redundancy of re-entering form data or tracking down payment information. Even a small increase in the success rate of checkout make a direct impact on your site’s bottom line, while improving the shopping experience for customers.

In Microsoft Edge, the Payment Request API connects to Microsoft Wallet (with the user’s permission), allowing easy access to payment information associated with the user’s Microsoft Account. Because payment information is securely saved in a digital wallet, shoppers don’t have to navigate through traditional checkout flows and repeatedly enter the same payment and shipping address information repeatedly. The wallet can provide a faster and more consistent experience across websites, which saves shoppers time and effort by allowing them to securely share saved payment information.

How does it work?

Microsoft and the other members of the W3C Web Payments Working Group designed the API with the goal of standardizing communication across merchants, browsers, and payment methods to provide a better experience for users, and a single, consistent API for developers.

With the Payment Request API, payment information is provided by the wallet (once the user has granted consent), as opposed to being collected via a checkout form in the website. The browser mediates all the information passed between the wallet and the merchant.

Flow chart illustrating the browser mediating a payment from a user to a merchant via a wallet app on the local system.

Let’s look at how to implement the Payment Request API into a sample site.

Constructor

We start with the constructor. The PaymentRequest object is constructed by passing the following parameters:

  • methodData: an array of dictionaries that contains the payment method identifiers and any pertaining data; a payment method identifier is a string that identifies a supported payment method
  • details: information about the transaction, such as the line items in an order
  • options: additional information that the Wallet may need to collect

https://gist.github.com/kypflug/6f2bdcc0859dee7ce4d81210a067d4a2

In the snippet above, we are allowing users to pay with any debit or credit card that belongs to Visa, MasterCard, or Amex networks. The details object contains the subtotal amount, the sales tax, and the total due. These details will be shown to the user in the wallet. Please note that the API will not add up items or calculate the sales tax – it’s up to the merchant to provide the correct information. In this example, we are selling a physical good, so we’ll ask the wallet to collect the customer’s shipping address.

Showing the UI, processing the payment, and displaying the results

Once the PaymentRequest object is created, you can trigger the browser to display the wallet with request.show(). In Microsoft Edge, this will present the user with a checkout dialog from Microsoft Wallet:

Screen capture showing an example Microsoft Wallet checkout dialog. The dialog reads "Confirm and Pay," with dropdown menus for "Pay with," "Ship to," "Shipping options," and "Email receipt to," with the total amount and a "Pay" button.

Customers can then select the appropriate payment information, shipping address, and other fields, then click Pay when ready. At this point, the users will have to verify their identify. If successful, this will fulfill the request.show() promise and return  to the website all the information that the customer provided to the Wallet. For the basic card payment method, the result object will contain the card holder name, card number, expiry month and other relevant fields. The merchant can then use this information to process the transaction on the backend.

After the response comes back from the server, you can use result.complete(‘success’) to display the success screen in the Wallet and result.complete(‘fail’) to indicate a failed transaction.

https://gist.github.com/kypflug/c7fdc8cea5de36c8a65fc713817c7fcb

Listening for events

The price might change according to the shipping address and shipping options that the customer selects. You can listen to those changes with the shippingaddresschange and shippingoptionchange events to recalculate the prices accordingly.

https://gist.github.com/kypflug/e5f2434c024ff132f27403e228d295b0

Feature detection

Sites can feature detect for the Payment Request API, forward the user to a legacy, form-based experience if it is not available.

https://gist.github.com/kypflug/7daa1f7f31c90b6f679ffa31925b4e31

Here’s an example of a minimal implementation of this code:

https://gist.github.com/kypflug/14dec252e272a62ef7aa0aa127a66101

Testing & Availability

The Payment Request API is on by default starting with the most recent Windows Insider Preview release (14986 or higher) on phone and desktop. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon. During this preview period, Microsoft Wallet’s response for the basic card payment method will be a fake payment card response, to help developers perform early-integration testing without having to deal with the constraints of PCI.

Starting next Spring, the API will begin to return real payment card responses. Initially, the Wallet will support US billing and shipping addresses and the English language (en-US locale). Support for additional geographies and languages will be added in 2017.

Wrapping it up

Microsoft Wallet and the Payment Request API combine to provide a powerful tool for merchants to improve checkout conversion on the web, and to give customers a more pleasant and convenient shopping experience. This API is a great example of the power and flexibility of the web platform, and is on the road to broad interoperability, with Chrome for Android supporting the API starting with Chrome 54.

More details and full documentation for the Payment Request API in Microsoft Edge are available at the Payment Request Developer Guide on Microsoft Edge Dev, and the Payment Request API Reference on MSDN. You can preview Payment Request today, along with other new features coming to EdgeHTML 15, by joining the Windows Insider Program, or by downloading preview virtual machines from Microsoft Edge Dev for your Mac or PC.

If you encounter issues, you can file bugs on bugs.microsoftedge.com, or connect with us on Twitter at @MSEdgeDev. We look forward to hearing from you!

Andy Pavia, Program Manager, Microsoft Edge

In Case You Missed It – This Week in Windows Developer

While most of the world froze in place to follow the endless stream of U.S. presidential election coverage, we continued to push forward in the world of Windows Developer. And by push forward, we humbly admit that we just kept geeking out over the new Surface Dial and its recently released APIs. (Check out the Surface Dial and more updates from our event here.)

What Devs Need to Know about the Windows 10 Creators Update & New Surface Devices

We recently learned that you can tweak the Surface Dial to be the ultimate debugging tool. Check it out here:

And while the politicians duked it out in the electoral college, one particular MVP found himself in a higher stakes conflict – battling aliens in a mall.

Insider Preview Build 14965

TL;DR – A bunch of updates and improvements across the board. Check out Dona’s post by clicking above.

MVP Summit

And, on a high note, we had a great time hosting our Microsoft MVPs in Redmond this week. Thank you to everyone who attended and helped organize the event. Here’s a quick recap from Day One:

Overall, regardless of what happens politically, there will always be more bugs to squash and even more code to write. So, on that note, have a great weekend; We’ll be right here waiting for you on Monday morning!

Download Visual Studio to get started.

The Windows team would love to hear your feedback.  Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

JavaScript performance updates in Microsoft Edge and Chakra

Since we first started work on the Chakra JavaScript engine, it has been our mission and priority to make JavaScript faster for the real world web, and to continuously improve the experience of browsing in Microsoft Edge (and previously Internet Explorer). We’ve had a very busy year, with highlights like taking Chakra open-source, delivering ES2015 & beyond, experimenting with WebAssembly and more!

Through all of this, performance remains a principal theme – our team regularly looks at customer feedback and telemetry data to find potential patterns that slow down user experience, and tunes Chakra to provide substantial boosts to the web. Today, we’d like to share a few recent Chakra improvements coming up in the Windows 10 Anniversary Update, which you can preview today on recent Windows 10 Insider Preview builds.

Memory optimizations in functions

One of the code patterns on the web is the abundance of small-sized functions in scripts. This isn’t particularly a surprise as it is common developer practice to break down complex coding logic into many smaller pieces. The practice reduces repetitiveness and makes reading, debugging and testing the code much easier. Even better it can have a performance advantage as smaller functions are generally easier to inline and the profiler can target the ‘hottest’ ones to produce JIT’ed code.

To optimize for this pattern especially in terms of memory consumption, Chakra has refactored the metadata format used for each function (internally referred to as FunctionBody). Based on data, pointers in FunctionBody that point to rarely used information have been moved to a dynamic auxiliary structure and will not be instantiated and consume memory unless necessary. A good example is the asm.js related data which is not applicable for most functions. Most of the 32-bit counters in FunctionBody were also observed to hardly have values over 256, such as the variable count or object literal count within a function. Thus these counters have been replaced by a compact structure that uses a single byte for each counter and can be promoted to full 32-bit if needed. Combined with a good number of functions, these seemingly subtle optimizations can make a big difference in reducing memory overhead (we’ll share our experiments later).

Diagram showing pointers and counters in FunctionBody moved to memory-saving structures

Many pointers and counters in FunctionBody are moved to memory-saving structures

Deferred parsing for event-handlers

The modern web is a very interactive place, and inside almost every page there lies an event system with plenty of event-handlers defining the behavior of button-clicks, mouse-overs and many other events. However, unless the associated events are triggered, event-handlers are basically dead code. And in fact more often than not many of them end up unused during a browsing session. Just think about how many buttons or textboxes you left untouched the last time you visited your Facebook home page and imagine these controls and others all have event-handlers associated with them. Taking advantage of the formerly introduced deferred-parsing feature, Microsoft Edge and Chakra now delays the full parsing and bytecode generation of event-handlers until when they are first called. Chakra uses a smaller representation for partially-parsed handlers, so the optimization not only improves the start-up time but also saves memory from any unused handlers.

The combination of deferred parsing for event-handlers and the memory optimizations in FunctionBody can together shrink a fair amount of memory footprint for each page. Though the actual saving depends highly on the pages being loaded and thus is quite hard to generalize, our experiment on a small sample of top visited sites shows that these optimizations along with other smaller tweaks typically reduce about 4 to 10% of memory usage per page opened in Microsoft Edge, with cases where the saving reaches over 20%.

Synthetic JavaScript benchmarks

All of our performance efforts are driven by data from the real world web and aim to enhance the actual end user experience. However, we are still frequently asked about JavaScript benchmark performance, and while it doesn’t always correspond directly to real-world performance, it can be useful at a high level and to illustrate improvement over time. Let’s look at where Microsoft Edge stands at the moment, as compared to other major browsers on two established JavaScript benchmarks maintained by Google and Apple respectively. The results below show Microsoft Edge continuing to lead both benchmarks.

Chart comparing browser performance on Google Octane and Apple Jetstream benchmarks. Octane scores: Edge 31187, Chrome 25910, Firefox 24836; Jetstream score: Edge 233.7, Chrome 168.3, Firefox 146.6.

All measures collected on 64-bit browsers running 64-bit Windows 10 Insider Preview
System Info: Dell Optiplex 7010 Intel(R) Core(TM) i5-3475S CPU @ 2.90GHz (4 cores) 4GB ram

We are very excited to share our performance effort to reduce memory footprint and start-up time with you. The road to better performance never ends, and we’re as committed to making JavaScript faster as we always have been. There will be more improvements in the summer months, so stay tuned for additional updates! Until then, we love feedback and rely on it to help us improve. You can always get in touch on Twitter via @MSEdgeDev and @ChakraCore, or the ChakraCore repo on GitHub.

Limin Zhu, Program Manager, Chakra Team

 

A world without passwords: Windows Hello in Microsoft Edge

At Build 2016, we announced that Microsoft Edge is the first browser to natively support Windows Hello as a more personal, seamless, and secure way to authenticate on the web. This experience is powered by an early implementation of the Web Authentication (formerly FIDO 2.0) specification, and we are working closely with industry leaders in both the FIDO Alliance and W3C Web Authentication working group to standardize these APIs. Try out this Test Drive demo in Microsoft Edge on recent Windows Insider builds to experience Windows Hello on the web today!

Passwords can be a hassle. Most people don’t create strong passwords or make sure to maintain a different one for every site. People create easy-to-remember passwords and typically use the same passwords across all of their accounts. Surprisingly – and if it’s not surprising to you, you may want to change your password – passwords like “123456” and “password” are very common. Malicious actors can use social engineering, phishing, or key logging techniques to steal passwords from your machine, or they can compromise the server where the passwords are stored. When the same password is used across several sites, compromising one account can expose many others to abuse.

We look forward to a web where the user doesn’t need to remember a password, and the server doesn’t need to store a password in order to authenticate that user. Windows Hello, combined with Web Authentication, enables this vision with biometrics and asymmetric cryptography. In order to authenticate a user, the server sends down a plain text challenge to the browser. Once Microsoft Edge is able to verify the user through Windows Hello, the system will sign the challenge with a private key previously provisioned for this user and send the signature back to the server. If the server can validate the signature using the public key it has for that user and verify the challenge is correct, it can authenticate the user securely.

Screen Capture showing Windows Hello prompt to log in to a web page

These keys are not only stronger credentials – they also can’t be guessed and can’t be re-used across origins. The public key is meaningless on its own and the private key is never shared. Not only is using Windows Hello a delightful user experience, it’s also more secure by preventing password guessing, phishing, and keylogging, and it’s resilient to server database attacks.

Web Authentication: Passwordless and Two Factor Authentication

We’ve been working at the FIDO Alliance with organizations from across the industry to enable strong credentials and help move the web off of passwords. The main goal of the FIDO Alliance is to standardize these interfaces, so websites can use Windows Hello and other biometric devices across browsers. The FIDO Alliance had recently submitted the FIDO 2.0 proposal to the W3C and the newly formed Web Authentication working group is standardizing these APIs in the W3C Web Authentication specification.

FIDO Alliance logo

The Web Authentication specification defines two authentication scenarios: passwordless and two factor. In the passwordless case, the user does not need to log into the web page using a user name or password – they can login solely using Windows Hello. In the two factor case, the user logs in normally using a username and password, but Windows Hello is used as a second factor check to make the overall authentication stronger.

In traditional password authentication, a user creates a password and tells the server, which stores a hash of this password. The user, or an attacker who obtains the password, can then use the same password from any machine to authenticate to the server. Web Authentication instead uses asymmetric key authentication. In asymmetric key authentication, the user’s computer creates a strong cryptographic key pair, consisting of a private key and a public key. The public key is provided to the server, while the private key can be held by the computer in dedicated hardware such as a TPM, so that it cannot be moved from that computer. This protects the users against attacks on both the client and the server – client attacks cannot be used to let an attacker authenticate from elsewhere, and server attacks will only give the attacker a list of public keys.

Microsoft Edge supports an early implementation of the Web Authentication spec – in fact, the latest editor’s draft has already been updated beyond our implementation and we expect the spec to continue to change as it goes through the standardization process. We have implemented our APIs with the ms-prefix to indicate that these APIs are very likely to change in the future. We’ll continue to update the APIs in future releases as the standard finalizes – so be sure to watch for changes.

The Web Authentication API is very simple – it supports two methods: window.webauthn.makeCredential and window.webauthn.getAssertion. You will need to make both server and client sides changes to enable Web Auth authentication in your web application. Let’s talk through how to use these methods.

Registering the user

To use Web Auth, you, the identity provider, will first need to create a Web Auth credential for your user using the window.webauthn.makeCredential method.

When you use the makeCredential method, Microsoft Edge will first ask Windows Hello to use face or fingerprint identification to verify that the user is the same user as the one logged into the Windows account. Once this step is completed, Microsoft Passport will generate a public/private key pair and store the private key in the Trusted Platform Module (TPM), the dedicated crypto processor hardware used to store credentials. If the user doesn’t have a TPM enabled device, these keys will be stored in software. These credentials are created per origin, per Windows account, and will not be roamed because they are tied to the device. This means that you’ll need to make sure the user registers to use Windows Hello for every device they use. This makes the credentials even stronger – they can only be used by a particular user on a particular origin on a particular device.

Before registering the credential to a user on your server, you will need to confirm the identity of the user. This can be done by sending the user an email confirmation or asking them to use their traditional login method.

The below code sample shows how you would use the makeCredential API. When you call the makeCredential API, you will need to supply as parameters data structures containing the user account information, crypto parameters, and an attestation challenge. The user account information contains information on the user’s name, profile image, site in which the user is logging into, and user identifier information on the site. We’ll cover later how this information is used. The crypto parameter is a data structure that contains the crypto algorithm you which to use. The attestation challenge is used by the authenticator to produce an attestation statement, which tells the server what security measures the authenticator implements for its credentials. There are a number of other optional parameters, which we’ll ignore here. The methods are all implemented as promises. When the promise returns, it will include an object that contains information on the credential ID, public key, crypto algorithm, and the attestation challenge. The credential ID will be used to identify the public and private key pairs. You will then send this information back to the server for validating future authentications.

.gist table { margin-bottom: 0; }

The Microsoft Edge implementation is ms-prefixed, so you’ll need to call window.msCredentials.makeCredential instead of window.webauthn.makeCredential. The Microsoft Edge implementation is also based on an earlier draft of the specification, so there are a number of other differences in implementation as well, like the credential type is “FIDO_2_0” instead of “ScopedCred”, we don’t yet implement the optional timeout, denylist, or ext parameters, or require the attestation challenge to make the credential. In Microsoft Edge, you would instead make this call using the following code:

.gist table { margin-bottom: 0; }

Authenticating the user

Once the credential is created on the client, the next time the user attempts to log into the site, you can offer to sign them in using Windows Hello instead of a password. You will authenticate the user using the window.webauthn.getAssertion call.

The getAssertion call has a number of optional parameters, but the only required parameter is the challenge. This is the challenge that the server will send down to the client. This challenge is a random quantity generated by the server. Since the challenge is not predictable by an attacker, the server can be assured that any assertions it receives were freshly generated in response to this challenge and are not replays of earlier assertions.  The allowList parameter also takes an optional list of credential ID information to locate the correct private key. This information is useful if you’re doing two factor auth and you can share the id from the server, where it is stored. In the passwordless case, you don’t want to share the id from the server because the user hasn’t yet authenticated.

If the user has multiple credentials for an origin in the TPM, the browser will show a user experience allowing the user to pick the account they meant to use (assuming they have multiple accounts with an application, and you don’t provide a credential ID). This is why we collect the user profile picture and account name upon registration.

Once the getAssertion call is made, Microsoft Edge will show the Windows Hello prompt, which will verify the identity of the user using biometrics. After the user is verified, the challenge will be signed within the TPM and the promise will return with an assertion object that contains the signature and other metadata. You will then send this data to the server. We’ll check the server code next to see how you verify the challenge is the same that you had sent.

.gist table { margin-bottom: 0; }

In Microsoft Edge, you will need to call window.msCredentials.getAssertion instead of window.webauthn.getAssertion. The Microsoft Edge implementation also requires the credential ID and we don’t yet support the account picker experience. A side effect of this is that for the passwordless case, you’ll need to store your credential ID information in local storage on the client, either in indexDB or localStorage when making your credential. This mean that if a user deletes their browsing history, including local storage, they will need to re-register to use Windows Hello the next time they log in. We will very likely fix this issue in a future release.

Here’s how you would make the getAssertion call in Microsoft Edge. Note how the accept object is required for the filter parameter.

.gist table { margin-bottom: 0; }

Server side authentication

Once you receive the assertion on the server, you will need to validate the signature. The below Node.JS code shows how you would validate the signature to authenticate the user on the server. We also have the same code available in C# and PHP.

.gist table { margin-bottom: 0; }

Evolving Web Authentication standard and Microsoft Edge implementation

As mentioned above, Microsoft Edge has an early implementation of Web Authentication and there are a number of differences between our implementation and the April 2016  spec.

  • Microsoft Edge APIs are ms- prefixed
  • Microsoft Edge does not yet support external credentials like USB keys or Bluetooth devices. The current API is limited to embedded credentials stored in the TPM.
  • The currently logged in Windows user account must be configured to support at least a PIN, preferably face or fingerprint biometrics. This is to ensure that we can authenticate the access to the TPM.
  • We do not support all of the options in the current Web Auth spec draft, like extensions or timeouts.
  • As mentioned earlier, our implementation requires that the list of acceptable credential IDs be included in every getAssertion call.

The specification is also going through the W3C standardization process and we expect a number of changes in the specification, like the object name recently changing from window.fido to window.webauthn in the latest’s editor’s draft.

We have a number of resources available to help you prototype and experiment with these APIs:

  • Webauthn.js polyfill. Using this polyfill, you can code to the standard instead of our early implementation. We’ll update this polyfill for every major published version of the specification.
  • Windows Hello in Microsoft Edge test drive sample. This test drive sample shows you the typical client side registration and assertion flow.
  • Server and client side WebAuth This sample code shows the end to end client and server side flow for registration and assertion.
  • C#, PHP, and JS server side sample. These code samples show how could implement your server side logic in a number of language options.
  • Web Authentication MSDN documentation and dev guide.

Call to Action

We’re excited to support Windows Hello and Web Authentication in Microsoft Edge and innovate in the biometric authentication and passwordless space in the web. Now is a great time to start prototyping and experimenting with these APIs and sharing your feedback with us in the comments below or on Twitter. We look forward to hearing from you!

Rob Trace, Program Manager, Microsoft Edge
Jatinder Mann, Program Manager Lead, Microsoft Edge
Vijay Bharadwaj, Software Engineering Lead, Security
Anoosh Saboori, Program Manager, Security

Microsoft Edge extensions now available to preview

Today, we’re happy to announce that the first set of extensions for Microsoft Edge are now available to preview via the Windows Insider Program. You can try out extensions starting in build 14291, which was released today to the Fast ring. Visit our new extensions page at Microsoft Edge Dev to learn more and try it out for yourself!

In keeping with our commitment to an interoperable web, we’re participating in the W3C Browser Extension Community Group’s efforts to define standardized extension APIs based on familiar web technologies. Today, we’re previewing our first step towards that goal.

This release supports a selection of preview extensions that have been validated by our team to work with the current set of supported APIs. Some planned APIs are not yet supported, but will be coming in future previews. We’ll share additional examples of extensions with future releases.

Loading extensions in Microsoft Edge

When we ship extensions to the public later this year, extensions will be available through the Windows Store, providing users a simple and secure discovery and installation experience. In this preview, extensions need to be sideloaded manually.

You can download the first preview extensions at our extensions page on Microsoft Edge Dev. We currently support the Reddit Enhancement Suite, Microsoft Translator, and Mouse Gestures extensions, with more on the way!

Screen capture showing Extensions interface in Microsoft Edge

Sharing feedback

At this time, we’re focused on collecting feedback on the supported extensions and finding bugs in our extension APIs. We’re continuing to work with a group of co-development partners on the first extensions that will be available in the Windows Store later this year. We’ll share more details on our extension APIs and the path to the Store at Build 2016 and Microsoft Edge Web Summit, and we look forward to sharing more then.

If you encounter any issue with these extensions, you can share it with the Microsoft Edge team via the Windows Feedback app in Windows 10. Try it out and let us know what you think!

– Chee Chen Tong, Senior Program Manager, Microsoft Edge
– Mike Pietraszak, Senior Program Manager, Microsoft Edge

Celebrating Lumia 950 and Lumia 950 XL sales starts around the globe

On November 20, we started the rollout of the Lumia 950 and Lumia 950 XL, and over the next couple of weeks, we celebrated with Windows Insiders – people helping to shape Windows 10 with us – in nine countries and 12 cities taking us from China to New York City.

This duo of Windows 10 phones – the most productive smartphones on the planet – created a buzz around the globe. Here’s a smattering of the social conversation on the availability of the Lumia 950 and Lumia 950 XL:

If you already have one of these new smartphones–which come pre-loaded with Windows 10, world-class imaging with ZEISS optics and a 20-megapixel camera, Windows Hello Beta, and more–take part in our #LumiaTrials Challenge series on Twitter.

Through January 1, @LumiaUS will post nine challenges for select social influencers and anyone (such as you!) who would like to participate. The challenges include showing how you’ve personalized your Start screen; telling how Cortana helps you; and sharing your favorite photo-worthy moments.

And if you don’t have a Lumia 950 or Lumia 950 XL yet, follow the social conversation to jumpstart your knowledge and know-how of these Windows 10 devices.

#LumiaTrials graphic for social campaign

Both phones are available through the Microsoft Store and from network carriers (availability is dependent on country).

Asynchronous code gets easier with ES2016 Async Function support in Chakra and Microsoft Edge

While we work on rounding out our ES6/ES2015 support, the Chakra team is already looking ahead to ES2016 and, especially, to Async Functions. Today, we’re excited to announce the availability of Async Functions in Microsoft Edge as an experimental feature, available to preview starting in Microsoft Edge (EdgeHTML 13.10547).

ES7/ES2016 Async Functions

The async and await keywords, part of the Async Functions proposal, provide an easy way to write asynchronous code. It is one of the killer features of C# and is often requested by JavaScript developers.  Before Async Functions and Promises, a JavaScript developer had to carve out all the asynchronous code she needed into a separate function from the synchronous core and use callbacks to retrieve the result of the asynchronous computation. This code can quickly become hard to read and difficult to maintain.

ES6 Promises helped improve the way to write asynchronous code by standardizing and by including the feature directly in the web browser. But it did not totally solve the problem as we still need to use callbacks to retrieve the result.

Async Functions are based on Promises, but take them a step further. When you add an async keyword to a function or an arrow function it will automatically return a Promise. For example, the following code is a standard ES2015 program that performs an Http request with promises:

.gist table { margin-bottom: 0; }

If we rewrite the same code and get the same behavior with Async Functions, the result is smaller and more readable code. The code below also has a refactoring to change the way we manage the error in the function:

.gist table { margin-bottom: 0; }

The async keyword also works with ES6 arrow functions, simply by adding the keyword before the arguments. Following in an example of the same:

.gist table { margin-bottom: 0; }

To clarify:

  • Use the async keyword with any function declaration or arrow function to get asynchronous code with a Promise. This includes functions in classes and static function. For this last one, the async keyword should be placed after the static keyword and before the function’s name.
  • Use the await keyword to make execution wait for the end of an async expression (a call to an async function for example) and get the returned value of the Promise.
  • If you don’t use the await keyword, you will get a Promise.
    .gist table { margin-bottom: 0; }

  • You cannot use the await keyword outside an async function, including the global scope.

How is it implemented in Chakra?

In a previous post, we discussed the architecture of the Chakra engine in detail using the diagram below. The parts requiring the most modification to support Async Functions are highlighted in green.

Global behavior

Using the async keyword will generate a Promise constructor, according to the specifications, that wraps the function’s body. To perform this action, Chakra’s Bytecode Generator generates a call to a built-in function that describe the following behavior:

.gist table { margin-bottom: 0; }

The spawn function above is designed to manage all the async expressions in the function’s body and decide to stop or continue the process depending of the behavior inside the async function. If an async expression called with an await keyword fails, for example because of an error inside the async function or something being awaited, the promise will be rejected to make it possible to manage the error higher in the stack.

Now the engine needs to make the JS script call this spawn function to get the Promise and run the function’s body. To do this, when the parser detects an async keyword, the engine changes the AST (Abstract Syntax Tree), which represents the developer’s algorithm, to add a call to the Spawn function with the function’s body. Consequently, the httpGetJson function is converted like this by the parser:

.gist table { margin-bottom: 0; }

Note the use of Generators and the yield keyword to perform the await keyword’s behavior. Indeed, the implementation of the await keyword is extremely similar to the yield keyword.

Behavior with a default argument

One of the new feature from ES6 is the possibility to set a default value to an argument in a function. When default value is set, the Bytecode Generator will set the value at the top of the function’s body.

.gist table { margin-bottom: 0; }

In the case of an async keyword, if the default value sets to this argument throw an error, the specifications ask to reject a Promise. This allows the exception to be caught easily.

To realize it, the Chakra team had two choices: change the AST (Abstract Syntax Tree), or implement it directly in the Bytecode Generator. We chose to implement it directly in the Bytecode Generator by moving the argument’s initialization to the top of the function’s body directly in the Bytecode, because it is an easier and cleaner solution in this engine. Since a try/catch needs to be added to intercept any error from the argument’s default value, it’s easier to change the Bytecode directly when we detect an async keyword.

Finally, the generated Bytecode will be similar to what would be generated for the following JavaScript code:

.gist table { margin-bottom: 0; }

How to enable Async Functions in Microsoft Edge?

To enable and experiment with the current Async Functions support in Microsoft Edge, navigate to about:flags in Microsoft Edge and select the “Enable experimental JavaScript features” flag as below:

Screen capture showing the "Experimental JavaScript features" flag at about:flags

The “Experimental JavaScript features” flag at about:flags

Async Functions are available to preview via the Windows Insider Program starting in Microsoft Edge 13.10547.We can’t wait to hear about how you will be using the feature in your ES2016 code and look forward to sharing more soon about our next investments in Chakra. In the meantime, feel free to join the comment discussion, reach out on Twitter @MSEdgeDev, or on Connect.

Etienne Baudoux, Software Development Engineer Intern, Chakra Team
Brian Terlson, Senior Program Manager, Chakra Team

Understanding versions in an evergreen browser

The most recent Windows Insider Preview release (build 10547) contains a new set of features now available for Insiders to test – we encourage you to check out our Microsoft Edge changelog to see what’s new and try out the build for yourself via the Insider Program.

Since Microsoft Edge is designed to be an evergreen browser, regularly updated as part of “Windows as a Service”, we expect the browser version numbers to be much less of a focus than they have been in the past. That said, we do recognize that underlying version numbers can still be important for some scenarios, so with this release  we’re also issuing our first updates to the browser’s app and platform version. These updates will be reflected in Settings pane in Microsoft Edge and in the browser’s User-Agent string.

EdgeHTML versioning and the “Edge” User-Agent token

Since our first previews of Microsoft Edge  and the EdgeHTML rendering engine, we’ve asked developers not to rely on the token version (“Edge/12.10240”) in the user-agent string as it was likely to be updated. This token represents the EdgeHTML platform version number (12), and in a future preview will also be found in the Settings pane in Microsoft Edge.

Mockup of settings pane showing Microsoft Edge and EdgeHTML versions

Mockup of settings pane showing Microsoft Edge and EdgeHTML versions

With today’s updates, we’re iterating this token to “Edge/13.*,” and will continue to update the token in the future according to the MAJOR.BUILD  schema. The major version number represents a significant platform release; typically, we will only update the major number once for each Current Branch  update. As always, you can expect to see these updates in the Windows Insider Preview rings before the Current Branch is updated. The build version number continues to indicate the current Windows build number. Our changelogs will continue to provide details according to the build version to best reflect changes between Windows Insider or Current Branch builds.

This scheme is designed to make it easy for developers and IT professionals to track features from preview builds to release branches via the major version number, and from build to build via the build version number. In future preview releases, we expect to iterate the major build number in the first feature release to the Insider rings following a mainstream release to the Current Branch.  Note that these versions will not be incremented when servicing fixes are applied.

For sites or other resources that are primarily concerned with tracking availability of web standards and other developer-facing features, we recommend tracking against the EdgeHTML version number, rather than the Edge app version number (described further below). We have started working with sites like CanIUse.com and the Kangax ECMAScript 6 compatibility table to start reflecting this:

Screen capture of CanIUse.com showing the EdgeHTML platform versions 12 and 13

Microsoft Edge app version

In this update you’ll also notice the Microsoft Edge app version has been updated to 21.10540. This version number represents feature updates to the browser application  (i.e. user interface features surrounding the web page itself, such as the address bar, tabs, Cortana, Reading View or Web Notes). As in EdgeHTML, the build version simply represents the current Windows build. The major version numbers between Microsoft Edge and EdgeHTML have diverged and will continue to do so as we deliver updates to the application and underlying platform separately. Unlike the EdgeHTML version number, the Microsoft Edge app version is not incorporated in the UA string, as it does not impact site rendering.

As always, we encourage you to try out today’s preview and the new platform features we’re flighting, and let us know what you think!

Kyle Pflug, Program Manager, Microsoft Edge