Search bar result cannot be opened in editor

[HansomHu]

Issue Type: Bug

I like the "Open in editor" feature of search bar. But it doesn't work from some point on(I don't know the exactly time), and if I click the link "Open in editor", an error notification occurs like following:

"Unable to open '': Unable to resolve resource search-editor:#0.36733523645139976."

I really like this feature, hoping you fix it.

VS Code version: Code 1.57.0 (b4c1bd0a9b03c749ea011b06c6d2676c8091a70c, 2021-06-09T17:22:31.215Z) OS version: Darwin x64 19.6.0 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|2, 2, 5| |Memory (System)|16.00GB (0.69GB free)| |Process Argv|-psn_0_21628063 --crash-reporter-id 8cd49c1f-5018-4fc8-ac0b-3c95b4de8155| |Screen Reader|no| |VM|0%|

Extensions (18)

Extension|Author (truncated)|Version ---|---|--- bracket-pair-colorizer|Coe|1.0.61 doxdocgen|csc|1.3.2 vscode-simpler-icons|dav|1.6.5 gitlens|eam|11.5.1 vscode-great-icons|emm|2.1.77 vscode-glsl|GeF|0.2.2 theme-karyfoundation-themes|kar|20.0.3 git-graph|mhu|1.30.0 python|ms-|2021.5.926500501 vscode-pylance|ms-|2021.6.1 jupyter|ms-|2021.6.999406279 cmake-tools|ms-|1.7.3 cpptools|ms-|1.5.0-insiders cmake|twx|0.0.17 vim|vsc|1.21.2 markdown-all-in-one|yzh|3.4.0 material-theme|zhu|3.10.14 vscode-proto3|zxh|0.5.4

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383cf:30185419 pythonvspyt602:30300191 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythonvspyt639:30300192 pythontb:30283811 pythonvspyt551cf:30311713 vspre833:30321513 pythonptprofiler:30281270 vshan820:30294714 pythondataviewer:30285071 vscus158:30321503 pythonvsuse255cf:30319632 vscgsv2:30307504 vscorehov:30309549 vscod805cf:30301675 binariesv517:30312825 ```

[JacksonKearl]

Thanks for the report, do you maybe have

"workbench.editorAssociations": {
    "*": "default",

set in your settings.json?

cc @lramos15 this seems to be a common problem, is there a better way to be contributing these overrides to not need to maintain a separate allowlist for things broken by "*": "default", associations? As is I've been using:

Registry.as<IEditorRegistry>(EditorExtensions.Editors).registerEditor(
    EditorDescriptor.create(
        SearchEditor,
        SearchEditor.ID,
        localize('searchEditor', "Search Editor")
    ),
    [
        new SyncDescriptor(SearchEditorInput)
    ]
);

which should mean all SearchEditorInput's get opened with the SearchEditor, regardless of workbench.editorAssociations. In this and the welcome page, there's simply no way any other editor could know how to open the input.

[lramos15]

cc @lramos15 this seems to be a common problem, is there a better way to be contributing these overrides to not need to maintain a separate allowlist for things broken by "*": "default", associations? As is I've been using:

I am interested at how users are setting this setting as it means they ignore all custom editors. What I suggest is if it truly cannot be opening by anything else then register it as exclusive instead of default as then it will pick yours regardless of setting.

[JacksonKearl]

There's no way an extension can open an untitled search editor, but a saved search editor is fine as the backing store is just the text file. I'd expect the override service not to be used in the untitled case, as far as I'm aware it's only for opening file resources via the UI.

I guess the root of the question is why is the override service getting involved with actual Inputs? I'd expect it to manage going from a URI to the Input, but once there's an input shouldn't it correspond to a single view type, as determined by IEditorRegistry#registerEditor?

[lramos15]

There's no way an extension can open an untitled search editor, but a saved search editor is fine as the backing store is just the text file. I'd expect the override service not to be used in the untitled case, as far as I'm aware it's only for opening file resources via the UI.

You could register a separate editor entry for the untitled scheme similar to what notebooks do for cells as a temporary solution.

I guess the root of the question is why is the override service getting involved with actual Inputs? I'd expect it to manage going from a URI to the Input, but once there's an input shouldn't it correspond to a single view type, as determined by IEditorRegistry#registerEditor?

This is part of the end goal of the debt, I still have a lot of code to get there. So no we don't know (yet).

[JacksonKearl]

cc @lramos15 what's the status on this? Are search-editor schemes now disallowed from participating in override process?

[lramos15]

cc @lramos15 what's the status on this? Are search-editor schemes now disallowed from participating in override process?

I got rid of the avenues which caused users to end up with the broken setting. The search-editor schemes are allowed to participate in the override service, if you would like me to disallow them let me know as I'm not familiar with the repercussions there. Here are the following exempt schemes

        Schemas.extension,
        Schemas.webviewPanel,
        Schemas.vscodeWorkspaceTrust,
        Schemas.walkThrough,
        Schemas.vscodeSettings

Are you seeing this as a common issue? It seems like most of the issues are from the "*": "default" setting which should be fixed.

[JacksonKearl]

I haven't seen this one as often, we can wait to see if it's fixed by "*": "default" improvements.