"Expand" tooltips are obscuring other UI elements

[zbjornson]

Select Topic Area

Bug

Body

Something changed recently where mousing over the Expand Up/Expand All/Expand Down buttons reveals a tooltip after a delay, that appears and stays visible even if your cursor isn't over the Expand button:

Notice that the tooltip appears while my cursor is no longer over the blue expand button.

Consequently you can't click on whatever is behind the tooltip (line number, file collapse/expand button).

[manifestinteractive]

Having the same issue here on the main file collapse / expand. Seems like a "hover intent" delay is needed here to only show the tooltip if the user is actually hovering over the element when it is shown.

[elias6]

That is so annoying. I frequently click that "Expand Up" thing by accident.

[manifestinteractive]

What's sad is this is easy to fix with three lines of CSS code. GitHub uses a custom element called tool-tip so just adding pointer-events: none; will fix this 100% and keep all other functionalities.

tool-tip {
    pointer-events: none;
}

[sbakic]

I wanted to open the same issue. It is very annoying when reviewing PRs.

Screencast.from.2023-05-09.13-02-28.mp4

Possible Solution: Looks like the tooltip delay should be increased.

[pf-paul]

Another possible solution: allow the tooptips to be disabled in settings. They're not useful to people who are already familiar with the interface and even with a delay may still get in the way.

I have resorted to a Tampermonkey script to get rid of them.

[nick-andren]

I'm hitting this as well. "Expand Down" is tricky to click on because "Expand Up" keeps obstructing it

[pf-paul]

That is the exact case that gets me all the time as well. The other one is when the tooltip obscures the button for collapsing the entire file. Plenty of "gah!" moments have arisen from these 😖

At least we have some reliable workarounds, particularly the bookmark method, as that doesn't require installation of any browser extension, which some IT departments may prohibit. Thanks @gsaunders-sw2 for that

[ayal4m]

Same issue here. Horribly frustrating. This definitely a bug, not a feature.
I would consider moving my entire organization from github if it is not fixed soon.

[ddavies-integral]

If anyone's interested, I wrote a TamperMonkey/GreaseMonkey script to hide the annoying tooltips.
Modify the "match" URL to limit it to only the PR's for your organization if you want.

// ==UserScript==
// @name         Github tooltip hider
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  hide those annoying tooltips that obscure the collapse file button
// @author       Some Dude
// @match        https://github.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    function processTooltips() {
        var tips = document.getElementsByTagName('tool-tip');
        for(var tip=0;tip<tips.length;tip++) {
            var elem = tips[tip];
            if (elem) {
                elem.remove();
            }
        }
        setTimeout(processTooltips,1000);
    }
    setTimeout(processTooltips,1000);
})();

[grant]

Don't mention @grant please :)

[simon-abbott]

Thanks for this script. I cleaned it up a bit and made it only apply to the expand up/down tooltips (as-written it's blocking all tooltips, including the "who reacted" information).

// ==UserScript==
// @name         Github tooltip hider
// @namespace    http://tampermonkey.net/
// @version      1.0
// @description  hide those annoying tooltips that obscure the collapse file button
// @author       Simon Abbott
// @match        https://github.com/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    setInterval(() => {
        const tips = document.querySelectorAll('tool-tip[for^=expand]') || [];

        for (const tip of tips) {
            tip?.remove();
        }
    }, 1000);
})();

[ddavies-integral]

Cool. Not being a user of the who-reacted tooltip I hadn't noticed any negative side-effects of doing all of them. I see you ES6'ed it too. It was a copy/paste of a script I wrote at least 10 years ago, didn't have the motivation to update it.

[samsonjs]

I know it's not useful to pile on with a "me too" but I'm dying here. Please tackle this one soon, I'm literally begging you to make this a high priority 🙏 This has really affected my productivity and I wish I was joking or exaggerating but it truly is that rough.

Apparently almost every time I want to click this button I move my mouse up from the bottom and it blocks my click before the tip even appears. You can't see it but I click once or twice before it shows up in this gif.

[geoff-vsco]

I think it's useful to pile on with a "me too", because hopefully it will signal that more users are annoyed by this. Hence, I'm piling on.

+1. Me too. I'm highly annoyed by this. Please fix it.

This bug also reminds me how I think unsolicited tooltips are generally bad UI/UX practice, commonly used as a design crutch. Even worse in this case, the same information keeps getting repeated ad naseum. As a user, if I don't get the "Expand Up" idea by the first or second tooltip, what makes GitHub think I'll get it on the 1,000th showing? But anyway, the inherent bad practice of unsolicited tooltips is a debate for another day.

[mikhoq]

I was about to say something similar. Tooltips are useless, and a hinderance, after about two minutes of using a site. Get rid of them, or at least allow me to turn them off via a setting. Ugh! Horrible from a UI design point of view, and seems to be more about being able to say "Look! We have all the two million accessibility features implemented, popups on everything!".

[gsaunders-sw2]

Not all of them get in the way, it looks like just the ones that are tool-tip elements do (there are others that are a tags which do not have this blocking effect).
In any case until this is fixed, using the following bookmark will remove them from the page (the elements always are on the page and get made visible after an event triggers, this will remove them completely so they cannot be made visible) ... useful when looking at large PRs and wanted to expand lines/files without getting frustrated by this bug.:
javascript:void((function(){{var x=document.getElementsByTagName('tool-tip');for(var i=x.length;i>0;){x[--i].parentNode.removeChild(x[i]);}}})())

[shuaitq]

problem

In "Files changed" tab when people have read a file and want to fold it.

page often looks like this

• the fold button is at the top left of the page
• mouse in middle of the page
• an expand up button below the fold button

when people want to fold the file and move mouse to the top left. if the mouse passes over the expand button, an "Expand Up" label will pop up and block the fold button as below.

which is very annoying. because it happens so often, and you need to move mouse out of the "Expand Up" label and move to the fold button again.

suggest

maybe changing the "Expand Up" label don't block the fold button will be better.

[JSn1nj4]

There's also an overlay or invisible container where the tooltip shows up.

I think what's happening is, your mouse runs over the "expand up" control, the overlay opens immediately, and then it has a delay to check if you really meant to have your mouse over the "expand up" control.

But since your mouse is now over an overlay that opened right away, it thinks you want the tooltip for the control.

What they probably need to do is not bring the overlay to the front until right before the tooltip should render.

[zhiyi-zhang-duke]

Apparently I opened up the exact same issue. Just wanted to pile on and say me too. I do think this is a pretty easy solution. Really hoping github resolves this soon.

[joaqbarcena]

Also wanted to be on the pile, as someone pointed out up there this kinda tooltip is just annoying and useless, is there any metric that demonstrate this tooltip has improved the Expand actions?? In that case we should be able to disable them or just removing after a first use

[simon-abbott]

Joining the pile here since it's still an issue. This is seriously affecting my productivity while reviewing large PRs since I also apparently click the "collapse file" button by moving my mouse from the bottom up. Please please please fix this.

Here are my suggested fixes, in order of preference:

1. Just remove the tooltip altogether
2. Make it so having the mouse over the tooltip doesn't keep it open, especially when it hasn't even displayed yet
3. Move the tooltip so it doesn't block other UI (maybe placed on the left?)

[ddavies-integral]

I think we're wasting our time here. Just looking at the URL of this topic it's listed as community/discussions. I don't think anyone's looking here for bugs to fix and the fact that it's 4 months since it was first logged (aka 'discussed') without any kind of confirmation that it will be worked on or even acknowledged, we can give up.

While I'm here though, and for no good value typing it .... where's the collapse file button at the end of a file's changes? What I find myself doing is scrolling down through the changes to a file, then having to scroll all the way back up to where the collapse file button is - this can be a dozen scrolls on the mouse scroll wheel. A collapse file button at the end of the file too would improve things a lot. Do people at github themselves not do code reviews of their own department's changes? You can't do this on a regular basis and not see these issues.

[simon-abbott]

The file header, including the collapse button, is stickied at the top of the page when you scroll past it. There is always a collapse button for every diff currently visible on the page.

[ddavies-integral]

You're absolutely right of course. Since installing my greasemonkey script this issue isn't really troubling me. I just remove all those tooltips from the dom and it's joyous code reviews all the way. It'll go even more smoothly now you've pointed out I didn't need to keep scrolling up. More time for agile meetings 👍

[brianpeiris]

Pre-Microsoft GitHub would have fixed this in a week :(

[JSn1nj4]

Any chance on this? Still super annoying to work around.
https://github.com/orgs/community/discussions/54674#discussioncomment-7115119

[wmacaluso]

friendly bump, everyone on our team is frustrated by this :)

[ymuzyukin-mwb]

Submitted this as a bug to GitHub support. And would love to share the link to the ticket, but the ticket is private, and I didn't find a way to make it public.
Let's see what would be the response from the support...

[ymuzyukin-mwb]

Ok, GitHub support responded. They say they already have similar issues reported, but there are no any plans to address it as a quick fix. Rather they are working on a bigger change for the view in question. And they expect our pain point to be addressed as well with those bigger changes. No any ETA was provided.

My only recommendation to anyone annoyed by the issue for now is to use workarounds with scripts provided above. And/or submit your own issue to GitHub support: https://support.github.com/contact/bug-report. As they have mentioned that they added my report to theirs similar reports. Maybe the amount of such reports could influence the priority for this, who knows.

[geoff-vsco]

Thanks, ymuzyukin-mwb!