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

Autocomplete box in text boxes is not selectable using the enter key

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • core
    • Windows 7 64 bit
      Jenkins 1.403
      Opera 11.10
      Firefox 4.0

      Jenkins closes/saves the project configuration if the user presses RETURN in a text field. If the text field has a Jenkins provided auto-completion (or an auto-completion of a browsers like Firefox) then Jenkins also saves the configuration upon selecting a value in the auto-completion list. This is irritating since the user does not expect that a dialog will be closed due to a selection in a list. Either provide a new shortcut to close/save a dialog (as it is done in Jira using ALT-S) or provide a special handling for ENTER if there is a auto-completion in progress.

      Old Issue description:

      Under the build triggers block in the job configuration if you check off "Build after other projects are built" and start typing a project name, the auto complete box that offers possible suggestions for jobs you want to set as triggers does not respond to the enter key.

      For example I type test, it tells me available jobs are test-1 and test-2, I use the arrow key to scroll down to test-1 and press enter it will save and exit the configuration rather than select test-1 because the enter key is still tied to the save button.

      *Also I believe that Projects names is a grammatical error, and should instead be Project names.

          [JENKINS-9597] Autocomplete box in text boxes is not selectable using the enter key

          Ulli Hafner added a comment -

          Reopening since this actually is a bug (or at least leads to a bad user experience). We should not change common UI patterns in Jenkins. If we need a shortcut to finish a screen then we should define a new one instead of reusing an existing key that has a different semantic.

          Ulli Hafner added a comment - Reopening since this actually is a bug (or at least leads to a bad user experience). We should not change common UI patterns in Jenkins. If we need a shortcut to finish a screen then we should define a new one instead of reusing an existing key that has a different semantic.

          Another annoyed user, happens just about every time I login to Jenkins and every 3rd time I start a build with parameters

          In my opinion the enter key is quite alright (and common) to use as a hotkey for submitting a form, however NOT while you are in "autocompletion mode". For jquery I have been using a nice plugin called SafeEnter (http://plugins.jquery.com/project/SafeEnter) which basically disables the Enter event if your previous keystroke was up,down,pgup or pgdown.

          The protection from a method like SafeEnter will not be 100%, but so far it has worked very well where I have implemented it.

          Emil Ljungdahl added a comment - Another annoyed user, happens just about every time I login to Jenkins and every 3rd time I start a build with parameters In my opinion the enter key is quite alright (and common) to use as a hotkey for submitting a form, however NOT while you are in "autocompletion mode". For jquery I have been using a nice plugin called SafeEnter ( http://plugins.jquery.com/project/SafeEnter ) which basically disables the Enter event if your previous keystroke was up,down,pgup or pgdown. The protection from a method like SafeEnter will not be 100%, but so far it has worked very well where I have implemented it.

          Ari Hyttinen added a comment -

          I just ended up disabling autocompletion on a textbox in a build step config.jelly, after having just implemented it, because I accidentally saved the job twice during testing. Considering how the job would usually not be fully configured at that point (especially since my textbox uses autoCompleteDelimChar), and considering the worst case side effects of submitting badly configured job (in my case on the level of "annoying to other people"), I find the behavior unacceptable for the end users.

          Any javascript/jelly gurus who could provide a workaround piece of javascript? It would be nice, if this could be fixed in the plugin itself, for fields where it is important that reflexive enter press does not save the form? Also, having that workaround code would probably be a good first step on getting Jenkins itself "fixed", whatever that would mean in this case.

          Ari Hyttinen added a comment - I just ended up disabling autocompletion on a textbox in a build step config.jelly, after having just implemented it, because I accidentally saved the job twice during testing. Considering how the job would usually not be fully configured at that point (especially since my textbox uses autoCompleteDelimChar), and considering the worst case side effects of submitting badly configured job (in my case on the level of "annoying to other people"), I find the behavior unacceptable for the end users. Any javascript/jelly gurus who could provide a workaround piece of javascript? It would be nice, if this could be fixed in the plugin itself, for fields where it is important that reflexive enter press does not save the form? Also, having that workaround code would probably be a good first step on getting Jenkins itself "fixed", whatever that would mean in this case.

          Stas Gromov added a comment -

          +1.... very annoying behaviour on login page...
          I hate this form!
          PLEASE change Enter handling when selecting smth from autocomplete suggest

          Stas Gromov added a comment - +1.... very annoying behaviour on login page... I hate this form! PLEASE change Enter handling when selecting smth from autocomplete suggest

          Daniel Beck added a comment -

          Cannot reproduce on Jenkins 1.561 with Firefox 29.0.1 on OS X. Both autocomplete text boxes and the descriptor lists (e.g. 'Add build step') do not trigger form submit after selecting an item using the keyboard and pressing Return.

          Needs confirmation that this issue is still relevant to current Jenkins versions. Be specific: Which form (vanilla Jenkins!), which browser, OS, Jenkins version? What's your input, the exact sequence of keys you press?

          Daniel Beck added a comment - Cannot reproduce on Jenkins 1.561 with Firefox 29.0.1 on OS X. Both autocomplete text boxes and the descriptor lists (e.g. 'Add build step') do not trigger form submit after selecting an item using the keyboard and pressing Return. Needs confirmation that this issue is still relevant to current Jenkins versions. Be specific: Which form (vanilla Jenkins!), which browser, OS, Jenkins version? What's your input, the exact sequence of keys you press?

          Stas Gromov added a comment -

          reproduced on https://ci.jenkins-ci.org/login?from=%2F
          Browser: Firefox 29.0.1
          User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
          OS: ArchLinux (x86_64 GNU/Linux)
          Jenkins ver. 1.565-SNAPSHOT (rc-05/20/2014 18:32 GMT-kohsuke)

          steps:
          1.mouse left-click in first field (field was selected)
          2.keypress down-arrow-key (drop-down menu was showed)
          3.keypress down-arrow-key once more time (first option in drop-down menu was selected)
          4.press "Enter" key to select this option.

          Expected: option, selected in drop-down-menu, will be in field
          Actual: option, selected in drop-down-menu, was shown in field and then form automaticaly submits. And then screen with " Invalid login information. Please try again.
          Try again" was shown

          Stas Gromov added a comment - reproduced on https://ci.jenkins-ci.org/login?from=%2F Browser: Firefox 29.0.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 OS: ArchLinux (x86_64 GNU/Linux) Jenkins ver. 1.565-SNAPSHOT (rc-05/20/2014 18:32 GMT-kohsuke) steps: 1.mouse left-click in first field (field was selected) 2.keypress down-arrow-key (drop-down menu was showed) 3.keypress down-arrow-key once more time (first option in drop-down menu was selected) 4.press "Enter" key to select this option. Expected: option, selected in drop-down-menu, will be in field Actual: option, selected in drop-down-menu, was shown in field and then form automaticaly submits. And then screen with " Invalid login information. Please try again. Try again" was shown

          Ulli Hafner added a comment -

          Can also verify that this still does not work for textboxes using Firefox auto complete feature.

          Ulli Hafner added a comment - Can also verify that this still does not work for textboxes using Firefox auto complete feature.

          Daniel Beck added a comment -

          Right. The browser's autocomplete, rather than Jenkins/AJAX autocomplete. That makes sense.

          Note that the original issue description seems to indicate a Jenkins/AJAX autocomplete popup, and I was unable to reproduce the behavior on those.

          Daniel Beck added a comment - Right. The browser's autocomplete, rather than Jenkins/AJAX autocomplete. That makes sense. Note that the original issue description seems to indicate a Jenkins/AJAX autocomplete popup, and I was unable to reproduce the behavior on those.

          Ulli Hafner added a comment -

          I think it did not work in both cases. Seems that at least the drop-down selection is ok now.

          Ulli Hafner added a comment - I think it did not work in both cases. Seems that at least the drop-down selection is ok now.

          Daniel Beck added a comment - - edited

          Debugged to YAHOO.widget.Button.onFormKeyPress in button-debug.js. We're entering the condition on line 3705.

          This seems to be the upstream bug report, except that Jenkins uses YUI 2.9.0: http://yuilibrary.com/projects/yui2/ticket/1743305

          Isse can be reproduced on this form, so it's definitely a YUI issue: http://yui.github.io/yui2/docs/yui_2.9.0_full/examples/button/btn_example05.html

          Daniel Beck added a comment - - edited Debugged to YAHOO.widget.Button.onFormKeyPress in button-debug.js . We're entering the condition on line 3705. This seems to be the upstream bug report, except that Jenkins uses YUI 2.9.0: http://yuilibrary.com/projects/yui2/ticket/1743305 Isse can be reproduced on this form, so it's definitely a YUI issue: http://yui.github.io/yui2/docs/yui_2.9.0_full/examples/button/btn_example05.html

            Unassigned Unassigned
            oseparovic oseparovic
            Votes:
            5 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: