Skip to content

Conversation

@colin-grant-work
Copy link
Contributor

@colin-grant-work colin-grant-work commented Jan 19, 2026

What it does

How to test

Fixes #16645
Fixes #16821

Offers two alternatives:

  • First commit tries to make newValue meaningful. Then it would be (kind of) safe to use. I think that would be nice, but it would be a somewhat large change to the API. We're very clear that you shouldn't use newValue as new value (makes one wonder why we include it), and we do provide a scope in which the change occurred, and giving a different value might be misleading.
  • Second commit reverts that
  • Third commit goes through and replaces uses of newValue the result of getting the new value. This is the safest.

Follow-ups

Breaking changes

  • This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

Reminder for reviewers

@github-project-automation github-project-automation bot moved this to Waiting on reviewers in PR Backlog Jan 19, 2026
@ndoschek ndoschek self-requested a review January 20, 2026 07:51
Copy link
Member

@ndoschek ndoschek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot, Colin, for this great improvement! Glad we could finally resolve this newValue trap for developers now.
I had a look and tested several of the updated settings, changing and resetting them works as expected 🎉

I only have a few very minor comments. It would be great if you could have a quick look when you get a chance. TIA!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this setting there seems to be an issue (for both browser and electron though), when I change the setting to compact and back/reset to classic, the menu does not show again as expected, but only shows a ... button.
But this was not introduced with this PR, so I'm going to open a follow up for this.

toDispose.dispose();
assert(results.every(setting => setting.status === 'fulfilled'), 'All promises should have resolved rather than rejected.');
assert.deepEqual(actualValues, eventValues, 'The event should reflect the current state of the service.');
assert.deepEqual([channelPref, hoverPref, searchPref], eventKeys, 'The event should contain the changed preference names.');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more thing I just noticed: we seem to be hitting issues with this equality check in the CI runs on Node 20. Maybe we could use a less strict comparison for the array?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Waiting on reviewers

3 participants