Add support to deactivate auto-updating disabled extensions

[plainerman]

This PR fixes #76879

With the current version, disabled extensions are updated in the background. When manually triggering an update process, the user is explicitly asked if disabled extensions should be updated.

This PR transfers this desired behavior (as stated in issue #76879) to auto-updating extensions. Users can now set extensions.autoUpdateDisabledExtensions and decide whether disabled extensions should be updated or not (the default is false, meaning to not update disabled extensions). Further, this PR includes the required code to ignoring disabled extensions in the update process.

To test this fix, you can install an outdated extension, disable it and see that it won't be updated (unless you set the correct configuration).

[plainerman]

Could you take a look, why the Mac OS build has timed out and maybe restart it?
I saw that multiple other Mac OS builds in other PRs have also failed due to a timeout.

[plainerman]

@sandy081 is there anything I can do to help getting the PR reviewed and merged?

[plainerman]

@sandy081 I was wondering whether you already had a chance to look at the PR (and the failing build) and if there is anything I can do to help you merging the PR?

[plainerman]

@lszomoru, as you were also involved in this issue and @sandy081 is not responding, I was wondering whether you could take a look at this PR?

[sandy081]

@plainerman Sorry for not responding soon. I will take a look at this in Feb milestone and get back to you with feedback.

[plainerman]

@sandy081 I have just resolved merge conflicts that came up and the PR is now ready again to be reviewed.
Can you give me an estimate on when you will have time to look at this?

Thanks for getting back to me.

[plainerman]

Hey @sandy081,

I saw that you have pushed this issue back to the march milestone. I was hoping that we could look at this issue soon.
Any updates from your side? Or when you will have time to look at it?

Thanks

[sandy081]

Will take this up in this milestone.

[sandy081]

Also please provide action to toggle this flag in extensions ... menu here:

[plainerman]

Thank you for the review! I will take a look at it in the next few days and will get back to you.

[plainerman]

@sandy081 I have implemented some of the requested changes, but after rebasing my branch against the latest main branch, I have difficulties with node-gyp and cannot compile the project as of now. It will probably take until the following week, until I have time to resolve the remaining issues and look into those errors.

In the meantime, could you point me in the right direction on how I can check when an extension was enabled globally? And possibly, where the best place is to call checkForUpdates() in this case?

In the meantime, I will revert this PR into a draft, and will come back to you.

Thank you

[sandy081]

To know if extension was enabled globally you can check the extension's enablement state. Eg:

vscode/src/vs/workbench/contrib/extensions/browser/extensionsActions.ts

Line 1108 in 7cae7b5

&& (this.extension.enablementState === EnablementState.EnabledGlobally || this.extension.enablementState === EnablementState.EnabledWorkspace)

Listen on enablement changed event (extensionEnablementService.onEnablementChanged) and check if extension is enabled then call checkForUpdates. For eg:

[plainerman]

Thank you for the code pointer! I have now resolved all of your suggestions. If there are any further changes, just let me know.

[sandy081]

@plainerman Thanks for the changes. After trying out I felt having two settings for disabling auto updates and disabling auto updates of disabled extensions seems confusing for the user.

Instead I think having one setting that defines what to update would be simple. Change the existing extensions.autoUpdate setting to take enum value "all", "enabled", "none" and defaults to "all". For backward compatibility we can still accept boolean values.

"extensions.autoUpdate": true | false | "all" | "enabled" | "none"

Action in the UI can also be changed to choose among above 3 values.

[sandy081]

@plainerman Thanks for the changes. After trying out I felt having two settings for disabling auto updates and disabling auto updates of disabled extensions seems confusing for the user.

Instead I think having one setting that defines what to update would be simple. Change the existing extensions.autoUpdate setting to take enum value "all", "enabled", "none" and defaults to "all". For backward compatibility we can still accept boolean values.

"extensions.autoUpdate": true | false | "all" | "enabled" | "none"

Action in the UI can also be changed to choose among above 3 values.

[plainerman]

Thanks @sandy081, I will try to get it ready by tomorrow.

[plainerman]

I have implemented most changes, apart from the UI controls.

I imagine the new change auto update behavior to show a submenu like here:

but was not able to find out how to properly create such a menu (as of now). Further, I could not find an instance where only one option can be selected.

And I am not quite sure how to change this negate, to check for === 'none' (similarly in another line for enabled)

vscode/src/vs/workbench/contrib/extensions/browser/extensions.contribution.ts

Lines 500 to 504 in 0179466

	}, {
	id: MenuId.ViewContainerTitle,
	when: ContextKeyAndExpr.create([ContextKeyEqualsExpr.create('viewContainer', VIEWLET_ID), ContextKeyDefinedExpr.create(`config.${AutoUpdateConfigurationKey}`).negate()]),
	group: '1_updates',
	order: 2

Any suggestions are appreciated but I will look more into it in the next few days.

[plainerman]

I have now adopted the code to to this three-options approach. A few points I would like to mention:

1. I believe that the code could be simplified if we remove this backwards compatibility true | false. Is there a way to "ugprade" the users' configurations?
2. I could not manage to create a submenu like I described in the previous message. As of now it shows the two missing options as individual buttons (see image below). If you would prefer the other option, I would need a pointer into the right direction :)
   

Thank you @sandy081

[sandy081]

@plainerman Thanks a lot for the changes. You are right that supporting both boolean and string (all, enabled, none) values is complicated. We can remove boolean values and migrate to new values on users machine automatically. But, if settings sync is enabled then it might sync new values to user's other vs code instance which might be still on old version. Even though we do not support old clients I would like to try as much as possible for not making this happen.

Hence I simplified the current proposal by just adding one string value onlyEnabledExtensions to the existing boolean values

Supported this with improved UI:

Added above changes on top of your changes and merged the PR

[plainerman]

Wonderful, thank you very much!