Microsoft Edge Developer

Hi, are you a web developer or designer?

“No, I just want to share feedback on Microsoft Edge.”

Please use the Feedback Hub (requires Windows 10) to submit your feedback in the Microsoft Edge category. This site is for web developer and designer feedback only. Other feedback will be closed without action.

“Yes, I’m a web developer or designer with feedback for the Microsoft Edge platform.”

Great! This site is where the Microsoft Edge team collects feature requests from the web developer and designer community in the categories listed to the right. For bugs on existing features, please log an issue on the Issue Tracker.

Your feedback will help us with planning and to better understand how web developers and designers are using the platform. Top standards-based feature requests will also be copied over to status.microsoftedge.com, where you can track its development status.

For the most actionable feedback, please search and up vote for existing suggestions before submitting a new suggestion, and create a separate suggestion per idea. Note that off topic or inappropriate suggestions may be moderated. The Microsoft Edge team will use suggestions as an important input, but there are several additional factors that inform the final roadmap.

A note from our lawyers: Please do not send any novel or patentable ideas, copyrighted materials, samples or demos which you do not want to grant a license to Microsoft. See the Terms of Service for more information.

How can we improve the Microsoft Edge developer experience?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

Just like it happens for OSX/iOS, where attaching a device via USB or connecting via wifi allows to use desktop safari to inspect mobile safari and webviews on the mobile. All other browsers support this but Edge.

I know weinre was recently adapted to be usable on Edge mobile too but it's hardly a complete solution for serious development, lacking support for breakpoints, CSS pseudo-element.

Not to mention that I did encounter really strange behaviors of the DOM inspection panel based on when the weinre resources are loaded during JavaScript execution, something that is not acceptable to develop modern SPA web application.

Just like it happens for OSX/iOS, where attaching a device via USB or connecting via wifi allows to use desktop safari to inspect mobile safari and webviews on the mobile. All other browsers support this but Edge.

I know weinre was recently adapted to be usable on Edge mobile too but it's hardly a complete solution for serious development, lacking support for breakpoints, CSS pseudo-element.

Not to mention that I did encounter really strange behaviors of the DOM inspection panel based on when the weinre resources are loaded during JavaScript execution, something that is not acceptable to develop modern SPA…

This feature would enable the emulation of different network connections such as 3G, 4G etc... changing network throughput, latency and packet loss to match typical conditions for that type of network.

Proposed Design
- Impacts just the page being debugged
- Dropdown on emulation tool to select from the different connection options (exact list tbd)
- Fits in with the persistence of the rest of the emulation settings

Proposed Design
-Mark HTTP requests that are upgraded to WS in the summary grid
-Add a WS Frames tab in the details view to display the data
-Frames panel displays plains text data and calls out binary opcodes and origin of the data

We’ve started work on edit and continue in the F12 debugger. It’s going to take us a while as it’s a complex feature with many moving parts. The first part we’ll tackle is applying changes when you’re not at a breakpoint. So you could do something such as editing an event listener then trigger the event again. No dates for when, or if, we’ll be able to deliver it.

This feature would add the ability to dock F12 to the left side of the IE window.

Proposed Design
- Extend the current horizontal explorer bar system that F12 uses to cover the vertical scenario
- Additional dropdown for docking to indicate the different options (right, bottom, left)
- No top docking as the explorer bar system doesn't support it (and it's less important as windows are commonly side by side not bottom to top)
- Not mirrored (i.e. no support for RTL)
- Each tool in F12 will have to adjust their layout to cope with the change

There is currently, as far as I can see, no way to view the layout of printed document and the CSS styles that will be applied when printed. In Chrome you can choose to emulate @media print mode and inspect the document.

I am trying to debug why the text of a document printed from Chrome and IE11 has such wildly different text sizes but I cannot trace the font-size styles in IE to compare it to the font-size in Chrome.

This feature would extend the DOM tree in the DOM Explorer to include pseudo element as selectable elements (as if they were real nodes) so that the styles applied to them can be applied.

Proposed Design

- Items appear in the tree surrounded by a delimiter that indicates the 'pseudo' (e.g. :before)
- The node is selectable and once selected the CSS styles panes should be updated to reflect the style of the pseudo element the events pane should be empty
- All of the commands that impact the tree should be disabled (cut, copy, paste, add attribute, delete, etc.)

[Edited by Andy Sterland [MSFT] to clarify the idea and move it to the F12 category. Original text from Clayton Martin below.]
Support ::before and ::after pseudo elements and display them in the F12 DOM Explorer for inspection.

This feature would extend the DOM tree in the DOM Explorer to include pseudo element as selectable elements (as if they were real nodes) so that the styles applied to them can be applied.

Proposed Design

- Items appear in the tree surrounded by a delimiter that indicates the 'pseudo' (e.g. :before)
- The node is selectable and once selected the CSS styles panes should be updated to reflect the style of the pseudo element the events pane should be empty
- All of the commands that impact the tree should be disabled (cut, copy, paste, add attribute, delete, etc.)

Testing Edge on localhost can sometimes be a pain. Especially when we load resources from CDNs (like our own). In a mixed localhost / cdn Environment one will always see "This Internet Explorer instance does not have privateNetworkClientServer capabilities", which is a) misleading, since i'm using edge, not IE and is frustrating, since there is no internal Workaround. Fiddler allows me to remap mylocalhost to localhost, which solves the Problem, but I - as a developer - would like to just use it for development, as I do with all my other Browsers.

SystemJS is a polyfill for and extension to the ES6/ES2015 Module Loader (System). It tries its best to pass along Source Maps and Chrome today works alright with SystemJS, but today IE/Edge doesn't seem able to work with these source files. Some of this might be assuaged as IE/Edge implements the ES6/ES2015 Module Loader, but until such time, it would be great if the Dev Tools supported Source Maps in the way that SystemJS is outputting them in a stronger fashion.

When you're working with multiple scripts, especially with source maps (eg from TypeScript) Google Chrome dev tools shows a folder structure in the left hand side of the sources tab. IE F12 developer tools just shows a list of all the .js files.....

This is incredibly difficult to navigate! Especially if you have two or more files with the same name, in different folders (for us, it's _index.js and _module.js)....

Can you please add a folder like tree structure, mimicking the behaviour in Chrome Dev Tools?