Change:
import { IMenuService, MenuId } from 'vs/platform/actions/common/actions'; import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IContextMenuService } from 'vs/platform/contextview/browser/contextView'; <ins> import { TextEditorSelectionSource } from 'vs/platform/editor/common/editor'; </ins> import { IInstantiationService, ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { Registry } from 'vs/platform/registry/common/platform';

Discussion:
In our tree and list widgets as well as in our editor breadcrumbs, we visually distinguish between: active element element that's being hovered element that a context menu was invoked for via right click (and maybe ctrl+click on mac) https://user- https://user- We now have a context menu for editor line numbers, but the editor line number only reflects where the cursor currently is, so: is no highlight when you hover over an editor line number which is different than the one relating to the editor selection is no focus indicator when you right click on an editor line number This makes it difficult to visually verify which line number you are right clicking on, e.g. if you are trying to copy a link.
Kai had the suggestion that we should select the whole line corresponding to the line number context menu target to reduce ambiguity about which line is going to be selected. This does align with what happens on and is not a breaking change since we never enabled right click context menus on the line number in the first place. Looping in for UX and for editor feedback
Explored this, seems pretty reasonable and does address the problem of ambiguous context, the only thing I'm wondering about is whether it also makes sense to have this selection behavior when right clicking in the editor gutter, as it would be a behavior change for the debug/test context menus, and it would not preserve your in-editor selection (which could be bad if the user has multiple selections going). Any feedback https://user-
Hm, I'm honestly not a fan of selecting the line when right clicking on test decorations or working with breakpoints. In both cases you aren't "switching contexts" away from what you were doing, and selecting the line is never going to be a desired outcome of right-clicking a gutter
Yea maybe we have this selection behavior only for a right click on the line number specifically then.
To clarify how to test this you just right-click in the gutter and an option should pull up which says : `copy vscode id"? Is this in vscode desktop and are there parameters on which types of files it works for?

Steps: click on a line number with no existing selection in the editor that the target line is selected an existing selection in the editor (test both single line and multiple line selections) that the selection changes appropriately when right clicking on a line number
seeing this on two different file types: https://user-
are you pointing out that there's a context menu for .py but not .json? That is by design since you cannot set breakpoints in a json file so none of your available actions apply to the .json file. The active selection seems to be changing correctly based on your mp4 (which is the scope for this issue).
Is it supposed to have a related context menu or am I supposed to see the "open in " menu item come up for a json like it did in yours? If that looks correct then I just misunderstood the issue I was verifying. Sorry!
You'll only see the Copy link action in a GitHub repo. There are other actions if you install the GitHub Pull Requests extension for copying GitHub links. If this is a GitHub repo then that's a bug.