Usability: "source" (extension / owner) of a problem diagnostic not discoverable #141987
Comments
|
I am now off to But, really, the vscode product should also add implementation, see my suggestions for resolution, at least items a) and b). |
|
The "offender" above now knows this as spring-projects/sts4#725 |
|
It is extension's responsibility to set the source of the extension so that users will be aware of that. And most of the extensions are playing this correctly and would recommend to file issue against those which are not doing it. |
|
FWIW, I see vscode as a framework to assist users and extension developers. The current state of the framework helps neither party. I do agree that extension developers should write correct extensions (see my bug report against Spring), but that does not, IMHO, relieve the framework from the duty to protect (or enforce, or...) |
|
When software on your system isn't behaving as it should, saying "but it's the fault of that software" is a cheap way to shift off the burden the platform should have to help in at least discovering and identifying which software is causing the issue, in a way that can't be faked by misbehaving software. I don't think we'd be happy if Windows Defender just said "It's malware's job to let you know it's malware. We shouldn't need to do anything to help you identify what's really causing an issue." As another example, when something's eating up 100% of our CPU etc., we look to Task Manager or Process Explorer type tools to find out what. Those tools exist for a reason! The philosophy of just saying it's the responsibility of misbehaving software to report accurately on itself is not a good one for a platform like this.
How would you even know which extension to file a bug against for this purpose (or that or any other) when VSCode doesn't provide a way for you to find out which one is flagging a problem? |
jrieken
added
feature-request
|
Tagging @tvvignesh from #111443 if you and/or colleagues want to thumbs-up the backlog candidate! |
|
@shoffmeister you should upvote your own proposal and get colleagues involved if you want to see it happen! |
|
🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation. Happy Coding! |
|
Just today I ran into a case where this issue really really hurts again. It's best to demonstrate this with an example: How am I, a simple user, expected to find the extension which produces this error diagnostic: I am the first to agree that the extension ought to declare itself in a reasonable way, somewhere, somehow. But, as is quite evident from the above, it does not. With vscode as the framework not injecting a marker itself, it's ... just horrible. Even if extensions strive to be kind and friendly, the situation does not improve all that much: I happen to have a reasonably qualified guess that the origin of that diagnostic is the extension So, in short, the only recourse to this dilemma that I see is the framework code taking action, i.e. literally Visual Studio Code forcibly adding a reference to the extension, to every diagnostic entry. |
|
vscode itself does not apply a descriptive owner to problems generated with its built-in json validation tools enabled by reproductionusing the latest version, with no extensions installed, and the default vscode settings {
"json.schemaDownload.enable": true,
"json.schemas": [],
"json.validate.enable": true,
}create a project with a package.json file containing an {
"name": "vscode-problem-example",
"type": "module",
"exports": {
".": "./src/index.js",
"submodule": "./src/submodule.js",
"another": "./src/another.js"
}
}you'll see a problem with an unidentifiable source reported in your package.json [{
"resource": "/Users/yet/Developer/vscode-problem-example/package.json",
"owner": "_generated_diagnostic_collection_name_#2",
"severity": 4,
"message": "Property . is not allowed.",
"startLineNumber": 5,
"startColumn": 5,
"endLineNumber": 5,
"endColumn": 8
}]the problem disappears if you disable either generation of a meaningless string is the issueultimately, some separate issues contributed:
these are valid separate issues, but they simply emphasize this issue: if vscode did not invent the string vscode/src/vs/workbench/api/common/extHostDiagnostics.ts Lines 281 to 292 in 9b569af please enforce or generate a problem sourceif vscode itself does not correctly use the owner field, it seems unlikely that extension developers can be expected to correctly use the owner field. vscode should enforce legibility of problem owner either within its APIs or its user interface. |
and others
Issue Type: Bug
Extensions in vscode generate "Problems" entries - and sometimes it is all but clear which extension generated a specific entry.
This makes it difficult to correctly address any such entry - e.g. by fixing the underlying issue, or by managing the extension.
As an example, take this screenshot where a "problem" is flagged:
In this screenshot, I can conveniently discover that
application.yamlhas a problem -> hm, OK, go on;Unknown property 'performance'-> hm, OK, go on;YAML_UNKOWN_PROPERTYis (apparently) the error code - eh, yes, go on, tell me?... and that's it. And that is a usability problem in the vscode core product (framework), because the product does not allow me to discover straight away which of the (many) installed extensions actually emitted this problem entry, anywhere.
Now, the problem entry itself offers hard-core access to the underlying JSON data used for rendering; in the above case, we get
Clearly, this is correct information, but this is not helpful information.
What is missing - either in the hard-core raw JSON data, or discoverable by being rendered, is the originator and quite literally, at least the
sourceof the entry.In my above example, the
sourcefield is missing from the JSON; I guess extensions may optionally setsourceto, say, "Java", to flag that something related to Java is the source of the problem. In this case here, obviously the extension did not emitsource, so it's mystifying what is going on.Now, even when some extension emits a
source- let's stick with "Java" -, I am unable to correlate this source back to a very specific originator: I am unable to identify the specific extension which generated the entry, as any extension is welcome to put anything into source. AFAICT, nothing would prevent 20 extensions to all claim they are source "Java".Proposal for resolution:
a) Every raw problems entry (the JSON) should always contain a reference to the true originator of that entry - where this truth is not something reported by the originator itself, but the unique identifying element as seen by the core vscode product, such as the vscode extension id:
pivotal.vscode-spring-bootb) In case the extension does not emit a
sourcefield, consider rendering the originator in place of where the source would otherwise be rendered. In my example this would then result in rendering ofpivotal.vscode-spring-boot(YAML_UNKNOWN_PROPERTY)instead of (just)YAML_UNKNOWN_PROPERTYc) Even if a
sourceis supplied by the originator, consider making the originator conveniently available, too. It might be useful to expand the tooltip implementation in the Problems view and in the code editor, and the flyway "Show problem" hover, with functionality that allows easy discovery of the originator. This would simply access aways from having to inspect the raw JSON data.VS Code version: Code 1.63.2 (899d46d, 2021-12-15T09:39:46.686Z)
OS version: Linux x64 5.15.18-200.fc35.x86_64
Restricted Mode: No
System Info
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
opengl: enabled_on
rasterization: disabled_software
skia_renderer: enabled_on
video_decode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
Extensions (29)
A/B Experiments
The text was updated successfully, but these errors were encountered: