Feature/tree view search

[FilipCondac]

Search feature

Screen.Recording.2025-10-06.at.15.42.43.mov

---

Motivation

I work in an env with a lot of containers and can be quite annoying to always try track them down.

---

Implementation Details

Core Logic

• Implemented in src/commands/filterTree.ts
• Filters across multiple properties: label, description, and metadata
• Case-insensitive and partial matching for flexibility
• Maintains filter state per view during session

Telemetry

• Tracks filter application and clearing actions
• Logs filter text length and item count

---

Files Changed

New

• src/commands/filterTree.ts — core filter logic and commands

Modified

• src/tree/LocalRootTreeItemBase.ts — integrated filtering into tree item loading
• src/commands/registerCommands.ts — registered six new filter commands
• package.json — added command definitions and menu contributions
• package.nls.json — added localisation strings

[FilipCondac]

@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

[bwateratmsft]

@isidorn tree views used to filter when you just started typing while focused on the tree view, but it seems like that's gone now? Additionally, I can't get Ctrl+F to work either.

[isidorn]

@benibenj should be able to help with this

[benibenj]

@bwateratmsft they keybiding is Alt + Ctrl + F. You can change the keybinding for list.find

[FilipCondac]

@bwateratmsft they keybiding is Alt + Ctrl + F. You can change the keybinding for list.find

This wasn't defined by default in my VSCode settings. Had to create a custom keybind which does now allow me to activate the search bar feature.

[
  {
    "key": "cmd+f",
    "command": "list.find",
    "when": "listFocus && !inputFocus"
  }
]

[FilipCondac]

I get the point about list.find, but this feature goes a bit beyond that. list.find only highlights matches, it doesn’t actually filter the list or reduce clutter. Plus, it’s not enabled by default and requires a keybind (not sure if all users?), so some users won't know that exists.

[bwateratmsft]

I get the point about list.find, but this feature goes a bit beyond that. list.find only highlights matches, it doesn’t actually filter the list or reduce clutter. Plus, it’s not enabled by default and requires a keybind (not sure if all users?), so some users won't know that exists.

I agree, this PR definitely goes beyond the features that list.find provides. There is a little button that toggles between highlighting and filtering in list.find though. However, I did not have to set the keybinding for it--are you on Mac or Windows?

You're right though, discoverability of this feature has always been a problem.

[FilipCondac]

I get the point about list.find, but this feature goes a bit beyond that. list.find only highlights matches, it doesn’t actually filter the list or reduce clutter. Plus, it’s not enabled by default and requires a keybind (not sure if all users?), so some users won't know that exists.

I agree, this PR definitely goes beyond the features that list.find provides. There is a little button that toggles between highlighting and filtering in list.find though. However, I did not have to set the keybinding for it--are you on Mac or Windows?

You're right though, discoverability of this feature has always been a problem.

I am on a Mac. It seems it was an issue for a few of my colleagues but for a few it just worked.

One thing I did find is that the filtering feature doesn't work, at least in the containers tab.

[FilipCondac]

I get the point about list.find, but this feature goes a bit beyond that. list.find only highlights matches, it doesn’t actually filter the list or reduce clutter. Plus, it’s not enabled by default and requires a keybind (not sure if all users?), so some users won't know that exists.

I agree, this PR definitely goes beyond the features that list.find provides. There is a little button that toggles between highlighting and filtering in list.find though. However, I did not have to set the keybinding for it--are you on Mac or Windows?
You're right though, discoverability of this feature has always been a problem.

I am on a Mac. It seems it was an issue for a few of my colleagues but for a few it just worked.

One thing I did find is that the filtering feature doesn't work, at least in the containers tab.

@bwateratmsft

Filtering not working

This wasn't a problem only on my machine. Tested only on Mac.

Screen.Recording.2025-10-13.at.10.58.16.mov

[bwateratmsft]

I can repro this. It seems that the built-in filtering feature will not hide unexpanded nodes. Only once the entire tree is expanded will it hide the node. @isidorn or @benibenj is this intentional behavior?

Since our containers view includes the filesystem in the tree view, that will basically never happen (nobody would ever expand the entire filesystem tree), so the built-in filtering will never really work in the containers view.

[benibenj]

Yes this is the expected behaviour currently

[bwateratmsft]

I have a few general pieces of feedback.

• I'd prefer for the search icon to change to $(search-stop) and a single click to that to clear the search terms. This could be implemented similar to how we do the commands vscode-containers.images.showDangling and vscode-containers.images.hideDangling. Unfortunately, this doubles the number of commands which is a bummer.
• Fuzzy search is pretty deeply ingrained into the habits of VSCode users, I'm wondering if there's a reasonably simple way we can support that. The builtin search/filter feature does include that.
• We could probably get away with supporting this only for images and containers. It's not common for other types (networks, volumes etc.) to have so many instances.

In the past, we have considered supporting a group-by-arbitrary-label feature. Right now for example, the default container grouping is by compose project, which comes from labels on the containers. #104 is related but not exactly the same.

Would your use case be served as well by being able to set arbitrary labels on the containers, and use them for grouping? While not the same as filtering, that would at least allow you to group in any way you want.

[bwateratmsft]

(changes requested mentioned above)

[FilipCondac]

(changes requested mentioned above)

Will tend to these in the next 1-2 days 🫡

[FilipCondac]

I have a few general pieces of feedback.

• I'd prefer for the search icon to change to $(search-stop) and a single click to that to clear the search terms. This could be implemented similar to how we do the commands vscode-containers.images.showDangling and vscode-containers.images.hideDangling. Unfortunately, this doubles the number of commands which is a bummer.
• Fuzzy search is pretty deeply ingrained into the habits of VSCode users, I'm wondering if there's a reasonably simple way we can support that. The builtin search/filter feature does include that.
• We could probably get away with supporting this only for images and containers. It's not common for other types (networks, volumes etc.) to have so many instances.

In the past, we have considered supporting a group-by-arbitrary-label feature. Right now for example, the default container grouping is by compose project, which comes from labels on the containers. #104 is related but not exactly the same.

Would your use case be served as well by being able to set arbitrary labels on the containers, and use them for grouping? While not the same as filtering, that would at least allow you to group in any way you want.

I think the group-by-arbitrary-label feature would be also great addition, especially for developers working in monorepos or microservice heavy environments. It would be genuinely useful to visually group related services.

However, I personally see filtering as the more universally valuable feature. Speaking for myself (and likely many other developers), I often prioritise features that just work out of the box. Setting up labels adds a layer of manual organisation. In practice it could be time consuming for big projects but beneficial for those who love organisation.

[bwateratmsft]

That makes sense! By the way, your formatter went a little mad with power 😄

Can you revert the formatted lines? Don't want to put you on the git blame for everything

[FilipCondac]

That makes sense! By the way, your formatter went a little mad with power 😄

Can you revert the formatted lines? Don't want to put you on the git blame for everything

All will be fixed 😭I up arrowed the git push into my terminal by accident.

[FilipCondac]

• Removed

That makes sense! By the way, your formatter went a little mad with power 😄

Can you revert the formatted lines? Don't want to put you on the git blame for everything

Oh phew, slightly embarrassing but all fixed. One wrong command is all it takes sometimes.

[FilipCondac]

I merged main and am having trouble compiling with unrelated issues to this feature. Is this a known issue?

[bwateratmsft]

What's the error and in what phase of building? If it's happening during npm run test, it's probably due to the current Azure outage.

[FilipCondac]

What's the error and in what phase of building? If it's happening during npm run test, it's probably due to the current Azure outage.

/src/commands/registries/inspectRemoteImageManifest.ts(21,43)
TS2551: Property 'getManifest' does not exist on type 'RegistryV2DataProvider'. Did you mean 'getManifestV1'?

This came in from the most recent main merge 🤔

[FilipCondac]

What's the error and in what phase of building? If it's happening during npm run test, it's probably due to the current Azure outage.

/src/commands/registries/inspectRemoteImageManifest.ts(21,43)
TS2551: Property 'getManifest' does not exist on type 'RegistryV2DataProvider'. Did you mean 'getManifestV1'?

This came in from the most recent main merge 🤔

All working, for some reason updating VSCode fixed this and allowed me to build. I wasn't able to build or view the feature otherwise. I don't understand the correlation.

[FilipCondac]

Latest commits:

• Added fuzzy search.
• Removed support for networks, volumes etc.
• Implemented the $(search-stop) single click clear.

[bwateratmsft]

/src/commands/registries/inspectRemoteImageManifest.ts(21,43)
TS2551: Property 'getManifest' does not exist on type 'RegistryV2DataProvider'. Did you mean 'getManifestV1'?

This came in from the most recent main merge 🤔

All working, for some reason updating VSCode fixed this and allowed me to build. I wasn't able to build or view the feature otherwise. I don't understand the correlation.

Oh, I bet it was due to the TS language server getting confused due to the dependencies changing when you did npm install, after merging from main. I usually will run the "Restart TS Server" command or just reload VSCode entirely when that happens.

[FilipCondac]

@bwateratmsft Forgot to ask if you want a demo video of the new iteration.

[bwateratmsft]

@bwateratmsft Forgot to ask if you want a demo video of the new iteration.

Sure! Thanks!

[bwateratmsft]

Thanks for all this--I'll try to take a look soon.

I'm allowed to dismiss my own review

[FilipCondac]

Demo for fuzzy matches and new one click clear

Demo2.mov

[FilipCondac]

@bwateratmsft hello, just wondering if there is any progress on this. Appreciate any feedback / updates that I could work towards in the mean time. Thanks!

[bwateratmsft]

Yeah! I'm planning to take a look soon. We just got the 2.3.0 release out the door on Monday, and want to get this in for the 2.4.0 release. That said, next week is Microsoft's Ignite conference so we're doing some things for that, and the week after is Thanksgiving...so it might be a few weeks yet. Sorry for the delays.

[FilipCondac]

Yeah! I'm planning to take a look soon. We just got the 2.3.0 release out the door on Monday, and want to get this in for the 2.4.0 release. That said, next week is Microsoft's Ignite conference so we're doing some things for that, and the week after is Thanksgiving...so it might be a few weeks yet. Sorry for the delays.

No worries! Just looking for an update.

Happy Thanksgiving! Enjoy🙏🏻