Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13995

Would like the ability to disable hover-over context menus.

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Jenkins 1.464
      CentOS 6.0 x64 Master, multiple slaves

      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.

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

          Joe Hansche added a comment - - edited

          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)

          Joe Hansche added a comment - - edited 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)

          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.

          G. Ann Campbell added a comment - 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.

          di kn added a comment -

          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.

          di kn added a comment - 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.

          Jesse Glick added a comment -

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

          Jesse Glick added a comment - @dikndd feedback on 1.510 is irrelevant since the implementation was heavily modified in 1.513.

          Bernd bep added a comment -

          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)

          Bernd bep added a comment - 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)

          Dale King added a comment -

          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

          Dale King added a comment - 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

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Phil Miller added a comment -

          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.

          Phil Miller added a comment - 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.

          Idan Bidani added a comment -

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

          Idan Bidani added a comment - liked the hover menu Just updating from 1.509.4, sadly realized the hover is gone.

          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.

          Kohsuke Kawaguchi added a comment - 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.

            kohsuke Kohsuke Kawaguchi
            khushsk Sagar Khushalani
            Votes:
            34 Vote for this issue
            Watchers:
            33 Start watching this issue

              Created:
              Updated:
              Resolved: