WebView2Feedback is where Edge WebView2 developers report bugs, and the labels tell you what will happen

What this repository is for

The WebView2Feedback repository is the place for all developers of Microsoft Edge WebView2 to report bugs, make feature requests, and ask questions and have discussions about WebView2.

That is the whole of it. There is no library here, no sample project and no build. The top level of the repository holds a .github/ directory, the README, a SECURITY.md, and three content directories, best-practices/, diagnostics/ and specs/.

The primary language is recorded as PowerShell and the licence as one GitHub cannot classify, which reflects what the repository is. It is a tracked issue queue with some documentation attached, not a codebase.

The WebView2 runtime itself is what the rest of the ecosystem is built on: it is the embedded browser engine that a Win32, WinUI or WPF application uses to render web content, and the SDK for it is where most developers first encounter the product. The homepage given here is aka.ms/webview2, and the documentation lives at aka.ms/webview.

The repository exists because WebView2 ships as part of the Edge browser rather than as a separately versioned runtime, which means there is no single changelog, no separate issue tracker and no per-version announcement feed for the people embedding it. Everything lands in one place, which is convenient for Microsoft and slightly awkward for developers.

It is worth noting that the repository is not archived and the last push was on 2026-09-30, so the tracker is live even though the content is mostly issue metadata.

The two reporting flows and why the search comes first

There are two distinct flows in the README, one for bugs and one for feature requests, and they follow the same three-step shape.

For a bug, step one is to search for existing open bugs to avoid duplicates. If you find that your bug is already reported, give it a thumbs up reaction and add a comment with additional details that may help the team investigate. If it is not already reported, open a new issue.

For a feature request, the same sequence applies. Search for existing feature requests, and if you find a similar one, react to it and provide additional context into how you would use the feature. If the feature is not already requested, open a new issue.

The emphasis on reacting and commenting rather than opening a duplicate is a real signal about how the triage works. The team is tracking issues on an internal backlog, and a reaction with additional detail is a stronger input to that backlog than another copy of the same report, because it tells them how many people hit the problem without adding work to triage.

The third step in both flows is the same sentence: tracked issues will be labeled with the `tracked` label, and if you see this label, the team is aware of the issue and is tracking it on their internal backlog.

So the state of a report is visible in the label. No label means not yet acknowledged. Tracked means acknowledged and queued. The two other labels cover the cases in between.

What the three labels actually mean

The README explains the labels, and this is the most operationally useful part of the document.

The `tracked` label means the team has acknowledged the issue and is tracking it on their internal backlog, and that they will consider and investigate it in the near future. For bugs it means they think it is an actual product issue. For feature requests it means they consider it a valid request.

The `regression` label means a behavior that used to work in a previous version of WebView2 but no longer works as expected, and the team will prioritise this issue higher.

The `priority-low` label means the team has considered the issue and decided they will not be able to address it in the near future. Developers are welcome to provide justifications on the issue for the team to revisit the prioritisation.

That last one is a mechanism worth using rather than resenting. A priority-low label is a statement about staffing rather than about merit, and the invitation to argue the case on the issue thread is how a developer finds out whether their case changes the decision or merely repeats it.

The three labels together form a small triage vocabulary: acknowledged and queued, acknowledged and deprioritised, and confirmed as a regression with a higher bar. A bug that is a regression is materially more likely to be fixed in a near-term runtime update, and a WebView2 user who can establish that is doing something genuinely useful.

A separate mechanism exists for questions. Asking a question goes through the discussions area with the q-a category, and general conversation about WebView2 with other developers happens in the discussions area itself.

Announcements live somewhere else, which is the part that trips people up

Because WebView2 ships inside Edge, there is no single place where you can read what changed. The repository handles that by pointing at a separate one.

The README asks you to subscribe to WebView2Announcements for news, API proposals and SDK release announcements.

So the division is: this repository is where you report and discuss, and the announcements repository is where Microsoft tells you what changed. A developer who watches only one of the two will either miss releases or be drowned in issue threads.

The SDK documentation at aka.ms/webview is the third piece, and it is where the actual API reference lives.

That three-way split is the main practical thing to set up before you need it. Subscribe to the announcements feed, keep the documentation bookmarked, and use this tracker only when you have something specific to report. The alternative, which is what a lot of teams end up doing, is to find out about a breaking change when a feature stops working in a customer environment.

It is also worth noting what this repository does not do. There is no changelog file, no version listing and no code, so if you are looking for the WebView2 SDK source, samples or a release notes list, none of it is here.

The content directories, and where the useful reading is

Three directories at the root hold the non-issue content, and their names tell you what kind of content they carry.

best-practices/ is the one most likely to save you time before you file anything. The diagnostic path for most WebView2 problems is to check the recommended configuration and then look at what the runtime is actually doing, and a best-practices document is the first place to look because the majority of reported problems turn out to be a configuration question rather than a defect.

diagnostics/ is the second. WebView2 debugging has a specific vocabulary, environment variables, browser arguments, DevTools configuration, and the diagnostics content is where the tooling for that lives. It is the content to read when you have a bug report but no idea what state the runtime is in, and the failure mode of an undiagnosed WebView2 issue is a long exchange of comments asking for the same information.

specs/ is the third, and it is where API proposals and specifications are discussed, which connects to the announcements repository, which carries API proposals and SDK release announcements. A feature request that has become a proposal would appear on both sides.

So the reading order that saves the most time is best-practices, then diagnostics, then search the open issues with the bug label before filing.

The repository also carries a SECURITY.md, which is the file to read if you have found a vulnerability in WebView2 rather than a bug, and the Microsoft Open Source Code of Conduct is the stated code of conduct for the project.

Where WebView2Feedback is the wrong choice

Four cases argue against it.

The first is if you are looking for WebView2 code. There is none here. The runtime ships with Edge and the SDKs are distributed separately, and this repository holds an issue queue and a few documentation directories. If your question is how to call a WebView2 API, the answer is in the documentation at aka.ms/webview, not here.

The second is if you need a changelog. There is no version history in this repository, and because WebView2 ships with the browser, its version is the Edge version on the user's machine. That is a genuinely awkward property of the product and the announcements repository is the mitigation, not this repository.

The third is if your problem is not WebView2. An issue filed here that turns out to be about your own application, or about Edge itself rather than the embedded runtime, will be closed. Getting that wrong wastes the time of both sides, and the `tracked` label will not appear.

The alternative in the same direction is the WebView2 issue tracker on Microsoft's own developer site, which handles product feedback separately from the GitHub issue queue, or the Edge feedback channels for the browser itself. The difference in approach is that this repository is where the embedded runtime's developers work, and the engineers who look at a WebView2 bug look here, so a well-formed report with a reaction and a comment reaches the right people faster than a support ticket. For anything that is not a WebView2 defect, the support path is the right one and this tracker is just noise to the team.

Editorial conclusion

WebView2Feedback fits any developer embedding the Edge WebView2 runtime in a desktop application, because it is the only channel Microsoft monitors for WebView2 defects and the label semantics tell you whether a report is being worked on. It does not fit a team looking for WebView2 source, samples or a changelog, because none of that is here. Search the open bugs with the `bug` label before filing, add a reaction and a comment rather than a duplicate, and read the `tracked`, `regression` and `priority-low` label descriptions to understand where a report sits in the backlog before you escalate.

Frequently asked questions

Official sources

1. Issues
2. MicrosoftEdge/WebView2Feedback on GitHub
3. Project website
4. README