[Feature Request] Feedback for contribution point "editor/title/run"

[jdneo]

// This is a follow-up issue for #114123, cc @jrieken

Thanks to the team to provide a centralized contribution point for the run button. Here are some feedback for consideration.

• Show the keyboard shortcut in the dropdown menu?
• Considering another entry for debug (editor/title/debug)? In that case the user can just have one click if each contribution(run and debug) just has one entry.
• Just like what we have in the debug view, the title area can have a dropdown menu explicitly and VS Code can memorize the last choice. (But given the very limited area there, this might not be a good idea though)
  

[jrieken]

Considering another entry for debug (editor/title/debug)?

Our idea is that the menu is used for run- and debug-commands

[jrieken]

//cc @weinand

[jabbalaci]

Now if I want to run my code, I need to click twice :( Previously one click was enough. Can you add a setting that sets a default behavior for the button? If you click on it once, "Run Code" should be the default. Clicking twice is a pain.

[jdneo]

The Java side also has a user mentioned about the Clicking twice is a pain

[hisra015]

I'd love an option to revert back to the previous button. This new feature has not once worked properly for me because it closes just as fast as it opens by itself. Seems to be a bug that I have been tracking for the past few days.

[Parminder51]

Clicking twice really is a pain, would appreciate if a 'Select Default Option' was available for different languages.

P.S. Happening in Python

[jabbalaci]

@Parminder51 "Happening in Python" : what do you mean? Do you have a link for more info?

[Parminder51]

@jabbalaci When I'm trying to click the run button, the context menu pops up. A few days back it would just run the file with the coderunner extension. Now I have to select again and again whether to run using the python extension or coderunner extension.

[jabbalaci]

@Parminder51 OK, I misunderstood. When you wrote "Happening in Python", I thought a solution for Python was under way. Yes, I also noticed this double-click problem and it also bothers me. I hope there will be a solution for this soon.

[gjsjohnmurray]

For those of you with the problem, are those two contributions to the new editor/title/run menu coming from a single extension or two extensions? If two separate extensions, is it feasible to disable one for the workspace?

[codinginpython123]

I have the same problem with @Parminder51

[Parminder51]

@gjsjohnmurray Usually the Python extension's button is hidden if the Code Runner extension is enabled, and it was working fine. But now when you click on it, the context menu pops up. I hope to use the Code Runner extension but there is no way to remove the run button in the Python extension, I checked for it and found this. https://github.com/microsoft/vscode-python/issues/6921.

[joaomoreno]

I suggest we agument toolbar submenu actions with some indicator that it's going to be a dropdown. This should help in the user's perception of what will happen when they click it.

For this specific toolbar submenu action, the Run, maybe it's best to further change it to behave like debug: a UI piece with two click zones, one for the default and another for the dropdown which, when selected, would run and change the default.

[miguelsolorio]

Now that we have hover feedback on toolbar actions (via #120226) I think it now makes sense to explore what adding affordances to split buttons could look like to improve their usability. Here are a few concepts:

[lukepighetti]

Option 3

[jdneo]

Vote for option 3.

The background color indicates that the play and chevron-down are in one group, while the different background color indicates that they have different functionalities.

[Tyriar]

I just pushed the new DropdownWithPrimaryActionViewItem that @meganrogge and I worked on to base:

https://github.com/microsoft/vscode/blob/main/src/vs/base/browser/ui/dropdown/dropdownWithPrimaryActionViewItem.ts

This powers the terminal's button in the same style:

It's basically the 3rd option but with a negative left margin on the right button so that the 2 buttons are closer together like option 2, this is particularly important to help distinguish the related v icon for this case:

[weinand]

The split button in action:

[weinand]

@isidorn raised the question whether selecting a drop down menu action should only select or select and execute the action.
The former would again require two clicks. The latter only one but its behavior might be a bit surprising.

For comparison here is the current behavior:

[isidorn]

I was just concerned if we have other places in our UI where selecting something also runs it.
Since the debug dropdown behaves different maybe I am just used to that selection only selects.

I would still slightly lean towards that selection should not run because:

• I think users will not often switch between the options
• It is cleaner and aligns better with the rest of our UI

[weinand]

Another thing to consider: if the actions in the drop down menu do not have different icons, then selecting them without executing them will not have any visual effect on the split button since the icon does not change. This is different from the debug config dropdown where the unique name of a configuration is shown.

[miguelsolorio]

I think the dropdown in the debug view is visually different enough that it won't cause that confusion:

Because we also use the same interaction of selecting a dropdown to perform an action in the terminal:

[isidorn]

@misolori I was not aware that we also do this in the terminal.
Then I think we should go with this approach here also.

[weinand]

I've released the feature. Please try it in the next Insiders.

[jdneo]

@weinand

Looks good! Just one bug I found, arrows are appended if user select through dropdown

bug.mp4

Version: 1.59.0-insider (user setup)
Commit: f6df685
Date: 2021-07-13T05:12:59.073Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Windows_NT x64 10.0.19043

[weinand]

@jdneo interesting. I'm not seeing this with Mock Debug... Will investigate with Java

[weinand]

Yes, I can reproduce with the Java extension.

Workaround: add a "enablement": "!inDebugMode", to the Run/Debug commands in package.json (see example).
This "enablement" is good anyway because it disables the command while a debug or run is running. This avoids that multiple debug sessions are created unintentionally.

[weinand]

@jdneo I've fixed the problem that you've spotted (c8d537c)
Please verify with next Insiders.

[andreamah]

I noticed some weird behavior with which title is shown on the button. To replicate:

1. Open the webview sample from vscode-extension-samples
2. Edit package.json to use the contribution point:

"menus": {
    "editor/title/run": [
        {
	        "command": "catCoding.start"
        },
        {
	        "command": "catCoding.doRefactor"
        }
    ]
}

3. Launch the extension and ensure that the button is currently showing "Do some refactoring". Using the "start a cat coding session" option in the dropdown does not cause the button show the text for "start cat coding session", but it just stays the same instead. 🐛
4. Also, if you click the "start cat coding session" option again with the window still open, it now shows the right text on the button 🐛

Version info:
Version: 1.59.0-insider (user setup)
Commit: 818c661
Date: 2021-07-21T06:59:32.970Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Windows_NT x64 10.0.19043

[jdneo]

Hi @weinand thank you for the fixing. Now the dropdown arrow works pretty well.

There is another problem though, after switching the active run action via the arrow, then the run/debug button itself becomes unclickable(no response after clicking).

[weinand]

@andreamah I can reproduce the problem you are seeing. I'll investigate...

[weinand]

@andreamah @jdneo
The issue is a cyclic context JSON that gets serialized over to the extension host via rpc and results in an exception due to the cycle (cc @jrieken).

I've added a workaround and I could no longer reproduce the problem in the webview sample and in the Java extension.

[jdneo]

Thank you @weinand, I just played it in the newest insider, everything works great now!