[JENKINS-13995] Would like the ability to disable hover-over context menus.

[timja]

The context menu was added as a feature a few versions ago.
While it is useful for many (probably most), I would like to suggest an enable/disable switch of some sort for it - preferably something that users can set individually instead of having it site-wide.

---

Originally reported by khushsk, imported from: Would like the ability to disable hover-over context menus.

• assignee: kohsuke
• status: Resolved
• priority: Major
• resolution: Fixed
• resolved: 2014-06-09T21:21:41+00:00
• imported: 2022/01/10

[timja]

mrysanek:

Yes. Obscures features, some of us really (and I mean REALLY ) hate popups, changes the workflow as in I can no longer right-click on a job in a tab to open it on another tab and continue to the next job.

Please.

Remove it or allow disabling.

Thank you.

[timja]

sirkkalap:

Another example of obscured and broken functionality is the ability to navigate with keyboard from tab to tab in browsers, when the popup steals focus on Jenkins pages.

It also is not easy to copy & paste job links or build links when the popup obscures the links and breaks copy operation.

I guess it is important to save clicks too, but for me it is not the clicks that are the problem, instead it is the page load and render speed.

So I wish that popup menus would be optional, either globally and/or by user.

[timja]

eyealike:

They pop up to early, too often and obscure too much content. I hardly ever use them, I'm just constantly swatting them away like flies. Of course, this is just subjective so I suggest conducting a poll about this feature in a prominent place on the site or in the Jenkins UI itself.

[timja]

marc_swingler:

"I'm just constantly swatting them away like flies." I'll second that comment.

[timja]

jglick:

Try making a plugin with JavaScript in the page footer calling

Behaviour.specify("A.model-link", 'breadcrumbs', 100, function (a) {
    $(a).stopObserving("mouseover");
});

(Cf. breadcrumbs.js.) Might work.

Ideally would be a per-user setting configured perhaps with a cookie set by a small link in the page header/footer, say near “ENABLE AUTO REFRESH”.

[timja]

shish:

Maybe binding to "contextmenu" (ie, right-click) rather than "mouseover" would be less annoying? Less obvious that the feature is there though...

[timja]

bep:

Those context menus also hide/conflict with regular tooltips.

E.g. if you want to check the time I job needs to finish, the tooltip with that information is hidden by this context menu.

Assigning the context menu to the right mouse button looks like a good approach to me.

[timja]

jglick:

The main problem I see with the right mouse button is discoverability: so few web apps use it that a user may never think to look for it.

Also it would conflict with browser-specific functions available on links, such as opening in a new tab. That could possibly be worked around by placing the original link at the top of the context menu so you can right-click on it again for these functions.

[timja]

sirkkalap:

Maybe a dropdown menu could work. Place a small triangle before the link and bind mouseclick listener to it. So then it might be discovered, it would be separate from normal links and would not popup unneccessarily.

[timja]

cdandoy:

+1. Those popups are annoying. I have tried to get used to them but after a few months of frustration I finally have decided to create an account and complain.

IMHO, I very much doubt that this feature is considered as an improvement by the majority of your users.
I would personally be satisfied if it could be disabled by a user setting but quite honestly I suspect you will achieve greater satisfaction by turning it off by default.

[timja]

kohsuke:

We dicussed this in FOSDEM 2013, where we basically agreed on working toward the direction of this comment.

I'll post the note to Wiki.

[timja]

scm_issue_link:

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/resources/lib/layout/breadcrumbs.css
core/src/main/resources/lib/layout/breadcrumbs.js
core/src/main/resources/lib/layout/menu_down_arrow.png
http://jenkins-ci.org/commit/jenkins/b41aa9e0a6489ec8f45aaf1c9f7cd3ad81419adf
Log:
JENKINS-13995 Disabled the automatic pop-up of context menu.

Instead, it shows a small 'v' icon to the right that needs to be clicked
to open a context menu.

[timja]

jglick:

Better. Still pops up context menu automatically in crumb bar; is this intentional and should be the issue be marked fixed?

[timja]

bep:

IMHO, the context menu should not open automatically in the crumb bar.

[timja]

dogfood:

Integrated in jenkins_main_trunk #2420

Result = UNSTABLE

[timja]

adamashley:

So how do I turn this feature back on? The automatic drop down made the dashboard much more useful. The new tiny appearing down arrow that has a tiny hover and click area is worse that useless. Its quicker to click to the project page, wait for it to load, then click the item you wanted from the drop down then it is try to use the drop down now. Don't get me started on how often the drop down icon simply doesn't appear even tho you are hovered over and click the link to the project page.

This change should be done as the original bug report suggested, a configurable options.

[timja]

rking:

The current widget is hard to use. I liked the way it was before, but I understand that not everyone does, so maybe we can figure out something that works for all of us?

The problem is that it's not discoverable. You mouse over and get this tiny "v", which isn't obvious that if you then click on that, you'll get a menu.

One option would be to make the "v" always visible, and hopefully a bit bigger.

Note that, on our server, every web hit takes quite a while, so the popout menu is nice: it makes it clear that you don't have to actually go to the intermediate step to get where you want.

[timja]

jglick:

@adamashley agreed there are problems with the UI that need fixing. For me, the arrow generally disappears when I try to click on it. I can only use it if I position my mouse within a very narrow margin, a pixel or two.

@rking if HTTP service is slow, making the context menu not appear unless and until clicked should improve things a bit, since displaying the context menu is also an HTTP request that adds to server load. Formerly, a lot of context menu background requests were made and then discarded as the mouse just incidentally swept by any number of model links.

[timja]

ganncamp:

I agree that the 'v' is hard to use. If I can't have the old functionality back (which I loved) how about you don't have to click on the 'v' it just drops down automatically?

[timja]

ganncamp:

Was the queue time popup for jobs in the build queue supposed to be incorporated into the now-non-default context menu? Since the context menu is now a separate function, I'd like to see the queue time popup return.

[timja]

rking:

@jesse - Oops, you're totally right. I misstated. I ended up downgrading because of strange web server instability issues, and I have to reiterate my intent (though my expression of it was wrong): with the popup menu, the UI is much more usable for me. Perhaps it's because that menu is easier to serve (it's smaller, and perhaps contends for fewer querying resources on the server-side)? Whatever the case, the 1.4x experience is a lot more navigable for me.

Would it be hard to just pregenerate that content for every page then use JS to show/hide it?

[timja]

jglick:

@ganncamp: removing the click trigger would reintroduce most or all of the problems with the original system, and we need to fix the problems of the new UI anyway. One possibility I did not see brought up is to remove the v and just let the user click on the regular hyperlink to show a context menu; it could be displayed in such a position that double-clicking would effectively follow the “main” link.

The queue time probably ought to once again be in a real tooltip. I think there was code that hijacked tooltips and stuck them in the context menu, so you could see both at once, which is now obsolete and should be reverted.

@rking: would be tricky now for technical reasons to pregenerate the context menu items, though I agree that would make a certain amount of sense if this were being designed from scratch.

[timja]

ganncamp:

@Jesse: Please, please, please don't turn single-clicks into double-clicks!

I like the OP's request best: make the context menu behavior a setting (user-level? system-level?)

I love the hover menus. Clearly others hate it. But why make half the crowd unhappy? Make it configurable, default to whatever pleases the loudest group of agitators.

[timja]

jglick:

Kohsuke is playing with the current impl, which is apparently not working the way it was intended to work. Once that is fixed we can reëvaluate whether a per-user switch is really needed; we do not want to introduce an option just to cover up a bug.

[timja]

scm_issue_link:

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/src/main/resources/lib/layout/breadcrumbs.js
http://jenkins-ci.org/commit/jenkins/6fb7a50d07d2332eee5a88e06baff12ea6fce3a5
Log:
JENKINS-13995

Fixed a bug where the context menu anchor 'v' disappears even when the mouse is still over a model link.

[timja]

scm_issue_link:

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/resources/lib/layout/breadcrumbs.js
http://jenkins-ci.org/commit/jenkins/084da443e1428d0d3bb83325e628a6665fc1f09e
Log:
JENKINS-13995

Added logging more liberally, and fixed the problem.
The root cause was that when the mouse enters a hot spot, I wasn't cancelling the previous delayed hide timer.

This fix eliminates the need for the hack in the hide method where I was testing if the mouse was still over the hotspot.

Compare: https://github.com/jenkinsci/jenkins/compare/293403f3d10e...084da443e142

[timja]

kohsuke:

The above change will be in 1.512. More feedback appreciated on that version.

[timja]

dogfood:

Integrated in jenkins_main_trunk #2465
JENKINS-13995 (Revision 6fb7a50d07d2332eee5a88e06baff12ea6fce3a5)
JENKINS-13995 (Revision 084da443e1428d0d3bb83325e628a6665fc1f09e)

Result = SUCCESS
kohsuke : 6fb7a50d07d2332eee5a88e06baff12ea6fce3a5
Files :

• core/src/main/resources/lib/layout/breadcrumbs.js

kohsuke : 084da443e1428d0d3bb83325e628a6665fc1f09e
Files :

• changelog.html
• core/src/main/resources/lib/layout/breadcrumbs.js

[timja]

scm_issue_link:

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/src/main/resources/lib/layout/breadcrumbs.js
war/src/main/webapp/scripts/hudson-behavior.js
http://jenkins-ci.org/commit/jenkins/11bc7ce933a8628e60cffff5061e741e31d06d3a
Log:
JENKINS-13995

Now that the context menu is open only when clicking 'v', the tooltip on model link should
be displayed as soon as the mouse hovers over it.

[timja]

scm_issue_link:

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/src/main/resources/lib/layout/breadcrumbs.css
core/src/main/resources/lib/layout/breadcrumbs.js
core/src/main/resources/lib/layout/menu_down_arrow.png
http://jenkins-ci.org/commit/jenkins/9cddeba7b2f82eec42e3b00e549dc1c55a193d48
Log:
JENKINS-13995

Made the 'v' icon bigger to increase the hit test area, and improved the alignment
logic so that the text and the 'v' icon gets vertically aligned.

[timja]

adamashley:

@Jesse "we do not want to introduce an option just to cover up a bug." what bug? Looking through the history of this issue I see a valid request by someone to be able to turn off something he doesn't like which was transformed into a removal of a useful feature to satiate a vocal few.

[timja]

dogfood:

Integrated in jenkins_main_trunk #2468
JENKINS-13995 (Revision 11bc7ce933a8628e60cffff5061e741e31d06d3a)
JENKINS-13995 (Revision 9cddeba7b2f82eec42e3b00e549dc1c55a193d48)

Result = SUCCESS
kohsuke : 11bc7ce933a8628e60cffff5061e741e31d06d3a
Files :

• core/src/main/resources/lib/layout/breadcrumbs.js
• war/src/main/webapp/scripts/hudson-behavior.js

kohsuke : 9cddeba7b2f82eec42e3b00e549dc1c55a193d48
Files :

• core/src/main/resources/lib/layout/breadcrumbs.css
• core/src/main/resources/lib/layout/menu_down_arrow.png
• core/src/main/resources/lib/layout/breadcrumbs.js

[timja]

kohsuke:

Given the strong feeling from both sides, maybe I can create a plugin that provides this as an user preference.

[timja]

jhansche:

Screenshots attached

IMO, there is a pretty simple way to fix this for both camps. The example I'm going to use is in JIRA (5.2 – this version does not behave the same). Several of the fields on the View-Issue page can be edited inline by just hovering over the field (which changes the appearance immediately, making it obvious that it's editable, and introducing a pencil/edit icon next to the field), and when you click (either on the text or on the pencil icon), it transforms into an editable field. You can see that with the 3 screenshots I'm attaching.

I think a good way to fix this problem would be to follow similar logic: instead of having the menu pop up on hover of the link itself, change it so hovering on the link transforms the appearance of the link into something that has the down-arrow icon and draws attention to that icon. Then you can make it where hovering (or clicking, if people are still adamant that it gets in the way) on the down-arrow icon brings up the context menu. That way the hover effect will not be as distracting to people who dislike it, and the context menu is still discoverable and easy to access for people who do like it.

I use the context popup all the time, because it does take so long to jump around, especially when the important part of a build that I need to get to quickly is the build's console. But yes, it does have many quirks – especially when I'm trying to reconfigure several jobs at a time (hover, cmd+click "Configure" link; next job: hover, cmd+click configure; etc...), the menu from one used to always cause the menu for the one I'm aiming for to disappear prematurely, etc. Sounds like KK fixed that particular issue, so that's nice .. but too little too late, since now the hover feature itself is completely gone :\

I think if the down-arrow appears on hover of the link, and hovering on the down-arrow brings up the menu, it would appease those who prefer not to see the context menu, while still making it easily discoverable and accessible for people who do (no clicking required, just hover on the link, move over to the arrow icon, and the menu comes out)

[timja]

ganncamp:

I've just installed 1.512 & feedback was requested.

I'm not seeing the mouseover popup of build queue items and/or jobs currently being run. I was under the impression that would come back.

As for the "v", I still don't like it, but it seems to work as designed. However, the spacing is a little crowded in the list of running jobs. It also looks crowded on the build number in the last failure/last success column. Haven't looked exhaustively at other places.

[timja]

dikndd:

After updating to 1.510 I got a lot of feedback from our about 30 users complaining about the new approach with the down arrow.
They miss the pop up menu now and complain about it's removal without choice.

I know that the popup menu solution was not perfect in every case - it has drawbacks.
But I can't see that the current 'v' solution has achieved a better degree of being perfect !

• using the 'v' requires special, fine tuned move-and-click - annoying for everyone who used the popup menu so far with its bigger click-able areas in
• often the 'v' disappears before you can move the mouse-pointer to it and click on it
• if the link, to which the 'v' belongs, is followed by other text that does not belong to the link text, then the 'v' is hard to see because it has a completely transparent background

From my opinion you should really offer to the users a choice to use the popup menu or not.
Even a system wide setting would be sufficient to keep user groups on going with what they are familiar with.

As a second step a more perfect solution could be developed in the lab.

[timja]

jglick:

@dikndd feedback on 1.510 is irrelevant since the implementation was heavily modified in 1.513.

[timja]

bep:

1.514 looks good to me.

A suggestion: A click on the "v" when the menu is already visible could close the menu again. (If you accidentally open the menu you can easily close it again)

[timja]

dalewking:

In my opinion the pop-up menus that popped up with mouse hover were the PRIMARY ADVANTAGE that Jenkins had over Hudson! Bring them back!

I can understand the need to allow it to be disabled, but not for getting rid of it entirely. The hover menus allowed me to get to almost anywhere in Jenkins with a single click. The new version is back to the multiple clicks and page loads to get anywhere that drove me crazy in Hudson.

Note I will be upgrading to an older version until this is fixed.

I wonder if it would be possible to restore old functionality with a grease monkey script

[timja]

danielbeck:

Another option: When hovering one of these links, right-clicking opens the context menu. This would significantly increase the clickable area to open the context menu. Of course, you'd need to learn which links support this, so the triangle or some other indicator should stay.

Artifactory works like that when you right-click any entry in the tree on the left: http://repo.jenkins-ci.org/webapp/browserepo.html

A possible downside is that these links have no normal context menu anymore, e.g. for copying the link URL without navigating there, or for those users who haven't learned to use keyboard modifiers to open links in new windows or tabs.

[timja]

millenix:

I'm running 1.532.2 (LTS), and just got this change in the upgrade from 1.509. Count me as another voice in the "liked the hover menu" camp. Its implementation may not have been optimal (especially given the complaints from users it was hindering), but not having it (and thus having to click to get the drop-down) definitely makes things worse for me.

[timja]

iplaman:

liked the hover menu
Just updating from 1.509.4, sadly realized the hover is gone.

[timja]

kohsuke:

1.513 has the last substantial change on the way context menu is displayed; in this version, a small 'v' icon appears to the next of links, and clicking on it reveals the context menu.

This issue was originally reported against 1.464 that had a very different implementation.

I consider the change in 1.513 to have sufficiently addressed the original issue of the reporter.

Future enhancement requests to the way context menu behaves should be filed as separate tickets.

[timja]

[Originally duplicated by: JENKINS-13620]