Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Support configuring data sent to extensions for Issue Reporter #196863

Closed
justschen opened this issue Oct 27, 2023 · 8 comments
Closed
Assignees
Labels
api-proposal insiders-released Patch has been released in VS Code Insiders issue-reporter Issue reporter widget issues on-testplan
Milestone

Comments

@justschen
Copy link
Contributor

justschen commented Oct 27, 2023

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:

externally handled demo

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.

demo of issue reporter api handled issue

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:

Screenshot 2023-11-02 at 3 05 22 PM
@justschen justschen added api-proposal insiders-released Patch has been released in VS Code Insiders labels Oct 27, 2023
@justschen justschen self-assigned this Oct 27, 2023
@justschen justschen added this to the November 2023 milestone Nov 3, 2023
@justschen
Copy link
Contributor Author

justschen commented Nov 7, 2023

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
Copy link
Member

jrieken commented Nov 7, 2023

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 justschen modified the milestones: November 2023, December 2023 Nov 27, 2023
@justschen justschen added the issue-reporter Issue reporter widget issues label Dec 14, 2023
@justschen justschen modified the milestones: December / January 2024, February 2024 Jan 23, 2024
@justschen
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

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?

image

@justschen
Copy link
Contributor Author

@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
Copy link

@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
Copy link
Contributor Author

@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 👍

@microsoft microsoft locked and limited conversation to collaborators Jun 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-proposal insiders-released Patch has been released in VS Code Insiders issue-reporter Issue reporter widget issues on-testplan
Projects
None yet
Development

No branches or pull requests

3 participants