Proposal: Support configuring data sent to extensions for Issue Reporter

[justschen]

Motivation

As discussed in #46726 and #45673, now that users can choose to file on extensions, extension authors should be able to specify additional data to include in the report. This could potentially include:

• User settings
• launch.json information
• Metadata about the workspace (is it multiroot)
• Console errors
• General data specific to the extension

Additionally, many extensions are using a similar command which creates the option in the quick pick to report on issue specifically on that extension. This flow will open the issue reporter, similarly to Help: Report Issue, but with the extension automatically selected, and can also provide a template to the issue body.

However, with many extensions installed, this can become bloated and when extensions what users to add additional information, they would like users to go through the full flow of the reporter to ensure that users never forget to fill in information.

Proposal

Adding an API with the following:

        export interface IssueUriRequestHandler {
		// Handle the request by the issue reporter for the Uri you want to direct the user to.
		handleIssueUrlRequest(): ProviderResult<Uri>;
	}

	export interface IssueDataProvider {
		// Provide the data to be used in the issue reporter.
		provideIssueData(token: CancellationToken): ProviderResult<string>;

		// Provide the template to be used in the description of issue reporter.
		provideIssueTemplate(token: CancellationToken): ProviderResult<string>;
	}

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

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

Via IssueUriRequestHandler, extensions can choose to direct users to file the extension externally. By providing a URI to the API, the Issue Reporter will show the following:

Via IssueDataProvider, extensions can apply a template and specify data, which will populate the template in the issue description body or a previewable text box with extension data, like below.

Additionally, we'll be adding a new activation event: onIssueReporterOpened which will activate the extension when the extension is selected in the extension selection section of the issue reporter. This ensures that extensions that are activated via means other than onStartupFinished will be able to contribute to the issue reporter via their API.

Limitations

The main limitation in this API is that the information and extension data can only be sent via the API in string format.

Additionally, at the moment, users would be unable to edit or modify the extension data that is sent. It's expected that users trust the extension to send the correct data and information and will be able to opt in or out of sending that extension data after previewing. However, if there are specific parts of the extension data that users would not want to send, they would only be able to send all or none.

The workaround is allowing the extension data text box to be editable, like the issue description. However, this may be an overload of information.

Another limitation is that only a single template can be provided, so users would break out of VS Code and have to report directly on GitHub if we want to direct them to one of the templates like below:

[justschen]

ATM, known additional wants/needs:

1. Even more data:

• From Python @karrtikr: potentially allowing a separate textbox/area for logs - we would also want to give users the opportunity to redact any potential PII from the logs. The format could be .txt or .log, or just another text box similar to template.
• Limitations/Concerns: could potentially exceed the limit of the payload.
• Alternatives: Hyperlinking?

2. Ability to edit the repository link:

• From Peng @rebornix for Copilot: Allowing specific repo urls . Since atm, handleIssueUrlRequest and provideIssueData are mutually exclusive, but looking into a way to provide a specific url, while also providing data.
• Use case: users with specific privileges (ie, vs code members) would file with a template and into the microsoft/vscode-copilot repo, while regular users would file with a different template into microsoft/vscode-copilot-release
• Limitations/Concerns: none, but would have to add an additional function under IssueDataProvider, would like something like this:

export interface IssueDataProvider {
		// Provide the data to be used in the issue reporter.
		provideIssueData(token: CancellationToken): ProviderResult<string>;

		// Provide the template to be used in the description of issue reporter.
		provideIssueTemplate(token: CancellationToken): ProviderResult<string>;

		// Provide the url to be filed upon.
		provideIssueUrl(token: CancellationToken): ProviderResult<Uri>;

	}

• this would be separate from the IssueUriRequestHandler since we should register one or the other, corresponding to filing externally or filing everything through the issue reporter itself.
• Alternative: Allow both parts of the API to be used - if we see that it has both the provider/handler from both parts, we assume that we must use the URL from handleIssueURl... and the data/template from IssueDataProvider

[jrieken]

Feedback/Todo

• find all extensions that use the API command
• know why they do that
• ask them what it takes to migrate onto a new "real" API

[justschen]

Feedback/Todo:

• More powerful openIssueReporter command - can already provide extension data and modify URI
  • Example: Popup when server crash, etc, that says "open issue reporter" and can attach logs and output channels automatically
• Contribute command, if contributed, normal flow from Help: Report Issue can also still gather data
  • via using the menu service
• Custom list in Quick Pick, similar to view.
  • if we type issue or report, custom quick pick list with all extensions that contribute the command

[justschen]

closing this for now - all discussed items are now completed and shipping out this iteration

• Command improvements, allowing for data and URI changes
• Normal flow via Help -> Report Issue... can trigger menu contribution point and run data collection
• Quick Access -> report extensions by searching issue<space> in the quick access. Hidden behind a setting (extensions.experimental.issueQuickAccess)
• Extensions begin adopting: started with Python and Python Debugger.

[caleb-at-pieces]

Hello, I am attempting to add this into my extension however I get the error message mentioning that this is still a proposed API even though I have vscode 1.88.1 installed. Is this not included by default in to the extension API yet?

[justschen]

@caleb-at-pieces hey! yes the contribIssueReporter is still proposed atm (see https://github.com/justschen/vscode/blob/2e521d38bb99c698fe22b60e54a20e8cb8910481/src/vscode-dts/vscode.proposed.contribIssueReporter.d.ts#L1-L2). It's just a placeholder so we can have use the menu contribution service.

@jrieken I will bring this up at api sync, but I'm not sure what this would look like when finalized, is there an example of this? I see a large number of vscode.proposed.contrib.... in our vscode.d.ts folder.

[caleb-at-pieces]

@caleb-at-pieces hey! yes the contribIssueReporter is still proposed atm (see https://github.com/justschen/vscode/blob/2e521d38bb99c698fe22b60e54a20e8cb8910481/src/vscode-dts/vscode.proposed.contribIssueReporter.d.ts#L1-L2). It's just a placeholder so we can have use the menu contribution service.

Great, thanks for the reply!

Follow up question: Is this unrelated to https://code.visualstudio.com/updates/v1_87#_contributing-additional-data-in-issue-reporter then? It seemed by reading this that this has been finalized. There is also this: https://code.visualstudio.com/updates/v1_88#_use-issue-reporter-command-for-extension-bug-reporting on the 1.88 release notes.

[justschen]

@caleb-at-pieces sorry just saw this, but no these are the same things that were finalized! the expectation is that extensions follow this command contribution structure to contribute date 👍