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

[Fred-Vatin]

"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

[Fred-Vatin]

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.

Edit : this is fixed now

[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 #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

[kostia1st]

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.

[SuzanneSoy]

Could the click behavior on tooltips be 'fixed' with an option to apply some CSS like pointer-events: none;? (Then that can be toggled with a modifier key or double-tap modifier.)

I thought about that, but it would be impossible to select text inside the hover (which can contain useful stuff like the types of what's under the cursor) :-/ . Also I'm not sure scrolling inside the tooltip (when it shows a big error message or e.g. the entire interface of a module) would still work with pointer-events: none.

[justsml]

I think I used the wrong word "option."

I'm not sure what options might be required, but I've got 2 rough behaviors in mind:

1. The tooltips show as configured, however in order to interact (click or scroll) I'd hold down a modifier key [ctrl] (or similar.) Any click on the tooltip would effectively click the item immediately beneath as though the tooltip wasn't there. Holding the modifier would be the only way to scroll, or click on links.

2. Another approach that might work: add ability to rapidly toggle the tooltips on/off. Where the tooltips wouldn't show on-hover at all, until I double tap [shift or ctrl]. Then they would stay enabled until I toggle them away.

[aminomancer]

Modifier keys could be fine for most users, but I don't see how the problem isn't solved by changing the tooltip position. I went ahead and tested it with Monkey Patch and it works just fine. I don't enable Monkey Patch in normal usage so it isn't a solution for me personally, but it does prove that changing the tooltip position solves the problem of clicking the tooltip when you're trying to click text.

And of course, requiring a modifier key to interact with tooltips/popups might solve this rather marginal problem for us, but at the cost of making the entire program less accessible for everyone. Locking it behind an opt-in pref could work, but why bother if modifying the tooltip position would mitigate the issue equally well with less cost?

Maybe you're thinking of some other use case that hasn't occurred to me. My own concern is with a scenario where you're trying to click a region of the text area that's covered up by the tooltip. If the tooltip is moved far enough away from the text that generated the tooltip, then there's no way for the tooltip to block the mouse.

Think about it like this — if the tooltip is offset from the text that generated it by 20x20px, then any attempt to click the text area underneath the tooltip would actually succeed, because it would require you to move your cursor off of the generating text, thereby closing the tooltip. By the time your cursor reaches the region that was covered up by the tooltip, the tooltip has already disappeared, since it was generated by text that's 20x20px away from itself.

Incredibly simple fix, it could even be implemented with CSS alone although it's probably better to go lower level so it can't bleed off the window by the offset distance amount. Modifying whatever component vs code uses to anchor the tooltips to the generating text I guess.

The exact offset might depend on how quickly the tooltip fades after the "mouseleave" event triggers on the generating text. A shorter fade duration/delay means the offset can be smaller. By that I mean the delay before the tooltip fades after the cursor leaves the generating text, not the delay before the tooltip opens.

A fade duration + delay of 0 would mean even a few pixels should work in most cases, but at that point it depends on the timing between a mouse movement in the OS and the end of a single run of the event loop, which I suppose is gonna depend on how busy the javascript engine is. So there's definitely some minimum offset required, but it can be pretty small if the tooltip fade duration + delay are shortened as much as possible.

[proimage]

@aminomancer What you're not taking into consideration is that some tooltips have elements inside that are intended to be clickable.

Let's define the issue clearly:

• Tooltips can contain links, and thus need to be clickable.
• However, tooltips also cover up/obscure code that the author may be trying to interact with.

Therefore, the solution becomes clear:

• By default, tooltips need to be mouse-phobic: they should rapidly fade to transparent when the mouse moves over them. Neither should they respond to clicks (assuming someone manages to click on them while they're fading out); instead, any clicks should be passed down to the code beneath them.
• When a modifier key is held, it removed the mouse-phobia from the tooltips, allowing them to remain on-screen when hovered, and to register mouse clicks.

The one caveat with that is that the modifier key should not be one that affects text selection; eg. if ALT-clicking makes multi-cursor selections, ALT would be a terrible modifier key to hold to make tooltips clickable. Presumably allowing a user-defined modifier key would solve this potential issue.

[trevyn]

Here’s a solution that works for me with no modifier keys:

• Tooltips appear at a dedicated area on the screen away from the text selection point.
• Normally, tooltip area shows tip for what is under the mouse cursor, with no delay, and no clicking.
• When the mouse cursor is over the tooltip location itself (or after a keypress with no mouse movement) the tooltip area shows the tip for what is at the text selection point.

This keeps the tooltip area away from obscuring the text, makes links (and the color picker!) clickable, and allows very fast “scanning” of tips by just moving the mouse around.

[justsml]

Well said @proimage - Another issue that @aminomancer touched on is the issue of a delay. That alone means an offset wouldn't work in every case.

For example, if you want to click 2 or 3 lines above the cursor, just as the tooltip opens, you'll still run into the problem.

@trevyn's suggestion of a dedicated area is another good option.
I suspect it would be a huge benefit for accessibility (e.g. folks sensitive to motion, or those using non-mouse/alternate input methods, etc.)

[Sofianio]

Why is this issue still open when there is editor.hover.sticky setting?
And I see no mention of it in this thread.
Set it to false and the tooltip hides when hovered :)

[aminomancer]

Why is this issue still open when there is editor.hover.sticky setting?
And I see no mention of it in this thread.
Set it to false and the tooltip hides when hovered :)

Weren't we just talking about how tooltips can contain hyperlinks, i.e. to MDN documentation?

[Sofianio]

@aminomancer I guess I missed that part, I never needed to click on a tooltip so it never came to my mind.
But it's still worth mentioning for those who don't care about clicking the tooltip

[holywar20]

This is a super annoying issue. I like tool tips. I use them all the time. but VS code is especially aggressive in displaying them.

I specifically have a huge issue with them popping up while I'm typing, covering up the line above it, which I sometimes want to actually read while I'm typing. Just like an offset reposition setting that a user could configure would be huge. Either that, or like a half second delay.

Also noting issue originally filed in 2016, so apparently I'm one of the few who finds this annoying and distracting.

[proimage]

Allow me to reiterate my solution, which in all honesty I believe to be ideal:

• Tooltips are "transparent" to mouse clicks by default.
  • When a mouse click "goes through" such a tooltip, make the tooltip disappear.
• If you hold down a (user-selectable) modifier key, tooltips can be interacted with.
  • CTRL/CMD might be a good default, to allow easy copy-pasta & link clicking without having to hold down an additional modifier key.

[Jimbo99]

I specifically have a huge issue with them popping up while I'm typing, covering up the line above it, which I sometimes want to actually read while I'm typing. Just like an offset reposition setting that a user could configure would be huge.

I would love to have the tool tips appear a little further away from the cursor, so an offset reposition would be great.

FWIW, there is already an option to delay appearance of tooltips. I use it but depending on circumstances sometimes I would like it faster and sometimes I don't want it at all. So the present delay option is far from perfect.

I think one of the problems I have is sometimes the tooltips are huge - a great chunk of a constant array or whatever that I don't want blocking the stuff I want to see. That amplifies the problem greatly.

[justsml]

@Sofianio

Why is this issue still open when there is editor.hover.sticky setting?
And I see no mention of it in this thread.
Set it to false and the tooltip hides when hovered :)

@Jimbo99 an offset can't ever know what lines you wish to be looking at.

The discussion around 'Sticky' or 'Offset' options will NEVER accommodate the multiple use-cases here.

I hope no-one is burning time building support for offset or fancier delay settings.

I've been noticing this issue more frequently as I coach & mentor people. Pair programming can be stressful anyway, but this behavior makes it border on painful. As navigator I need to be able to scan the code without asking "can you move your mouse? I was reading that..." 20x a session.
It violates a critical best practice "not to micro-manage the driver mid-flow."
It's now crystal clear to me how it harms momentum & focus for both driver & navigator.

I did some back-of-the-napkin math from 7 hours of pairing this past week.

The frequency of unwelcome tooltips is between 20 seconds and 4 minutes. (Defined as: anytime the users has to click around or move the mouse to get under a tooltip.)
The majority of delays fall between 2-15 seconds. Sometimes minutes as the tooltip can drag focus into other parts of the app.

These small delays might be fine for some folks, however I feel my ADHD get turbocharged. I struggle to build momentum & get into flow.

Here's a recording of me trying to click on methods the tooltip covers:

Essentially, I don't want tooltips to be interactive or perhaps show at all until I hold down a modifier, like [SHIFT].

It could also be a "sticky" state you toggle by Double Tapping [SHIFT] or whatever the user configures.

Considering most technical folks are already familiar with Ctrl+Click or Cmd+Click to open things in a new tab. This could extend behavior in a roughly similar spirit: holding the key toggles either showing, clicking, or scrolling.

Some toggle behavior/states could be:

• show-while-modifier-key-pressed OR
• default to show (similar to current defaults,) but grayscale until interactivity is enabled. Clicks should passed through to underlying content as if the box isn't there.

[jordan-bucholtz]

I just want to be able to pick where the tooltip appears 😞. Lately it's been so obstructive that I'm considering going back to my vim setup, which doesn't have this issue because I'm able to select the position of the tooltip.

[Flupp]

As an inspiration I’d like to show how KDevelop deals with this problem. It combines some ideas that were already mentioned here or in other issues. I do not want to say that KDevelop has the perfect solution. However, it has an existing solution so it can be tried out to get a feeling which parts of it make sense.

Tooltips in KDevelp are accessible via hovering with the mouse and via keyboard (by pressing Alt). When using the mouse, the hover delay is also applied when switching between tooltips. Therefore the tooltip stays in place when the mouse accidentally hovers another hover target for only a short amount of time. This allows placing the tooltips farther away from the hover target to keep more context in view while still allowing mouse interactions with the tooltip.

Alternatively the tooltip content can be show in a panel. As soon as the panel is visible, all tooltip content is shown there and tooltips are disabled. The panel content follows the mouse cursor as well as the text cursor. The idea of using a panel is discussed in #51253 and was also mentioned in #63144. The Docs View extension implements this idea partially, however, this extension considers only the text cursor and only documentation therefore it cannot entirely replace the tooltips.

Personally, I quite like the idea of dynamically switching between showing the information in a panel or in a tooltip simply based on the visibility of the panel. Also, I think this solution might be applicable to both hover tooltips and parameter hints.

[sbmelvin]

This issue has been open for five years. I didn't know VS Code was an Atlassian product.

[isimmons]

I love having all the information popup because I'm learning right now but back off from the cursor a little bit. As @Flupp shows in Kdevelope the popups are a couple of line widths off the cursor. vscode is literally on top of anything I'm trying to type so I can't even see what I'm typing.

Often times the suggestion popup stays after I type a semicolon at the end of the line and then when I hit enter to go to the next line it replaces everything I just typed with whatever it was suggesting.

It seems there are several trigger keys like when I try to type it('should... for a jest test as soon as I type '('' it inserts some code that does I don't know what but starts with the letters 'it' . When I see the suggestion pop up I have to type a space to make it go away and then backspace to finish typing what I was trying to type.

I just found the setting today to make it stop adding unwanted import statements to the top of the file that cause crashes and confusing errors. In some cases I went back to previous code in review and just happened to see these extra import statements and couldn't figure out how they got there. Luckily in those cases the statements weren't causing any errors but in many cases they did until I figured out what was going on.

[aminomancer]

How am I STILL getting emails from this? I posted an issue a couple months ago about validation and it was fixed within less than a week without anyone else voting. Why is this particular issue taking so long to move forward?

[pflannery]

My original issue is solved. There is lot of other issues posted here that are in and around the original issue.
Going to close this off and people can open their own issues if there still not solved

[proimage]

How am I STILL getting emails from this? I posted an issue a couple months ago about validation and it was fixed within less than a week without anyone else voting. Why is this particular issue taking so long to move forward?

To put it into perspective, when this issue was first posted, Americans were still in shock that Trump had won the 2016 elections.

[ShanConn]

These tooltips are just extremely annoying. The only things the vscode team cares about is if the product gets more addictive, and if they can use it to push users even further into azure.

[ohuu]

This issue is not fixed, please re-open it. The tooltips are incredibly annoying whether they appear immediately above or below the line your cursor is on. It would be so much better if you could set the number of lines (above or below) the cursor where any tooltip should be rendered.

Disabling tooltips is not a solution because they actually contain very useful information.

[aminomancer]

I agree the tooltips are annoying but I'm pretty sure theorizing about sinister conspiracies by microsoft isn't gonna help get this issue fixed

[JacobFV]

I tried finding the 'mouse hover wait before showing tooltip' variable in the source code but did not suceed. For anyone else who is trying to edit the code, I don't think you will have sucess changing the MOUSE_MOVE_MINIMUM_TIME variable (in src/vs/editor/browser/controller/mouseHandler.ts#L66).