Microsoft Edge Blog Official blog of the Microsoft Edge Web Platform Team Mon, 19 Jul 2021 05:45:20 +0000 en-US hourly 1 Microsoft Edge Blog 32 32 Easier browser debugging with Developer Tools integration in Visual Studio Code Fri, 16 Jul 2021 17:00:27 +0000 If you're debugging JavaScript in Visual Studio Code you probably have used either the Chrome Debugger or the <

The post Easier browser debugging with Developer Tools integration in Visual Studio Code appeared first on Microsoft Edge Blog.

Visual Studio Code you probably have used either the Chrome Debugger or the Microsoft Edge Debugger extension. Neither are necessary any longer to debug as JavaScript debugging is now built-in to Visual Studio Code. This does not only mean that you can uninstall these extensions, but we also made debugging more convenient. To debug any project in either Chrome or Microsoft Edge, all you need to do is to start a session by pressing F5 or activating the debug icon in the menu bar and selecting "Run and debug". Alternatively, you can also use the Visual Studio Code command palette and run the “Debug: Open Link” command. From there on you can choose to debug in Chrome, Edge or Node.js without having to install any extensions. If you choose Edge, you'll notice an extra feature in the debug toolbar: an inspect button. Screenshot of the inspect button in the debug toolbar This button launches the Edge Developer Tools right inside your Visual Studio Code instance. The first time you activate this button, the editor will ask you to install the Microsoft Edge DevTools for Visual Studio Code extension. Once you have this one installed you won't be prompted again. Prompt to install the Microsoft Edge DevTools extension You can then inspect the DOM, change CSS, and see network requests of your project running in the browser without leaving Visual Studio Code. Screenshot of the Elements inspector in VS Code As a bonus, you can also use the Debug Console in the editor to interact with the document in the browser, much like you would with the Console in the browser developer tools. You have full access to the window object and can use the Console Utilities API. Screenshot of the debug console If you want to automatically attach to Microsoft Edge and launch the Developer Tools in the editor, you can create a launch.json file. Notice that `https://localhost:8080` probably needs to be changed for your project.
  "version": "0.2.0",
  "configurations": [
      "type": "pwa-msedge",
      "request": "launch",
      "name": "Launch Microsoft Edge and open the Edge DevTools",
      "url": "http://localhost:8080",
      "webRoot": "${workspaceFolder}"
If you want to take a deep-dive into the features of the built-in JavaScript debugging workflow of Visual Studio Code, you can check the README file of the debugger extension. We hope that by automatically including the option to debug with browsers into Visual Studio Code we made the process easier to get started and would love to learn what else we can do to make you more effective in your debugging journey. Send feedback (Alt-Shift-I with the DevTools open) or reach out to the team on Twitter to let us know what you think!]]>
How to opt-in to the Extended Stable release cycle option beginning with Microsoft Edge 94 Thu, 15 Jul 2021 16:00:47 +0000 In March, we announced that Microsoft Edge would be moving from a 6-week to a 4-week release cycle cadence to deliver more innovation to u

The post How to opt-in to the Extended Stable release cycle option beginning with Microsoft Edge 94 appeared first on Microsoft Edge Blog.

6-week to a 4-week release cycle cadence to deliver more innovation to users and organizations, faster. For most users, this means receiving and enjoying our latest browser innovations on a more frequent basis. Organizations though might experience this change differently due to the complexities of testing, deployment, and maintenance. To more effectively serve organizations who may want a longer timeline, we will offer a new 8-week “Extended Stable” release cycle option (configurable by Group Policy) in addition to the regular 4-week “Stable” release cycle which will be the default beginning with Microsoft Edge 94. [caption id="attachment_24814" align="aligncenter" width="624"]Diagram showing incremental stable releases every four weeks, and even-numbered Extended Stable releases every eight weeks. Representation of how releases will be delivered to Microsoft Edge for the “Stable” and “Extended Stable” release cycle options.[/caption]

“Extended Stable” is available starting with Microsoft Edge 94

Starting with Microsoft Edge 94, IT administrators will have the flexibility to select between different release cycle options for Microsoft Edge Stable: the 4-week “Stable” option or the 8-week “Extended Stable” option. This means there isn’t a new browser application to deploy to use the “Extended Stable” release option—organizations can just select the release cycle option that is right for them. It’s like setting a recurring update for the Microsoft Edge stable application where a cumulative set of features will be delivered to the browser based on the selected release cycle. The 8-week “Extended Stable” release cycle option for Microsoft Edge Stable will deliver cumulative feature updates aligned with even-numbered releases beginning with Microsoft Edge 94; any feature updates from odd-numbered releases will be packaged up and delivered as part of the subsequent even-numbered release. For instance, if an organization selects the 8-week “Extended Stable” release cycle with Microsoft Edge 94, they will receive subsequent feature updates with Microsoft Edge 96, Microsoft Edge 98, and so on. While feature updates will be packaged and delivered with new version releases based on the selected release cycle, important security patches and fixes will be delivered as needed independent of the selected release option to help maintain browser security. Note: The WebView2 Runtime will update following the 4-week “Stable” release cycle.

Opt-in and manage using Group Policy or Microsoft Endpoint Manager

IT administrators will be able to opt-in to the 8-week “Extended Stable” release cycle option for Microsoft Edge Stable by using the “TargetChannel” Group Policy and selecting the “Extended Stable” option (updated policy files will be available from the Microsoft Edge Business website with Microsoft Edge 94). If this policy is not set, Microsoft Edge will default to the 4-week “Stable” release cycle. Organizations using Microsoft Endpoint Manager will also be able to select the 8-week “Extended Stable” release option via Intune. The Microsoft Edge browser updates automatically by default, and we recommend this as the best method to receive version releases, regardless of the release cycle option selected. With auto-updating, organizations can avoid the hassle of manually updating the Microsoft Edge application every 4 or 8 weeks, while exciting their users with the latest browser features as they’re released. For those organizations who prefer to manually update Microsoft Edge, packages will be found in the Windows Server Update Services (WSUS) catalog.

Support continues for current and recent versions of Microsoft Edge

With the transition from a 6-week release cycle to 4-week and 8-week release cycle options, we will also update our support policy. We will continue to support the latest major version release of Microsoft Edge “Stable”, along with the previous two “Stable” releases. We will also support the latest major version release of “Extended Stable” and the previous “Extended Stable” release to provide similar coverage.
Release option Major version release supported Cumulative coverage
4-week “Stable” Latest, and previous two “Stable” releases (eg. 96, 95, 94) 12 weeks
8-week “Extended Stable” Latest, and previous “Extended Stable” release (eg. 96, 94) 16 weeks
Note: For more information on Microsoft Edge support and servicing, please see our Microsoft Edge Support Lifecycle page. Over the last year and a half, customers have been delighted by innovations in Microsoft Edge that have boosted performance and offered new ways to experience the web. We’re excited to serve our customers more effectively with these new release cycle options arriving with Microsoft Edge 94 in late September. For a closer look at the Microsoft Edge release schedule, please see our Docs article]]> 0
Dark Mode for HTML Form Controls Wed, 16 Jun 2021 16:00:28 +0000 If you build a web application, chances are good that you’ve received user requests for dark mode support in the past couple of years. While some users may simply prefer the aesthetics of dark UI, others may find that dark mode helps ease eye strai

The post Dark Mode for HTML Form Controls appeared first on Microsoft Edge Blog.

Chrome v91 for Android, and will be available in future versions of Microsoft Edge for Android. When the web developer expresses support for dark mode, and the user has this mode enabled, our user agent (UA) stylesheet will “auto-darken” form controls out-of-the-box:
Light mode Dark mode
Light mode form controls in Chromium Dark mode form controls in Chromium
Any styles added by the web developer or user will override the user agent style as per usual—if you’ve made your text input background hot pink, you’ll need to update that color yourself in dark mode using the prefers-color-scheme media query. Here’s how you can take advantage of dark mode support for HTML form controls.

Render all document form controls in dark mode

A meta tag declaration with the color-scheme name signals to the browser which color modes the web application supports. To tell the browser it is safe to render controls as light or dark, declare the following in the head of your document:
The browser will apply its user agent stylesheet to all controls in your document: Dark mode controls in Chromium Explore meta tag example on Codepen for more controls The Chromium UA stylesheet also includes color scheming for the document background, text, and link colors. In this example, the web developer did not specify these colors in their own stylesheet, so the document is now automatically rendered as light text on a dark background. If you don’t have control over the head of your document, or prefer keeping all color support bits in CSS, you can instead use the CSS color-scheme property:
:root {
    color-scheme: light dark;
Opting into both light and dark schemes on the :root means that all the controls in your document will pick up the active color scheme—essentially equivalent to the meta tag declaration. Explore CSS color-scheme example on Codepen

Render specific form controls in dark mode

Some web developers might need to apply dark color schemes only to some areas of their application. In such a case, you can continue to use the color-scheme CSS property, instead with a more specific selector:
.schemed-area {
    color-scheme: light dark;
We’re targeting the .schemed-area div with our selector, so color-scheme specific UA styles will only cascade to this element and its descendants. Here’s what that looks like with dark mode enabled: Default style area contrasting with a schemed area. In this case, the default style controls are in light mode, and the schemed area controls are in dark mode. Explore selective color-scheme example on Codepen With dark mode enabled on the system, no changes were applied to the contents in the “Default style area” box. Within the “Schemed area” box, the form controls were updated to dark mode aesthetics. You may notice that—unlike opting into color schemes at the root—non-control contents in the “Schemed area” were unchanged by the user agent’s dark theme. Instead, web developers should manage text and background colors for the schemed area using the prefers-color-scheme media query.

Share your feedback

We’re excited to make it a bit easier for web developers to support dark mode in Chromium, and are eager to hear what you think! If you run into any issues or have any feedback, use the in-app feedback button (or Alt+Shift+I). You can also reach out to us on Twitter. Thanks for your feedback!

—Melanie Richards, Senior Program Manager —Sam Sebree, Software Engineer —Ionel Popescu, Software Engineer —Bo Cupp, Principal Software Engineer —Brian Heston, Senior Designer

Improving contrast in Microsoft Edge DevTools: A bugfix case study Tue, 15 Jun 2021 16:00:03 +0000 Creating accessible products means most of all being aware of the usability issues your designs and code can cause. When creating new products, Microsoft follows a strict workflow of accessibility reviews of designs, code reviews and mandatory audits

The post Improving contrast in Microsoft Edge DevTools: A bugfix case study appeared first on Microsoft Edge Blog.

command menu: DevTools Command Menu This menu lists commands that match what the user types in the input field. Every command has an associated category which is represented by a colored badge displayed next to it. This badge also contains the category name so we’re not relying solely on the color, which would be an accessibility barrier for people with low vision or color vision deficiencies. Enlarged screenshot of Command Menu results highlighting the colored category badge That said, we’re not quite out of the woods yet. The bug and its fix we would like to describe here is related to the fact that some of the badges didn’t have sufficient contrast between their background and text colors. The "resources" badge in the command bar, which is white-on-yellow The screenshot below shows that the “Resources” badge has a very low color contrast ratio (1.511:1). The WCAG2.1 guidelines say that, at a minimum, the contrast ratio needs to be 4.5:1 for users with low vision to be able to read the text. According to the W3C Accessibility Requirements for People with Low Vision, there is an estimated 246 million people worldwide who have low vision. Among them might be a lot of potential DevTools users who would have missed out on those badges if we hadn’t fixed that bug. In addition to that, making these more readable is what everyone can benefit from.

Setting up

The Resources badge wasn’t the only badge with low contrast, and in total there are 17 different badges. We needed to find all the contrast issues and – if needed – fix them using DevTools. One thing not a lot of people know is that you can use DevTools to inspect DevTools! This means you can open DevTools, undock them and open a second instance of DevTools that targets the first one. From that second instance, we can inspect the badges and make color changes like you would change any other color on a web page. Lately, we’ve improved our development environment to make this quite fast, but it was still going slow and repetitive work. We had many colors to change, and every time we would make a change to the source code, we’d have to rebuild and reload DevTools, re-open the command menu, and test the contrast. We needed a way to look at all badges all at once in order to make the necessary adjustments instead of testing them one by one. To do this, we created an HTML document that contained all the possible badges, in both themes: Mockup of all category badges in light and dark themes

Testing contrast

We used 3 different techniques to test color contrast in our HTML page.

In DevTools

DevTools has a built-in contrast feature. If you start the inspect element mode, you can hover over elements in the page, and DevTools will show a little popup that follows your cursor and indicates the color contrast of the hovered element you even get a green checkmark next to those with enough contrast and an exclamation icon next to problematic ones. DevTools element inspector showing a contrast warning on a badge This worked great, but it also meant we needed to hover over each and every badge, one at a time, in order to check for contrast. So we tried a second technique.

Using the Accessibility Insights extension

Since we had 17 different badges to check, in 2 color themes, we needed something a little faster. The Accessibility Insights tool comes as a browser extension (for both Google Chrome and Microsoft Edge) that, among other things, can check for color contrast issues. We use this extension in our audits of new products as it provides automated and guided accessibility test flows. Using the extension, we were able to run a scan of the entire page, and it reported 15 contrast issues all at once. Results from Accessibility Insights showing 15 color-contrast issues on the sample page While this browser extension was very useful, we lacked one more thing to make the fix easy to do. We needed to be able to make adjustments to the colors and see the resulting contrast in real time.

Our custom color contrast checker

We borrowed some of the contrast calculation code from DevTools (the DevTools front-end code is in JavaScript and TypeScript, which made it straightforward) and added it to the local web page. Wrapping the calculation code in an interval to display warnings in the page directly meant that we were now able to change colors in DevTools and see what the new contrast ratios were without having to reload the page. Animation showing adjusting color values in DevTools on the demo page You can try the demo page in action or look at the source code. One interesting technique we used to show the contrast in the page was by using data attribute on the badges. We calculated the ratio for each badge and then set it on each badge like this: badge.dataset.contrast = ratio; Using a CSS pseudo-element and the attr() function we could then display the contrast value directly from CSS without needing any other DOM elements:
.badge.low-contrast::before {
    content: attr(data-contrast);
    position: absolute;
    background: red;
    color: white;
    /* ... */

The fix

Now that we had a very comfortable environment to work in, we could make the required color changes. Practically, this meant opening up the color picker in DevTools for a given badge, and raising or lowering the luminosity of the background color just enough so that the contrast ratio became at least 4.5:1. We ended up with the following colors: Mockup of the DevTools command bar badges with new colors applied We weren’t entirely happy with the results though. With DevTools in Light theme, the label inside the badges was displayed in white text and, for the contrast to be sufficient, we had to make the background colors quite a lot darker than they were. While we started with saturated colors that really popped we had to change them quite drastically and the result is that they now looked a bit muted. A few of the colors looked kind of brown, less pleasing to the eye, and some became harder to differentiate from others. In Dark theme however, because the text was black, the background colors needed to be a lot lighter and this gave us a lot more freedom. The colors looked better, and still quite different from each other. We therefore decided to always use black text for the badges, no matter which DevTools theme was selected. This way we could use the nice colors, preserve a nice user interface while being accessible to all. The other advantage that came with this decision is that we didn’t need to have 2 sets of CSS variables now. Previously, we had 17 colors for Dark theme, and had to override some of them for Light theme. Others worked well for both black and white text. In trying to fix our contrast issues, we realized that it wasn’t always possible to have just one background color that works fine with our 2 text colors. Edge DevTools inspecting the "Resources" badge, showing that the same color will not meet contrast requirements for light and dark themes With just one single text color, we didn’t have that problem, and we only had to maintain 1 set of CSS variables.

The result

After applying the color changes to the DevTools source code, we went from this: Previous command bar styles with lower-contrast badges To this: Newer command bar style with higher contrast badges Now all the badges have sufficient color contrast ratios and we can be sure that the category names are accessible to all users.

More good news about contrast in web pages

Currently there is a lot happening in the accessibility tooling space when it comes to contrast. If you want to take a look at what’s coming next, check out the new color contrast algorithm experiment. This is an improved way to determine contrast that takes into account the weight of the text. Furthermore, as part of the Chromium project, an Issues pane experiment now automatically reports color contrast issues for the whole document. Using this feature means you don’t need to code  some extra page to test a lot of contrast issues at once any longer: Color contrast warnings in the DevTools issues pane

Closing thoughts

Fixing this bug shows that when it comes to accessibility, a lot of the problems you need to fix are part of the interaction. A purely automated process can report a contrast issue on one element but we needed to take a look at all the available badges to fix the overall experience and not only one reported bug. We also learned that just because something wasn’t reported as an issue, doesn't mean everything works. Being diligent about accessibility means constantly checking all the features of your tool and not only new ones, especially when you deal with legacy products or those with several owners and contributors. The interesting thing here is that we didn’t any third party tool to inspect and fix the developer tools as the in-built contrast checker got us almost all the way where we needed to be. The Inspector tool is incredibly powerful as it doesn’t only show you all kind of information about the element like tag name, dimensions and padding but also gives you accessibility insights. In addition to the contrast information you also get the name and role of each element and a check if it is keyboard accessible or not. This is a great first check to ensure that the thing you see on screen is also available to users who can’t see it or aren’t able to use a touch screen or mouse. Accessibility testing isn’t about compliance—it means finding flaws in your product and fixing them for a certain need, and thus making everyone benefit. At Microsoft we’re lucky to have a dedicated team of testers and well established processes to ensure our products are accessible. But even lacking that, you can do a lot as a developer to ensure you don’t create barriers by checking your work using DevTools. If you like to learn more about the accessibility features in developer tools, head on over to our documentation, where we've recently launched a new accessibility testing guide to walk you through DevTools features you can use to test for accessibility issues. Watch this space, as there is a lot more to come! You can also always contact us on Twitter at @edgedevtools to ask questions or share feedback. Happy testing! – Patrick Brosset, Senior Software Engineer, Microsoft Edge DevToolsOverview of accessibility testing using DevTools]]>
Improving font rendering in Microsoft Edge Wed, 02 Jun 2021 16:00:36 +0000 Today we are excited to announce improved font rendering in the latest Canary builds of Microsoft Edge on Windows. We have improved the contrast enhancement and gamma correction to match the quality and clarity of other native Windows applications. F

The post Improving font rendering in Microsoft Edge appeared first on Microsoft Edge Blog.

What’s New? In the latest Canary builds, we now have support for applying the system settings for contrast enhancement and gamma correction of text. You can enable this with the edge://flags#edge-enhance-text-contrast flag. "Enhance text contrast" flag in edge://flags To experiment with different values, run the ClearType Text Tuner (search for "Adjust ClearType text" in the Start menu). Note that Edge must be restarted whenever the settings are changed, and that only the settings for your primary monitor are used. Screen capture of ClearType Text Tuner You can see the effect of the various choices you made in the tuner by viewing a demo page hosted on GitHub. Here is a comparison of the Edge default settings compared to the maximum settings: [caption id="attachment_24754" align="aligncenter" width="624"] Font rendering at default contrast level (100). Left is ClearType and right is Grayscale.[/caption] [caption id="attachment_24755" align="aligncenter" width="624"] Font rendering at maximum contrast level (400). Left is ClearType and right is Grayscale.[/caption] Behind the scenes, the registry key KEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAY1 is modified to a value between 50 and 400.

Technical Background

To give some context as to why this change was made, we need to look at how the Legacy Microsoft Edge rendered text. Like many native Windows applications, Legacy Microsoft Edge utilized the DirectWrite framework to render glyphs to the screen. The benefit of using DirectWrite is that certain system-wide user settings are respected and use the same rendering pipeline across all other native Windows applications. Chromium, by contrast, only utilizes DirectWrite for part of the text-rendering pipeline: font enumeration, glyph information retrieval, and glyph bitmap generation; it handles its own text shaping, layout, and rendering. This enables code reuse across platforms, but on Windows, the results are typically different than the rest of the system's text rendering. The final compositing of glyph bitmaps in Chromium is handled by the Skia graphics library and does not respect the Windows system settings for contrast enhancement and gamma correction of anti-aliased text. Consequently, font rendering with the hardcoded settings in Skia results in text that is subtly lighter than Windows' system defaults. The difference is even more pronounced on CJK characters, where anti-aliased pixels comprise a larger percentage of each rendered glyph.

Looking Ahead

Today, the changes described above must be manually enabled, but after a rollout period we plan to have this behavior enabled by default in the Edge 92 stable channel. Also, while these changes are specific to Edge, we hope to be able to contribute them back to Chromium so that all Chromium-based browsers on Windows enjoy a consistent font rendering experience. We would love to hear your feedback on whether these changes improve your reading experience and if it addresses your feedback around font clarity and contrast. If you have comments or suggestions, please reach out on Twitter @MSEdgeDev or send feedback via the Microsoft Edge Feedback Tool. As always, we will continue to listen to your feedback and look for ways to improve text rendering going forward. We think that this change will address some of the feedback around font clarity and contrast, and we will continue to look for ways to improve text rendering going forward. – Ben Mathwig, Program Manager, Microsoft Edge]]> 0
Available for preview: Automatic HTTPS helps keep your browsing more secure Tue, 01 Jun 2021 17:58:13 +0000 Starting with Microsoft Edge 92, users can preview the Automatic HTTPS feature, which automatically switches your connections to websites from HTTP to HTTPS.

As you browse the web, you may notice that the Microsoft Edge address bar displays a “not

The post Available for preview: Automatic HTTPS helps keep your browsing more secure appeared first on Microsoft Edge Blog.

When sites are loaded over HTTP, attackers can view or change page content in transit, or redirect you to a different location than you had expected. Most websites now support HTTPS, which can help protect against these man-in-the-middle attacks. However, too many of these sites aren’t configured to require HTTPS, leaving open a short window of opportunity for attackers before the site can redirect to the more secure protocol. Some sites may not redirect visits from HTTP to HTTPS at all, leaving some visitors with a less secure connection. To help protect your information as you browse, we are introducing a feature called Automatic HTTPS: now available for preview in Canary and Developer channels with Microsoft Edge 92. Automatic HTTPS switches your connections to websites from HTTP to HTTPS on sites that are highly likely to support the more secure protocol. The list of HTTPS-capable websites is based on Microsoft's analysis of the web, and helps enable a more secure connection on hundreds of thousands of top domains. Automatic HTTPS upgrades your connection only on HTTPS-capable domains by default in order to prevent connection errors and potential performance issues. This protocol switch process happens automatically and without intrusive notifications, so that you don’t have to think about your connection to websites—simply browse as usual! If you’d like even tighter security and don’t mind potentially encountering connection errors more frequently, you can opt to switch all navigations from HTTP to HTTPS using the toggle on edge://settings/privacy:

An Edge setting that says ‘Automatically switch to more secure connections with Automatic HTTPS’ is toggled on. The selected radio button beneath it reads ‘Always switch from HTTP to HTTPS (connection errors might occur more often)’

We're starting to experiment with this feature in our Canary and Dev preview channels for select users of Microsoft Edge 92. If you'd like to try out Automatic HTTPS and the experiment hasn’t reached you yet:
  1. Visit edge://flags/#edge-automatic-https in Edge 92 Canary/Dev and enable Automatic HTTPS
  2. Hit the “Restart” button that appears to restart Microsoft Edge.
  3. Visit edge://settings/privacy and turn on “Automatically switch to more secure connections with Automatic HTTPS”.
If you run into any issues or have any feedback, please use the in-app feedback button (or Alt+Shift+I) to share your thoughts!

Technical details

A broad scope of protection

Automatic HTTPS applies to all user navigations. Whether you type a URL in the address bar or click on a link that takes you to a new site, the feature will check whether to switch your connection to HTTPS. It doesn’t matter how you browse—Automatic HTTPS will help keep you secure.

The known-capable domains list

In addition to security, we know that productivity and performance are top of mind for our users. When enabled, Automatic HTTPS defaults to upgrading navigations only on domains that are likely to support HTTPS. Scoping to HTTPS-capable domains reduces the likelihood of connection failures, as well as potential performance or reliability issues with “try HTTPS first and fall back to HTTP” approaches. The list of HTTPS-capable domains is delivered to the user’s device via a browser component, and is listed on edge://components/. Microsoft generates the list based on top domains that receive a high rate of traffic delivered over HTTPS and are not configured to require HTTPS (i.e. are not already included in HSTS Preload Lists).

Reducing encountered errors with local caching

Some users may prefer that all navigations use HTTPS, and are okay with encountering error pages more frequently in exchange for heightened security. These resulting error pages will enable you to try the same URL delivered over HTTP instead: [caption id="attachment_24747" align="aligncenter" width="640"]An error page titled “This page isn’t working right now.” Subtext says that Automatic HTTPS switched your connection to HTTPS, and offers to try the same URL but with http://. An example of an error occurring on a site that is specially configured to force use of HTTP only.[/caption] Regardless of whether you have configured Automatic HTTPS to run on known-capable or all domains, the feature will locally cache recent domains that resulted in a navigation error. The next time you visit a cached site, Automatic HTTPS will skip the attempt to upgrade, avoiding duplicative error pages and keeping you focused on your browsing. Users can clear this cache by visiting edge://settings/privacy and clearing “Browsing history”. Any cache entries stored during an InPrivate session will automatically be cleared when leaving InPrivate.

Subresource upgrades

HTTPS best protects you when all resources are delivered over HTTPS—not just the top-level document shown in the address bar. “Active” content subresources can access some or all of the content on the page you’re visiting. If these are delivered over HTTP, an attacker might still be able to manipulate content on the page. At the same time, switching these to HTTPS can potentially lead to other errors if delivery over HTTPS is not supported for a given subresource. When Automatic HTTPS is configured to switch to HTTPS only on known-capable domains, the feature will upgrade same-host active subresources to HTTPS, as these are more likely to also support HTTPS. For example, on, would be upgraded, but and would not. Active content subresources in scope of this feature include scripts, iframe sources, and fetch() requests; you can find a longer list on MDN. The “always switch” setting once again is designed for heightened security: all active content subresources will be upgraded. Failures to load subresources (and thus some site breakage) may be more common.

Developer guidance

We recommend that website owners serve all content over HTTPS, including top-level documents and any subresources. Developers should also consider configuring their websites to require HTTPS, though that may not be feasible for all domains. If you have not configured your domain in this way, you can observe the effects of Automatic HTTPS on your own website. Hit F12 to pull up the DevTools, then bring up the Console tab. Under “Console settings”, enable “Preserve log”: “Preserve log” checkbox is checked in the Console settings tray. Then visit your site using the http:// scheme (e.g. If Automatic HTTPS switched your connection to HTTPS, a message will appear in the console: The console specifies ‘Automatic HTTPS switched your connection to HTTPS’ on The exact message that appears depends on whether any subresources were upgraded:
Scenario Console Message
The document switched to HTTPS, but no subresources were upgraded Automatic HTTPS switched your connection to HTTPS.”
The document switched to HTTPS, and same-host active subresources were upgraded because Automatic HTTPS is set to “upgrade on websites likely to support HTTPS” Automatic HTTPS switched your connection and same-host subresources to HTTPS.”
The document switched to HTTPS, and all active subresources were upgraded because Automatic HTTPS is set to “always switch” Automatic HTTPS switched your connection and subresources to HTTPS.”

Please share your feedback

We are keen to know what you think about Automatic HTTPS! If you run into any issues or have any feedback, please use the in-app feedback button (or Alt+Shift+I) to share your thoughts. You can also reach out to us on Twitter. Thanks for your feedback, and please stay tuned for updates on Automatic HTTPS. — Melanie Richards, Senior Program Manager — Kinam Park, Software Engineer — Deepak Narasimha Murthy, Software Engineer — Brandon Maslen, Senior Software Engineer]]>
What’s new for Microsoft Edge at Microsoft Build 2021 Tue, 25 May 2021 15:00:53 +0000 Welcome back to Microsoft Build! Wherever this finds you, we hope that you’re safe and healthy.

Since last Build, the Microsoft Edge platform continues to empower developers with the latest tools ready for today’s evolving web land

The post What’s new for Microsoft Edge at Microsoft Build 2021 appeared first on Microsoft Edge Blog.

State of the Platform video below, Program Managers Scott Low and Zoher Ghadyali detail what’s new and what’s improved on the Microsoft Edge web platform. So, what’s new for developers since Build last year?
  • WebView2 is generally available and is now included with WinUI 3: Over the last year, WebView2 has become generally available and is supported across app frameworks like Win32 C/C++, WPF/WinForms, and now WinUI 3! WebView2 is Microsoft’s embedded web control, built on top of Microsoft Edge (Chromium). WebView2 is decoupled from the Windows operating system and lets you combine the ease and agility of developing for the web with the power of building a native desktop application. Whether for web, hybrid, or native apps, WebView2 treats these supported app frameworks as first-class citizens so you can bring the best of the web to your apps.
  • Morgan Stanley embraces WebView2 to help future-proof their technology: Since we started working on WebView2, Morgan Stanley has been a close partner in giving feedback, helping us to ensure WebView2 is meeting business needs. By adopting WebView2, Morgan Stanley has given their employees the power of native app experiences combined with the latest web app technology. Using WebView2 keeps that web technology evergreen with updates and security, which was something that their previous Chromium containers solution couldn’t do.
  • WebView2 Runtime is more broadly available to power WebView2 apps: Whether you plan to develop WebView2 apps in a fixed or evergreen state, you’ll need the WebView2 runtime to support them. To support your WebView2 apps, we’re making the WebView2 Runtime available in more places—for example, through dedicated installers and future Windows releases—so that it’s ready for use by you and your users.
And, what’s improved?
  • 5,300 Chromium commits accepted: Making the web better for everyone is essential to our mission for Microsoft Edge. Since launch, we’ve had over 5,300 commits accepted back into the Chromium project so that many of the improvements we’ve worked on for Microsoft Edge can be experienced by others using a Chromium-based browser.
  • Edge Origins Trials continue, and expand: Announced last year and embraced by the developer community, our Edge Origins Trials program continues to offer new experiences for developers to test and preview—join hundreds of other developers in an Origin Trial by registering through
  • PWAs join the Microsoft Store: Progressive Web Apps (“PWAs”) built on the Microsoft Edge platform are now available in the Microsoft Store, and yours can be too! Broaden the reach of your PWA in 3 easy steps:
  1. Create an app reservation in the Windows Partner Center
  2. Package your PWA for Windows with
  3. Submit the package to the Microsoft Store for approval

Microsoft Edge takes performance to the next level

You care about the developer tools, but we also know that you want great experiences when people use your website or application—and browser performance is essential to that. Since last Build, we’ve added new features to boost browser performance and because of this Microsoft Edge will be the best performing browser on Windows 10 when Microsoft Edge version 91 releases later this week! So, why can we say this? It’s simple: Startup boost and sleeping tabs. First, Startup boost launches Microsoft Edge more quickly by running a set of core Microsoft Edge processes in the background, all without adding additional resources when Microsoft Edge browser windows are open. Turning on your computer and getting online with Microsoft Edge just became that much faster. Animation showing Sleeping Tabs in Microsoft Edge Second, the new sleeping tabs feature gives Microsoft Edge a performance boost when using multiple browser tabs simultaneously. It helps optimize the performance of your Microsoft Edge browser by freeing up system resources from unused tabs. This month, sleeping tabs is further improved and with up to 82% memory savings based upon internal data collected on our preview builds. It does so by immediately putting ads to sleep when you put tabs in the background for instant resource savings. Sleeping tabs also now has additional improvements to save system resources on Windows.

The future of Internet Explorer is in Microsoft Edge

Finally, you may have heard our recent announcement that the future of Internet Explorer on Windows 10 is in Microsoft Edge and that the Internet Explorer 11 (“IE11”) desktop application will be retired on June 15, 2022 for specific versions Windows 10. We know that catering to specific browsers are top pain points for you, so this news means that you will be able to focus more of your efforts on modern web experiences. But we didn’t leave your customers and users behind either. With Internet Explorer mode in Microsoft Edge, consumers and organizations will be able to use IE-based sites and apps alongside modern ones in Microsoft Edge—this is what we call the dual engine advantage in Microsoft Edge. Timeline showing the retirement date for IE11 on June 15th, 2022 With this retirement date set, we recommend you develop a plan to end support for IE11 for your websites and apps, and to stage a process to transition users from Internet Explorer over time and with easy pathways forward. When you’re ready, we can help you with this. When end users land on a website that is no longer supporting their go-to browser, it can be disruptive and jarring. We can help, with a guided transition process and a one-click option to bring over important user data like passwords and favorites. Learn more in the Moving users from Internet Explorer to Microsoft Edge article. Transitions are hard but can be made easier. For further details about this announcement, read our blog and check out our FAQ.

Enjoy Edge at Build

We hope you enjoy Microsoft Build this year and feel energized by all the new developer innovations! Don’t miss the following sessions to learn more about Microsoft Edge and WebView2: And to see all the developer resources related to Microsoft Edge, we’ve conveniently compiled everything for you here: Have a great Build!]]>
Preview Microsoft Math Solver in Microsoft Edge Fri, 21 May 2021 16:00:57 +0000 For many students, math can be a particularly challenging subject in school. Math is sequential, in that each lesson is part of the foundation for future learning. If students do not have a solid understanding of each concept as they go, it may impac

The post Preview Microsoft Math Solver in Microsoft Edge appeared first on Microsoft Edge Blog.

Canary, Dev, and Beta channels), navigate to the settings menu (…) in the top right corner of the browser, open More Tools and select Math Solver. Screen capture showing Math Solver We hope you enjoy Microsoft Math Solver during the preview phase. Please share your stories about your experience with the feature and if you have any suggestions for improvement. To provide feedback, please use the feedback option in the browser or take a short survey: Feedback survey for Math Solver. We look forward to introducing additional features to help students achieve better learning results. Thank you for joining us on this journey – we look forward to hearing from you!]]> 0
Joining forces on better browser compatibility in 2021 Mon, 22 Mar 2021 16:01:11 +0000 Over the past few years, Microsoft has partnered with a group of browser vendors and other industry stakeholders to identify and address the top sources of web developer pain through initiatives like the Joining forces on better browser compatibility in 2021 appeared first on Microsoft Edge Blog.

MDN Web Developer Needs Assessment (“Web DNA”), as well as through our own product approach with Microsoft Edge and our contributions to the Chromium project. The Web DNA results for the last two years have consistently highlighted browser compatibility as one of the top challenges faced by developers, and follow up research in the MDN Browser Compatibility Report and other channels has helped hone that signal into five areas where browser compatibility is a particularly strong pain point: CSS Flexbox, CSS Grid, CSS position: sticky, the CSS aspect-ratio property, and CSS transforms. We’re excited to join with Google, Igalia, and the broader web community in committing resources to a cross-browser effort called #Compat2021, with the goal of substantial improvements in each area.


For this project, our joint working group identified the focus areas above based on feature usage data, number of bugs (or number of stars/upvotes on a given bug) in each vendor’s tracking system, various survey feedback, CanIUse data, and test results from web-platform-tests. We then split focus among the working group to focus on areas in respective implementations. For example, the Microsoft Edge team intends to contribute fixes to Chromium to pass 100% of CSS Grid tests this year and to support work to improve interop across browsers, as well as assisting with triage in web-platform-tests. You can learn more about each focus area, including current pass rates and some of the factors included in our prioritization, over at Eliminating five top compatibility pain points on the web

Getting Involved

As we kick off this effort, we need your help making sure we catch the most important issues and getting the word out! If you are encountering compatibility issues in the areas listed above, please continue to file bugs in the appropriate tool (either via the “Send Feedback” tool in Microsoft Edge, or directly in the appropriate project: Chromium, Webkit, or Gecko). You can follow the project’s progress on the Compat 2021 Dashboard on web-platform-tests, subscribe to the public mailing list for updates, or follow @MSEdgeDev on Twitter for the latest updates from our team. We’re excited to participate in this initiative to make the web an even better place to build great experiences that work across browsers!]]> 0
Serving our customers more effectively with new release cycles for Microsoft Edge Fri, 12 Mar 2021 19:02:38 +0000 Innovation has been part of Microsoft Edge since day one, whether you’re seamlessly accessing corporate apps online for work or saving money shopping with built-in coupons. As contributors to the Chromium project, we look forward to Serving our customers more effectively with new release cycles for Microsoft Edge appeared first on Microsoft Edge Blog.

the new 4-week major release cycle cadence that Google announced, to help deliver that innovation to our customers even faster. For many, innovation can’t come fast enough! But that is not the case for all customers, particularly our enterprise customers who manage complex environments and must balance delivering new innovations against rigorous planning and testing. To help our enterprise customers looking for an extended timeline to manage updates, Microsoft Edge will offer an Extended Stable option aligned to a longer, 8-week major release cycle; if this option is not selected, the 4-week cadence will be the default experience. Enterprise customers opting for the Extended Stable option will still get all the great innovation and security from the 4-week cycles, just delivered at a more manageable pace. In between major releases, customers choosing the Extended Stable option can expect a biweekly security update with the most important fixes; everything else will be delivered on the extended schedule every eight weeks. This change in release cycles is expected to start with Edge 94—for more information on the 2021 release schedule, check out our updated Microsoft Edge Release Schedule page. This change will also be reflected on the Microsoft 365 Roadmap. With changes like this, we strive to provide clarity and transparency for our customers. Over the coming months, please refer to the Microsoft Edge Blog for additional details and updates to prepare for the release cycle that best fits your needs.]]> 0