Windows 10: Introducing Source Order Viewer in the Microsoft Edge DevTools

Brink · Sep 15, 2020

Last year, we joined a cross-industry effort by browser makers to better understand the needs of the web developer community, The Web We Want. One of the first needs validated through this effort was submitted by Adrian Roselli, who asked for a way to display the source order of elements on a page using developer tools.

Today, weâre happy to introduce a new experimental Source Order Viewer in the Microsoft Edge DevTools. You can try this today by enabling experimental DevTools features in canary builds of Microsoft Edge or Google Chrome (85 or newer).

Why source order matters

Adrian did a great job explaining the problem in his https://www.youtube.com/watch?v=UjXCAuWuXdk and in several other blog posts, but hereâs a quick recap:

With modern CSS layout techniques web designers have more power than ever before to break out of traditional layouts and bring new aesthetics to the web. The problem is that what is underneath is still important to many users. The order of the content in the page source, for example, is the only thing assistive technology like screen readers read out. Thatâs why you need to make sure that what is underneath makes as much sense as what you display on the screen.

Consider the following example:

See the Pen
Source order problem example by Christian Heilmann (@codepo8)
on CodePen.

Visually, everything appears to be in orderâit makes sense to put on socks, then a shirt, trousers and finally shoes. However, if you tab through the document using the keyboard, you get a different story.

Now itâs shoes first, then trousers, then shirt and finally socks, which doesnât align with the layout on the page, and may not be what you intended.

For sighted users, this may not cause that much confusion. However, for a user who depends on a screen reader, the content may no longer makes sense.

The culprit is that the source order in the document doesnât match what is displayed on screen. In the following code, the HTML orders the items using one hierarchy. Screen readers use this hierarchy.

However, the display order on the screen is defined in the CSS using display:flex and order:

Previously, the only way to test this was by navigating your page using the keyboard, or by testing with a screen reader. The new Source Order Viewer allows you to see the source order superimposed on the page. You can find the option to enable it in the accessibility pane of the DevTools.

With the Source Order Viewer overlay enabled, we can now see the list starting with 4 and going in reverse order, which signals that something is wrong. To solve this, we can fix the order of the elements in the HTML source to match their logical order, and re-arrange their visual order as needed via CSS â rather than the other way around.

Turning on the source order viewer experiment

You can try out the source order viewer today in a Canary build of Microsoft Edge by enabling experimental features. You can find detailed information on how to do that in the official documentation.

This is currently an experimentâweâd love to hear your thoughts about it and what we could do to improve the experience. You can reach the Edge Developer Tools team on Twitter as @edgedevtools, or contact us using the feedback mechanism built into the developer tools (Alt+Shift+I when the DevTools are open).

â Chris Heilmann, Principal Program Manager, Microsoft Edge
Click to expand...

Source: https://blogs.windows.com/msedgedev/...edge-devtools/

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

:)

Brink · Sep 15, 2020

Introducing the Microsoft Edge DevTools Protocol

Today’s web developers face more challenges than ever before. New frameworks spring up left and right. The number of devices capable of running the web multiply by the day. And we strive as creators to enable an inclusive and trustworthy world where fundamentals like accessibility, privacy, performance, and security are key to success.

These challenges are an opportunity for builders and consumers of devtools, requiring our solutions to enable innovation and scale. We need to provide web developers and tool vendors targeting Microsoft Edge, including other Microsoft teams, flexibility in solving these tough problems.

With the Windows 10 April 2018 Update, we’re taking the first major step on our journey by introducing the Microsoft Edge DevTools Protocol, a set of REST and JSON-RPC/WebSocket APIs, which enable clients to diagnose and debug Microsoft Edge tabs. In addition, we’ve worked with our teammates from Visual Studio, Visual Studio Code, and the Microsoft Edge DevTools to integrate with, and validate the interoperability of, these new capabilities within those apps.

In this post, we’ll elaborate on why we’ve taken this approach and the exciting progress we’ve made so far. We’ll provide resources throughout to help you get started using these new technologies. At the end, we’ll look at our next steps and share the many ways you can provide feedback to help us shape the future of the Microsoft Edge DevTools Protocol.

Get started with the new local and remote debugging scenarios with the new documentation from aka.ms/edp-docs. Requries the Windows 10 April 2018 Update or the Microsoft Edge DevTools Preview app.

Rebooting the Microsoft Edge DevTools platform

A year ago, we set out to re-architect the Microsoft Edge DevTools platform with two general customer scenarios in mind: growing the number of devtools that work with Microsoft Edge, and expanding support for debugging Microsoft Edge on new device form factors.

Expanding opportunities in local and remote scenarios is a key motivator for the new architecture. More details on the components in the diagram above are provided below.

To tackle the realities described above and achieve both local and remote support, we came up with a short but impactful list of guiding principles:

Decouple the platform and client components and release the client separately to allow for faster UX improvements and innovations

Build the platform interfaces on standard technologies to foster a larger ecosystem of devtools with support for Microsoft Edge

Build the platform in a way which allows devtools running locally to target instances of Microsoft Edge on remote Windows devices

Align with other browser vendors to support ecosystem portability and efficiency

This work will span multiple releases, but we’ve already made some exciting progress. Let’s dive in.

Decoupling the Microsoft Edge DevTools platform and client

To enable us to deliver customer value more rapidly, we first looked to take the Microsoft Edge DevTools app and ship it separately from the Windows OS as a Store application.

But to ship via the Microsoft Store, we needed to build only on APIs which are publicly available to others. This lead to the creation of the new Edge DevTools Protocol (EDP). The protocol is comprised of two sets of APIs: REST and JSON-RPC via WebSocket. Through EDP, devtools can build experiences around invoking methods and subscribing to diagnostics and debugger events.

The REST APIs are primarily used to discover information about EDP such as the version, available targets, and the supported API surface. All response values are formatted as JSON objects.

An example of the return object from the /list REST API.

The WebSocket APIs are used to issue debugger and diagnostics commands and subscribe to correlated events. The APIs are broken down into Domains, which further break down into Methods, Events, and Types. A simple example would be the Debugger.setBreakpointByUrl API. A client would issue a JSON-RPC command looking something like this to set a breakpoint based on a JS file URL and location:

[table][tr][td][/td] [td]{[/td] [/tr] [tr][td][/td] [td] "id":209,[/td] [/tr] [tr][td][/td] [td] "method":"Debugger.setBreakpointByURL",[/td] [/tr] [tr][td][/td] [td] "params": {[/td] [/tr] [tr][td][/td] [td] "lineNumber": 15,[/td] [/tr] [tr][td][/td] [td] "url": "https://www.foo.com/content.js",[/td] [/tr] [tr][td][/td] [td] "columnNumber": 30,[/td] [/tr] [tr][td][/td] [td] "condition": ""[/td] [/tr] [tr][td][/td] [td] }[/td] [/tr] [tr][td][/td] [td]}[/td] [/tr] [/table]

By switching to this publicly documented APIs, we’ve begun the process of shipping a new Microsoft Edge DevTools Preview app which runs in part on EDP. You can read more about the new DevTools Preview app here.

Fostering an ecosystem of Microsoft Edge DevTools

By decoupling the client from the platform, we’ve started the work to achieve our second goal of enabling an ecosystem of devtools which support Microsoft Edge. HTTP and WebSocket are ubiquitous technologies in native and web development environments. This means clients written in many programming languages can integrate. We hope this vastly reduces the barriers to entry for those who want to build devtools for Microsoft Edge.

In addition to calling APIs, from within those tools developers will need a way to launch the Microsoft Edge DevTools Server. We’re excited to announce that in the April 2018 update, we’ve introduced a new command line parameter and Edge UX for doing that. Check out the capture below for a preview of that experience:

The animated gif above shows the new Microsoft Edge DevTools server command-line launching functionality added in the Windows 10 April 2018 update.

These command-line parameters for launching the Microsoft Edge DevTools Server, along with available HTTP and WebSocket APIs, can be found in the Microsoft Edge DevTools Protocol documentation. Combined, these capabilities enable developers to more easily build devtools which target Edge.

To prove the viability of this approach, we on the Web Platform team partnered with the Visual Studio and Visual Studio Code teams to support F5 debugging of JavaScript running in a Microsoft Edge tab. We look forward to sharing more about that experience in a future post.

Supporting remote debugging

In addition to wanting to foster a community of devtools which target Microsoft Edge, we want to enable those tools to target Microsoft Edge running on a remote Windows device. Though this specific scenario is not yet supported, it shows our long-term thinking:

Imagine you’re a HoloLens developer working with WebVR. Trying to debug your web app in Microsoft Edge on the HoloLens would likely be a time-consuming activity. Without a mouse and keyboard, navigating of devtools would be a cumbersome experience. Much better would be to run devtools on your local dev machine and remotely target Microsoft Edge instances running directly on the HoloLens.

To accomplish that, we built a plugin for the Windows Device Portal (WDP) which hosts the same Microsoft Edge DevTools Server that runs locally when launched via the command-line utility explained above. When you enable WDP in the Windows For developer settings, this will automatically install and activate the EDP plugin.

With your device in Developer mode and the Windows Device Portal turned on, the EDP plugin is automatically installed and HTTP and WebSocket servers started.

Using the Remote tab in the new Microsoft Edge DevTools preview app, you can connect to a remote device, view its targets, and connect to and debug them. You can read more about that here and here.

Note: At this point we support remote devices (and virtual machines) running the Windows 10 April 2018 Update or higher on PCs.

Aligning with the devtools protocol community

When we set out to build the devtools protocol for Microsoft Edge, we had a choice: build something which aligns with industry precedents or create our own approach tailored for our browser. The choice was obvious to us so we opted to align with the Chrome DevTools Protocol (CDP).

In the early winter of 2017, we met with fellow web experts from Google, Mozilla, Apple, VS Code, and others to discuss how better to align our work around devtools protocols. The result of that discussion is the DevTools Protocol Web Platform Incubator Community Group (WICG). Through this new group, we hope to publicly explore what alignment looks like and how best we as devtools protocol vendors can benefit the community.

Participants from Google, Mozilla, Microsoft, and VS Code drove the first draft of the WICG goals.

Separate from the WICG, we’ve worked hard as we’ve implemented EDP to validate that our API surface and method/event semantics mirror CDP. By releasing version 0.1 with support for three clients (Visual Studio Code, Visual Studio, and Edge DevTools preview app), we’ve achieved a high degree of interoperability. Where needed due to platform differences, we’ve introduced Microsoft Edge-specific methods and properties, all prefixed with ms and safely ignorable by any client not requiring them.

Lastly, though we’ve committed to testable interoperability, we know there will be bugs, and we hope you will help us find them! We look forward to your feedback as you build great devtools using EDP.

Next steps

This release is the first major step on a multi-milestone journey. We’re passionately committed to building the best Microsoft Edge developer tools and platform APIs to enable our customers to be more efficient and to fix bugs in Microsoft Edge. In terms of what’s next for EDP, here’s a quick look:

More devtools: we have more features to migrate to EDP within the Microsoft Edge DevTools, and are actively migrating the most-used tools to the new APIs. In parallel, we’re investigating how tools like Sonarwhal and WebDriver can integrate, as well.

More devices: the first release supports Windows Desktop SKU devices (including VMs of that flavor), and we plan to expand the Windows SKUs and devices supported for remote debugging.

Interop improvements: as more devtools on-board and we grow our API surface, we’ll continue to invest in ensuring we’re working with the larger DevTools Protocol community to align our efforts.

That’s a rough and quick run through our thoughts about the future. We’ll continue to evolve these priorities as we interact with our developer communities to build new platform capabilities together.

Providing feedback

If you’d like to provide feedback, we’d love to hear it and recommend several channels:

Feedback Hub: You can file feedback using the Microsoft Edge category and the Developer tools sub-category in the Feedback Hub app on Windows 10—just press Win+F to get started. Whether it’s a bug or suggestion, this is the easiest way for us to receive, track, and communicate around issues you bring to our attention.

Edge DevTools UserVoice: We monitor and use requests as an important signal informing what we do, and to help prioritize the order in which we implement new features. Please add requests or upvote your favorites.

Thanks for taking the time to learn about the new Microsoft Edge DevTools Protocol and our vision for a rich ecosystem of Microsoft Edge devtools. We hope you’re as excited as we are. Happy coding!

– Brendyn Alexander, Senior Program Manager
Click to expand...

Source: Introducing the Microsoft Edge DevTools Protocol - Microsoft Edge Dev Blog

Brink · Sep 15, 2020

Introducing the Microsoft Edge DevTools Protocol

Today’s web developers face more challenges than ever before. New frameworks spring up left and right. The number of devices capable of running the web multiply by the day. And we strive as creators to enable an inclusive and trustworthy world where fundamentals like accessibility, privacy, performance, and security are key to success.

These challenges are an opportunity for builders and consumers of devtools, requiring our solutions to enable innovation and scale. We need to provide web developers and tool vendors targeting Microsoft Edge, including other Microsoft teams, flexibility in solving these tough problems.

With the Windows 10 April 2018 Update, we’re taking the first major step on our journey by introducing the Microsoft Edge DevTools Protocol, a set of REST and JSON-RPC/WebSocket APIs, which enable clients to diagnose and debug Microsoft Edge tabs. In addition, we’ve worked with our teammates from Visual Studio, Visual Studio Code, and the Microsoft Edge DevTools to integrate with, and validate the interoperability of, these new capabilities within those apps.

In this post, we’ll elaborate on why we’ve taken this approach and the exciting progress we’ve made so far. We’ll provide resources throughout to help you get started using these new technologies. At the end, we’ll look at our next steps and share the many ways you can provide feedback to help us shape the future of the Microsoft Edge DevTools Protocol.

Get started with the new local and remote debugging scenarios with the new documentation from aka.ms/edp-docs. Requries the Windows 10 April 2018 Update or the Microsoft Edge DevTools Preview app.

Rebooting the Microsoft Edge DevTools platform

A year ago, we set out to re-architect the Microsoft Edge DevTools platform with two general customer scenarios in mind: growing the number of devtools that work with Microsoft Edge, and expanding support for debugging Microsoft Edge on new device form factors.

Expanding opportunities in local and remote scenarios is a key motivator for the new architecture. More details on the components in the diagram above are provided below.

To tackle the realities described above and achieve both local and remote support, we came up with a short but impactful list of guiding principles:

Decouple the platform and client components and release the client separately to allow for faster UX improvements and innovations

Build the platform interfaces on standard technologies to foster a larger ecosystem of devtools with support for Microsoft Edge

Build the platform in a way which allows devtools running locally to target instances of Microsoft Edge on remote Windows devices

Align with other browser vendors to support ecosystem portability and efficiency

This work will span multiple releases, but we’ve already made some exciting progress. Let’s dive in.

Decoupling the Microsoft Edge DevTools platform and client

To enable us to deliver customer value more rapidly, we first looked to take the Microsoft Edge DevTools app and ship it separately from the Windows OS as a Store application.

But to ship via the Microsoft Store, we needed to build only on APIs which are publicly available to others. This lead to the creation of the new Edge DevTools Protocol (EDP). The protocol is comprised of two sets of APIs: REST and JSON-RPC via WebSocket. Through EDP, devtools can build experiences around invoking methods and subscribing to diagnostics and debugger events.

The REST APIs are primarily used to discover information about EDP such as the version, available targets, and the supported API surface. All response values are formatted as JSON objects.

An example of the return object from the /list REST API.

The WebSocket APIs are used to issue debugger and diagnostics commands and subscribe to correlated events. The APIs are broken down into Domains, which further break down into Methods, Events, and Types. A simple example would be the Debugger.setBreakpointByUrl API. A client would issue a JSON-RPC command looking something like this to set a breakpoint based on a JS file URL and location:

[table][tr][td][/td] [td]{[/td] [/tr] [tr][td][/td] [td] "id":209,[/td] [/tr] [tr][td][/td] [td] "method":"Debugger.setBreakpointByURL",[/td] [/tr] [tr][td][/td] [td] "params": {[/td] [/tr] [tr][td][/td] [td] "lineNumber": 15,[/td] [/tr] [tr][td][/td] [td] "url": "https://www.foo.com/content.js",[/td] [/tr] [tr][td][/td] [td] "columnNumber": 30,[/td] [/tr] [tr][td][/td] [td] "condition": ""[/td] [/tr] [tr][td][/td] [td] }[/td] [/tr] [tr][td][/td] [td]}[/td] [/tr] [/table]

By switching to this publicly documented APIs, we’ve begun the process of shipping a new Microsoft Edge DevTools Preview app which runs in part on EDP. You can read more about the new DevTools Preview app here.

Fostering an ecosystem of Microsoft Edge DevTools

By decoupling the client from the platform, we’ve started the work to achieve our second goal of enabling an ecosystem of devtools which support Microsoft Edge. HTTP and WebSocket are ubiquitous technologies in native and web development environments. This means clients written in many programming languages can integrate. We hope this vastly reduces the barriers to entry for those who want to build devtools for Microsoft Edge.

In addition to calling APIs, from within those tools developers will need a way to launch the Microsoft Edge DevTools Server. We’re excited to announce that in the April 2018 update, we’ve introduced a new command line parameter and Edge UX for doing that. Check out the capture below for a preview of that experience:

The animated gif above shows the new Microsoft Edge DevTools server command-line launching functionality added in the Windows 10 April 2018 update.

These command-line parameters for launching the Microsoft Edge DevTools Server, along with available HTTP and WebSocket APIs, can be found in the Microsoft Edge DevTools Protocol documentation. Combined, these capabilities enable developers to more easily build devtools which target Edge.

To prove the viability of this approach, we on the Web Platform team partnered with the Visual Studio and Visual Studio Code teams to support F5 debugging of JavaScript running in a Microsoft Edge tab. We look forward to sharing more about that experience in a future post.

Supporting remote debugging

In addition to wanting to foster a community of devtools which target Microsoft Edge, we want to enable those tools to target Microsoft Edge running on a remote Windows device. Though this specific scenario is not yet supported, it shows our long-term thinking:

Imagine you’re a HoloLens developer working with WebVR. Trying to debug your web app in Microsoft Edge on the HoloLens would likely be a time-consuming activity. Without a mouse and keyboard, navigating of devtools would be a cumbersome experience. Much better would be to run devtools on your local dev machine and remotely target Microsoft Edge instances running directly on the HoloLens.

To accomplish that, we built a plugin for the Windows Device Portal (WDP) which hosts the same Microsoft Edge DevTools Server that runs locally when launched via the command-line utility explained above. When you enable WDP in the Windows For developer settings, this will automatically install and activate the EDP plugin.

With your device in Developer mode and the Windows Device Portal turned on, the EDP plugin is automatically installed and HTTP and WebSocket servers started.

Using the Remote tab in the new Microsoft Edge DevTools preview app, you can connect to a remote device, view its targets, and connect to and debug them. You can read more about that here and here.

Note: At this point we support remote devices (and virtual machines) running the Windows 10 April 2018 Update or higher on PCs.

Aligning with the devtools protocol community

When we set out to build the devtools protocol for Microsoft Edge, we had a choice: build something which aligns with industry precedents or create our own approach tailored for our browser. The choice was obvious to us so we opted to align with the Chrome DevTools Protocol (CDP).

In the early winter of 2017, we met with fellow web experts from Google, Mozilla, Apple, VS Code, and others to discuss how better to align our work around devtools protocols. The result of that discussion is the DevTools Protocol Web Platform Incubator Community Group (WICG). Through this new group, we hope to publicly explore what alignment looks like and how best we as devtools protocol vendors can benefit the community.

Participants from Google, Mozilla, Microsoft, and VS Code drove the first draft of the WICG goals.

Separate from the WICG, we’ve worked hard as we’ve implemented EDP to validate that our API surface and method/event semantics mirror CDP. By releasing version 0.1 with support for three clients (Visual Studio Code, Visual Studio, and Edge DevTools preview app), we’ve achieved a high degree of interoperability. Where needed due to platform differences, we’ve introduced Microsoft Edge-specific methods and properties, all prefixed with ms and safely ignorable by any client not requiring them.

Lastly, though we’ve committed to testable interoperability, we know there will be bugs, and we hope you will help us find them! We look forward to your feedback as you build great devtools using EDP.

Next steps

This release is the first major step on a multi-milestone journey. We’re passionately committed to building the best Microsoft Edge developer tools and platform APIs to enable our customers to be more efficient and to fix bugs in Microsoft Edge. In terms of what’s next for EDP, here’s a quick look:

More devtools: we have more features to migrate to EDP within the Microsoft Edge DevTools, and are actively migrating the most-used tools to the new APIs. In parallel, we’re investigating how tools like Sonarwhal and WebDriver can integrate, as well.

More devices: the first release supports Windows Desktop SKU devices (including VMs of that flavor), and we plan to expand the Windows SKUs and devices supported for remote debugging.

Interop improvements: as more devtools on-board and we grow our API surface, we’ll continue to invest in ensuring we’re working with the larger DevTools Protocol community to align our efforts.

That’s a rough and quick run through our thoughts about the future. We’ll continue to evolve these priorities as we interact with our developer communities to build new platform capabilities together.

Providing feedback

If you’d like to provide feedback, we’d love to hear it and recommend several channels:

Feedback Hub: You can file feedback using the Microsoft Edge category and the Developer tools sub-category in the Feedback Hub app on Windows 10—just press Win+F to get started. Whether it’s a bug or suggestion, this is the easiest way for us to receive, track, and communicate around issues you bring to our attention.

Edge DevTools UserVoice: We monitor and use requests as an important signal informing what we do, and to help prioritize the order in which we implement new features. Please add requests or upvote your favorites.

Thanks for taking the time to learn about the new Microsoft Edge DevTools Protocol and our vision for a rich ecosystem of Microsoft Edge devtools. We hope you’re as excited as we are. Happy coding!

– Brendyn Alexander, Senior Program Manager
Click to expand...

Source: Introducing the Microsoft Edge DevTools Protocol - Microsoft Edge Dev Blog

Brink · Sep 15, 2020

Introducing the Microsoft Edge DevTools Preview app

Last fall at the Microsoft Edge Web Summit, we laid out our plans for rebooting the Microsoft Edge DevTools in response to your feedback. Today we’re announcing the availability of the DevTools as a web app from the Microsoft Store. The new Microsoft Edge DevTools Preview app allows you to preview the very latest DevTools running side by side with the tools included in Microsoft Edge.

You can install the DevTools Preview app on Windows 10 Fall Creators Update or newer. Because the DevTools Preview app is based on the most recent Insider Preview version of the Microsoft Edge DevTools, this allows you to use the most recent updates to the Microsoft Edge DevTools without installing a full Insider release.

In addition, some new features will be exclusive to the app – such as debugging outside of the local browser, including web content in apps and remote debugging devices.

Debugging the web outside of the browser

When we think of the web, we largely think of browsers. But the web shows up on many more surfaces than just the browser in Windows: WebViews in apps, add-ins for Office, Cortana, Progressive Web Apps in the Microsoft Store, and many more places. The DevTools preview app gives you the ability to attach the tools to any instance of the EdgeHTML engine on Windows to debug.

The DevTools Preview app allows you to attach the Microsoft Edge DevTools to any local or remote EdgeHTML target.

Debugging remote devices

The web also runs on devices other than your dev machine. How do you debug the web on an Xbox, HoloLens, or an IoT device? One of the first features we’re previewing in the new DevTools app is remote debugging. By enabling Device Portal in the Settings app, you can now connect to that device over the network or via USB to debug remotely from the DevTools Preview app.

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

Building a DevTools protocol for an ecosystem of tools

One of the biggest changes to the DevTools isn’t visible in a screenshot – the new Microsoft Edge DevTools Protocol. Previously, the Microsoft Edge DevTools worked via invasive native hooks into the EdgeHTML and Chakra engines. This made it hard for other tools like VS, VS Code, Sonarwhal, and other open source tools in the ecosystem to support Microsoft Edge.

We started a conversation with other browsers last fall to incubate DevTools protocols at the W3C, with the goal of promoting interoperability between engines and allowing tools to support cross-browser debugging more easily.

The new DevTools app uses EDP to remotely debug Microsoft Edge today, and, eventually, all of our DevTools will use EDP. We’ll share more about EDP and our roadmap for additional tools in a future blog post.

The future of the Microsoft Edge DevTools

We’ve heard your feedback on the DevTools and we’re investing to make them great. Over the next several releases, we’ll evolve our tools based on your feedback. We encourage you to try out the DevTools Preview app, file feedback (just click the Smile icon in the DevTools), and reach out to us on Twitter with any comments!

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

– Jacob Rossi, Principal PM Lead, Microsoft Edge DevTools
Click to expand...

Source: Introducing the Microsoft Edge DevTools Preview app - Microsoft Edge Dev Blog

Windows 10: Introducing Source Order Viewer in the Microsoft Edge DevTools

Introducing Source Order Viewer in the Microsoft Edge DevTools

Introducing Source Order Viewer in the Microsoft Edge DevTools

Introducing Source Order Viewer in the Microsoft Edge DevTools

Introducing Source Order Viewer in the Microsoft Edge DevTools - Similar Threads - Introducing Source Order

Microsoft Edge Devtools

Introducing Microsoft Edge Kids Mode

Introducing web capture for Microsoft Edge

Microsoft improving DevTools accessibility in Microsoft Edge

Microsoft Edge DevTools now available to more languages

List of DevTools in new Microsoft Edge (Chromium)

Introducing the Microsoft Edge DevTools Protocol

Introducing the Microsoft Edge DevTools Preview app

Introducing Microsoft Edge Dev