Vscode: Tooltips gets in the way of general operations in the editor

[pflannery]

• VSCode Version: 1.7.1
• OS Version: Windows 10 64bit

Steps to Reproduce:

I'm finding that the hover over tooltip gets in the way of general operations in the editor. i.e. when trying to double click on words. The tooltip prevents selection (see the screenshot).

Can we have a setting to change the delay timing for these tooltips?

[alexdima]

It is not currently possible to configure the delay until the hover is shown. It is however possible to disable it via "editor.hover": false

[frostius]

+1 some polish on usablity would be wonderful

[DSoa]

I don't want to see popups on everything I hover over, but do want them when there is an error (lint, etc.). Setting editor.hover to false turns off all hover help.
Can you make it more granular? Or can you add a control-key+hover/click or something to show the tooltip?
Currently Esc does not close the tooltip either. Have to click somewhere outside of a "hoverable" item to get it to go away.

[chrisdothtml]

It is however possible to disable it via "editor.hover": false

@alexandrudima Was this setting removed? It apparently doesn't exist. The hints hinder more than help me and I would really like to disable all of them. Disabling parameterHints didn't solve it either

[freMea]

"editor.hover": false seems to work although Code returns it as
Unknown configuration setting.

Note it won't work as per language setting, it has to be a general setting.

This need to be fixed and have more granularity on setting this: delay, what tooltip to disable, per language setting.
Maybe most annoyance comes from the tooltip position that conflicts with the users common edit/select actions. Maybe a needed setting or a fix for that so it won't be an annoyance source.

+1 for a setting to only enable it for warning and error message.

In the meantime with "editor.hover": false you still can use Ctrl+k, Ctrl+i to show the tooltip at the caret position.

_setup: v1.10.2 on Win 10 x64 pro_

[chrisdothtml]

@freMea That appears to have done the trick for Mac v1.10.2 as well. Weird

[freMea]

Beware that if "editor.hover": false is used and you intend to use Ctrl+k, Ctrl+i to force tooltip display at caret position, you may encounter an error that will prevent tooltip to display in any case after VS Code has restarted.

Error will be Cannot read property 'startShowingAt' of undefined
To fix this, you have no choice but set "editor.hover": true, and restart Code.

Thus "editor.hover": false is far from being ideal since it will break the tooltips even when you try to force them to show up.

Well it is the case for my setup after Code has restarted: v1.10.2 on Win 10 x64 pro.

[mikeatgithub]

The best solution to avoid the "hover over tool-tip" annoyance would be to assign its invocation to a keyboard combination like "CTRL+SHIFT+T". This way it is always off until you need it at which time you could invoke it by hitting "CTRL+SHIFT+T" or a keyboard combination of user's choice settable in "settings.json" file.

[bpasero]

@alexandrudima any reason why editor.hover is not a public setting? I have a user that searched for it and wants to enable.

[alexdima]

@bpasero You're going to need to negotiate with @isidorn The editor.hover is programmatically disabled when debugging and programmatically enabled when debugging. Exposing the setting publicly would mean for the debugger code paths to read the setting from the settings service according to our language-based options to re-establish the user setting. e.g. here.

[isidorn]

@alexandrudima you describe it quite well, nothing to add here except please create a feature request for this and assign it to me. If there are users wanting this then we can surely add it.

[bpasero]

Ok I opened https://github.com/Microsoft/vscode/issues/28535

[madprops]

I agree with @DSoa

Can you make it more granular? Or can you add a control-key+hover/click or something to show the tooltip?

[wmadden]

A scenario occurring frequently for me is that the hover comes up while typing, and there's no way to hide it without using the mouse to click somewhere else. It's particularly frustrating when it's useless generated type information - which is enormous - like this:

I would love a simple key binding to close the hover information. There's a keybinding for editor.action.showHover but there's no editor.action.hideHover!

[pakastin]

Yup, super annoying!

[itsjtwright]

Yeah I am having the same issue as @pakastin and @wmadden , a way to choose a cap to character count on the tool tip before going to "..." would be great

[estorski]

One thing that would solve this "tooltip issue" for me is to make it NOT hit-testable so that the tooltip does not get in my way every now and then when I click the code.

[dnutels]

None of these work in Insiders. Literally do not do anything.

[pdecat]

Current workaround with 1.20.0 debian package:

# sudo sed -i s/HOVER_TIME=300/HOVER_TIME=1000/ /usr/share/code/resources/app/out/vs/workbench/workbench.main.js

[rob3c]

Still going since 2016 - impressive! :-)

I'm just wondering how this isn't enough of a daily annoyance for the team members who actually know the implementation that it isn't resolved already, by necessity of maintaining sanity. Are they all using the vim extension exclusively, so they never have a need to click to focus in some code and be routinely prevented by the tooltip? It's always been a problem, but it seems particularly bad recently, which is why I came digging through the issue tracker. Is it really so complicated, that exposing a custom delay or required shortcut key hook is um, not an option? I like them sometimes, so disabling them isn't desired - just controlling them better somehow.

[theRemix]

hitting shift + esc hides the tooltip.

[jaxelsson]

I think more granularity on usability would be very welcomed.

1. Something as simple as a longer delay (or delay setting) would go a long way to keeping the hyperactive feeling black boxes from constantly obscuring your direct actions and being helpful again.
2. In addition, lack of context granularity really becomes annoying when you're trying to select text. If you have text selected, it's a lot less likely that you still want the tooltips to pop up at all.
3. Maybe it is possible to adjust the placement or styling of the black box to be a little less of a "close talker" intruding on my attention, so it's not so uncomfortable and distracting.

For me this is distracting and obnoxious enough that I start considering switching to something else entirely. Which is sad, so I persist... for now.

[jaxelsson]

I think all in all more granularity on usability would be very welcomed.

1. Something as simple as a longer delay (or delay setting) would go a long way to keeping the hyperactive feeling boxes from being obscuring and annoying to being helpful again.
2. Lack of context granularity really becomes annoying when you're trying to select text as well. If you have text selected, it's a lot less likely that you still want the

[defields923]

I've had this issue since I first started using vscode, and wow am I surprised to find there isn't a solution??

The biggest annoyance is the issue wmadden brought up. typing multiple key/value pairs in an object while the tooltip pops up every new line, preventing me from using my arrow keys to jump lines, forcing me push esc to get rid of it. >(

I would like an option to selectively hide certain tooltips (because I do rather like the suggestions tooltip), or maybe the ability to move it to another part of the page, maybe upper-right corner.

[proimage]

These 4 changes would fix this entirely.

1. Only keep the tooltip open when the mouse is over the triggering code string itself. Hide using the usual delay once the mouse moves over the tooltip window.
2. Clicks on the tooltip window should pass-through to the code beneath.
3. Holding a modifier key (Shift? Ctrl?) should negate both 1 and 2 in case someone wants to select a code sample from the tooltip window itself.
4. Differentiate between informational tooltips (the ones complained about here) and code-completion prompts, and have separate "showAfter" settings for each.

[tushar-singh]

There should definitely be a way to at least disable the arrow navigation inside tooltips. I'd much rather be able to navigate through my code than endless tooltips

[kellytk]

Not being able to configure the hover delay introduces substantial friction to my use of VS Code. Additionally a key binding to hide the view, such as esc, would be helpful.

[alexdima]

I plan to look into improving things for the hover.

Just to clarify on expectations, this issue has gotten bombarded with various ideas or complaints about two different widgets. One is the hover and that shows typically when using the mouse over a symbol and the other is the parameter hints widget and that shows when typing (similar to suggestions) and renders the arguments that should be passed in to a method call. I plan to improve things for the hover.

| Type | Screenshot | Link |
|---|---|---|
| Hover | | https://github.com/Microsoft/vscode/issues/15667#issue-190133079 |
| Parameter Hints | | https://github.com/Microsoft/vscode/issues/15667#issuecomment-348932383 |
| Parameter Hints | | https://github.com/Microsoft/vscode/issues/15667#issuecomment-353326281 |

---

To summarise the current proposed ideas regarding hover:

• The setting "editor.hover" should no longer be an internal thing and it should work per language.
• Add option to configure the duration to hover until something is painted.
• Add option to show only errors & warnings in hover and not compute semantic hovers.
• Add option to configure hover to be shown with a different gesture than mouse hovering. (e.g. Ctrl key pressed and hover).
• If "editor.hover": false, the hover cannot be shown via keybindings.
• Allow clicking to pass through the hover (i.e. hover should not eat mouse events).
• Do not show hover when selecting text
• Hide the hover when the mouse leaves the triggering code.

I will look into implementing a subset of these ideas to hopefully reduce friction in this area.

[eamodio]

All sounds great, except for

Allow clicking to pass through the hover (i.e. hover should not eat mouse events).

While I think this is probably a good default, I often copy from hovers, so I would request a way to allow the hover to have focus. Maybe Ctrl+click or something. So we don't loose that ability.

[chrisdothtml]

I'm on v1.26.0-insiders, and I can no longer disable all hovers.

I have all the following:

"editor.hover": false,
"editor.hover.enabled": false,
"editor.parameterHints": false,

and as far as I can tell, none of them actually do anything. I used to be able to disable all hovers with "editor.hover": false, but now they're all back. I personally don't find any value in the hovers and just want them to be hidden

[michael-38]

Until someone has a better suggestion, I'm just going to set the delay to a higher number...

"editor.hover.delay": 3000000

[proimage]

BTW, I think disabling the hover also affects the color selector popup in CSS files...

[reeddunkle]

I believe that "editor.hover": false no longer works. Setting the delay "editor.hover.delay": 3000000 doesn't seem to do anything for me either.

Is this just a local problem or is this true for others?

[chrisdothtml]

Alright, so it turns out when I remove "editor.hover": false, and keep "editor.hover.enabled": false, it disables the hovers as expected

[reeddunkle]

@chrisdothtml You're right. I guess the old setting "editor.hover": false was preventing the others from working. The delay property works as expected now too. Thanks!

[Nodws]

Ah this bad boy has saved me from frustration "editor.hover.delay": 3000

[mblandfo]

I didn't see it on @alexandrudima 's list, but right now the hover appears directly above the hover element. I'd suggest adding 20px or 30px margin so it's a little less likely to get in the way.

"editor.hover.delay" seems to default to 300, I think 500 may be good enough. With 300, as I mouse up the screen, and I slow down when I get close to the text I want to select, as the mouse passes over the line below the hover for that line shows up... right on top of the text I was about to select!

[jasel-lewis]

Any movement on the "Parameter Hints" issue @wmadden presented? (comment link)

As his GIF demonstrates, this is _not_ a hover-related issue, rather, the tooltip appears as you type. ESC works to clear it, but the very next keystroke, the tooltip re-appears. And it's VERY inconsistent, at least for me, in when it displays. I've yet to determine the rhyme or reasoning. At times, it even appears when typing a comment line...

[edwarddim]

"editor.hover.enabled": false

It worked for me

[jasel-lewis]

@edwarddim I'm glad "editor.hover.enabled": false works for whatever concern you've experienced.

The issue which @wmadden has described in his post, and to which I am referring, is _not_ related to a _mouse_ hover condition. The graphic @wmadden provides in his post is exactly what I am experiencing. The pop-up _appears_ the same as a hover action, but it occurs without ever moving the mouse - it occurs when _typing_ and/or using nothing more than the keyboard's arrow keys to move around in the code.

I'll restate that "editor.hover.enabled": false _does not_ prevent that which is depicted in @wmadden's post.

[red-lonely-neuron]

I have Visual Studio Code 1.26.1 with Electron 2.0.5 on Linux and I have attempted to change the value of editor.hover.delay to 2000 (something different than the default 300) in the user settings. The result was the tooltips appeared after 2000 ms, but after restarting Code, the delay was again 300 (I guess since the tooltips appeared too fast). I have also attempted to set the value in the workspace settings and I've got the same result: after a restart, Code doesn't seem to take into account the value of editor.hover.delay in the user settings or in the workspace settings. It takes it into account only after modifying it to something else, then setting it to the desired value.

[reeddunkle]

@red-lonely-neuron I previously had the setting "editor.hover": false (before it was deprecated), and found that that setting was preventing the editor from registering the new hover delay setting "editor.hover.delay": 3000 I was attempting to add.

So there's a chance some other setting is conflicting with your hover delay setting.

[red-lonely-neuron]

@reeddunkle: there's no other modified editor.hover setting either in the user settings file, or in the workspace one. There is a editor.formatOnSave set to false.

[reeddunkle]

@red-lonely-neuron I don't think that "editor.formatOnSave" would interfere. Sorry, I don't have any other ideas.

[jakepark]

ParameterHints is a separate issue from the hover issue initially raised in this ticket, I think.

It's very distracting, and I don't see any setting to turn this off. According to research,
the setting:

"editor.parameterHints": false,

USED to work, but on my machine and version
ubuntu 16.04 / vscode 1.27.2 this setting does not work!

Thank you for visually laying out the different issues @alexandrudima , for now I would love just to get that formerly working setting back (to turn off parameter hints completely in the interim of additional feature requests.)

[alexdima]

@joaomoreno did we remove the setting editor.parameterHints for toggling on/off parameter hints ?

[joaomoreno]

@alexandrudima It seems to have changed to editor.parameterHints.enabled: https://github.com/Microsoft/vscode/pull/55354 cc @jrieken

[jakepark]

Thank you both. I can confirm that this fixes the parameterHints display issue.

"editor.parameterHints.enabled": false

Tooltips and its discussion is still relevant for this ticket.

[jasel-lewis]

Concur with @jakepark that "editor.parameterHints.enabled": false restricts the behavior I was discussing (and was annoyed with).
Thank you, Jake, for identifying the separate issues. Now if only we can get a delay setting added to editor.parameterHints instead of a simple on/off. :)

[codeocelot]

It's worth noting that the popovers will still occur if you have both "editor.parameterHints": false and "editor.parameterHints.enabled": false in your config. Remove "editor.parameterHints": false and they should disappear.

[benzvan]

Any progress on this? I'm just starting to try using vscode and I'm finding it very difficult with the parameterHints popping up and covering my code after I've already dismissed the parameter hint for the block of code I'm working on.

[pakastin]

I just disabled every single tooltip I could find 🤷‍♂️

[benzvan]

I actually find the tooltips super helpful when they aren't blocking the actual code I'm writing.

[sylver]

this parameterHints issue is bothering me for a while now, up to the point I ended up here to find a solution.
Being able to turn it off completely is not really solving the issue imho, that's hiding the problem (but helps for sure with the trade off to lose useful hints).

One solution I can think of, is to let one set where he wants this popup to appear.
Something like "editor.parameterHints.position" with options like cursor, topLeft, topRight, bottomLeft, bottomRight, etc

That way we could still enjoy the hints without having them overlaying the code we're working on.

[jakepark]

In the past I've coded modals that do exactly as you describe, @sylv3r .

As part of your feature request, please provide wireframes, some user interaction flow (gif's are worth a million points), edge case solutions (e.g. what should happen when the cursor is at the extremities of the screen), and other potential problems I haven't thought of off the top of my head :)

Not saying I'll work on it but hopefully this helps describe the problem complexity.

Honestly since I turned off the feature a year ago, I feel like I've opened more library code to fully understand dependencies being injected..

[proimage]

Might I suggest implementing modifier keys to control the behavior of these popups and hint windows and whatever the heck you call them? For example, by default, have these popups visible but non-interactive (not clickable). You have to hold CTRL/CMD to be able to interact with the popups—that's one modifier key. Another one would be SHIFT perhaps, which would make the popup transparent while the key is pressed.

This general "Hold a modifier key to interact with something" pattern is already established for when you click on links in those popups, so why not extend it to affect the interactivity behavior of the entire popup?

[affordablequalityhomes]

I would like them to be unobtrusive by default, without having to set some custom setting which may have unintended side-effects. Can they be a little transparent, and not clickable? But then if you do CTRL + . they are? Just brain storming. Something like that. So the people who want to do something with the tooltip itself still have a way, but 99.999% of the time when you don't, you can still see them but they don't block you clicking or selecting text or using the editor. Thanks.

[freMea]

A bar/panel at the bottom of the editor that would appear with no delay could do the trick too.

But with the new flexible layout released in may 2020, a parameter info view that one can move everywhere would be nice too. Maybe a new activity being oriented towards code documentation that would implements the current parameter info tooltip as well as other documentation aggregator like DevDocs would be nice and complete.

I have a workaround to have access to this info tooltip without being annoyed by them. I explain it here #102198 because this highlighted another bug.

Here are other related issues more or less duplicate : #33752, #16221 (an awesome feature suggestion), #51253, #30797, #63144.