Try out the Issue Reporter UriHandler Proposed API

[TylerLeonhardt]

Refs: #46726

• anyOS @roblourens
• anyOS @sbatten
• anyOS @joyceerhl
• anyOS @bpasero

Complexity: 4

Create Issue

---

First off, before we get into any good stuff, I'd like to to try out the Issue Reporter (Help: Report Issue...) and make sure I didn't break it at all. I refactored quite a bit moving away from raw IPC calls so it's possible that I missed a detail. Do a general smoke test, how ever you interpret that.

Now for the fun part... this iteration we've introduced a new proposed API:

	export interface IssueUriRequestHandler {
		handleIssueUrlRequest(): ProviderResult<Uri>;
	}

	export namespace env {
		export function registerIssueUriRequestHandler(handler: IssueUriRequestHandler): Disposable;
	}

dts can be found at https://github.com/microsoft/vscode/blob/0b0c6a8889bf1ab752c71f599646b3b79cdf6f26/src/vscode-dts/vscode.proposed.handleIssueUri.d.ts

You can use this in your extension by adding this to your extension manifest (package.json):

"enabledApiProposals": [
    "handleIssueUri"
  ],

and then run: npx vscode-dts dev which will fetch the proposed API and allow you to see types.

So, the general idea is that when the Issue Reporter has selected an extension that implements this API, then the handleIssueUrlRequest will be fired and you want to return a Uri that you want to be opened... some examples:

• a basic url like https://github.com/microsoft/vscode/issues/new/choose
• a non-GitHub Issues URL like https://github.com/orgs/community/discussions/new?category=codespaces if you figure out how to fill in the body via query parameters in that new discussion form, tell me! I can't figure it out!
• a GitHub Issue Form like https://github.com/PowerShell/vscode-powershell/issues/new?assignees=&labels=Issue-Bug&template=bug-report.yml&summary=hi&powershell-version=7 note that you can fill in some values via query parameters.

When you use this API, the Issue Reporter will say that this extension uses an External Issue Reporter to handle issues and provides a big blue button to get to that issue experience. Make sure:

• The right things are hidden
• When you switch between an extension that implements this API and one that doesn't that the right info in the issue reporter is shown/hidden

Let me know what you think overall!

Note: you must adopt this in an external extension (not a built-in to VS Code one)

Helpful links

• Your First Extension
• Using Proposed API

[mjbvz]

Having trouble getting this API to work. Not sure if #180890 is the root cause but I'm also seeing:

I added logging to confirm my provider is invoked in this case, but I still see the original issue reporter template instead of a link to my custom url

[bpasero]

I am also blocked on this, even when I add a issue URL to package.json I get:

[isidorn]

Same here.

[roblourens]

I'm not sure why handleIssueUrlRequest is dynamic rather than just a field in package.json, will copilot-x add some details to the URL? Works fine now though

[sbatten]

@roblourens I've a feeling this API is going to change but the idea of returning a dynamic URL allows the extension to encode additional data into the query parameters

[jrieken]

I'm not sure why handleIssueUrlRequest is dynamic rather than just a field in package.json, will copilot-x add some details to the URL? Works fine now though

I agree from a consistency POV. We already have two ways to support issue reporting: the package-json field, and an API command to open the reporter directly I am hesitant to support a third completely different approach. Maybe we allow extensions to add a command to the package-json bugs property which we will invoke when filing an issue against the extension. Albeit less strongly typed it does allow for dynamic computation of data and/or uris. As a bonus it avoids the need for an activation event and is more similar to the solutions that are already in use

[TylerLeonhardt]

@jrieken neither of those (static contribution/command) help if you want to provide environment specific data and the user has clicked Help>Report Issue

[TylerLeonhardt]

Allowing a command for the bugs property doesn't allow for good fallback behavior for when the extension fails to activate. Today, if an extension fails to return an issue url, we fall back to the bugs property.

Maybe we could add another property to bugs in package.json called command that's next to the existing url property.

[jrieken]

if you want to provide environment specific data and the user has clicked Help>Report Issue

Pretty sure a command can do that

[TylerLeonhardt]

Im just clearing up the reason for such an API. The "API" as we have it today is not sufficient. A command would do the trick and you've already called out the issues with that approach.