Change:
case ProgressLocation.Explorer: return this.withPaneCompositeProgress('workbench.view.explorer', ViewContainerLocation.Sidebar, task, { ...options, location }); case ProgressLocation.Scm: <del> return this.withPaneCompositeProgress('workbench.view.scm', ViewContainerLocation.Sidebar, task, { ...options, location }); </del> <ins> return handleStringLocation('workbench.scm'); </ins> case ProgressLocation.Extensions: return this.withPaneCompositeProgress('workbench.view.extensions', ViewContainerLocation.Sidebar, task, { ...options, location }); case ProgressLocation.Dialog:

Discussion:
Issue Type: <bBug</bInsiders with a fresh user-data-dir in which progress-sample has been modified to target rather than . the extension (npm install) and launch it in Extension Host from 'Run and Debug'. EH Command Palette use the 'Show Progress' command that the extension contributes. Confirm that the clock decoration appears for around 5 seconds on the Source Control icon in Activity Bar. the Source Control icon over the Explorer icon, then onto the Explorer view container when its contents appear. the SOURCE CONTROL header from Explorer view back onto Activity Bar. -run the 'Show Progress' command. Observe that the clock decoration fails to appear :bug: recover the correct behaviour, run the 'View: Reset View Locations' command. Now when you run 'Show Progress' the clock appears for 5 seconds as expected. VS Code version: Code - Insiders 1.62.0-insider (, 2021-10-15T05:16:57.817Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
I think this bug is in the area of management of views and view containers, so maybe for From a user perspective step 6 in my repro reverts the effect of step 5, but internally something must be different when step 7 happens compared to how it was at step 4. I didn't notice the problem immediately after I had experimented with moving the Source Control view because no SCM operations were occurring at that time. Later I started wondering why the clock wasn't appearing when it should, and I initially thought my source control integration was broken.
the problem here is that the progress location code always directs progress badges for SCM to the original view container. This repro effectively moves all views from SCM in to the explorer, then moves a single view into the activity bar creating a new (with a different id) view container for scm. I believe the appropriate thing here is to direct scm progress location to the scm view itself (as opposed to the view container) and we can look up its current location. Sample fix
the area of code your proposed change is in makes me wonder if the same problem can occur with progress badges that target Explorer and Extensions. The API doesn't let extensions target those view containers, but maybe core code already targets them.

the original explorer and extensions view containers at the moment cannot be moved/removed. that used to be true for scm as well before work was done to allow scm to be moved as well. so today its not an issue, but you are right that it could be in the future.
I have taken the changes from your sample fix but they end up with the following error:
branch?
-
Thanks I have tested and checked in the changes.