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

IE 9 regular mode: Enter does not work to submit forms

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core

      In IE 9 on Windows 7 in regular mode, pressing the Enter key does not submit forms (such as the login form) as expected. It does work in compatibility mode.

          [JENKINS-22373] IE 9 regular mode: Enter does not work to submit forms

          Jesse Glick created issue -

          Tom FENNELLY added a comment -

          Here's a possible fix for this issue using Javascript: https://github.com/tfennelly/jenkins/tree/JENKINS-22373 That was the only thing I could find that fixed it (only tested on the login screen so far).

          There was also a suggestion that <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> would fix it. I tried that but it didn't work.

          Tom FENNELLY added a comment - Here's a possible fix for this issue using Javascript: https://github.com/tfennelly/jenkins/tree/JENKINS-22373 That was the only thing I could find that fixed it (only tested on the login screen so far). There was also a suggestion that <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> would fix it. I tried that but it didn't work.

          Jesse Glick added a comment -

          Looks like a hack but maybe that is what we need. File a pull request in case someone else with knowledge of IE issues has an idea.

          Jesse Glick added a comment - Looks like a hack but maybe that is what we need. File a pull request in case someone else with knowledge of IE issues has an idea.
          Jesse Glick made changes -
          Assignee New: Tom FENNELLY [ tfennelly ]

          Beware that a generic JS hook to submit the form on Enter keypress may interfere with controls that are designed to consume Enter, like textarea [very bad]. This may also interfere with plugins that customize the behavior of Enter [bad for unknown subset of plugins]. Finally, hooking forms during onload will miss form elements that are injected into the DOM after onload [bad since it creates inconsistencies in form handling].

          Is the goal here to really make it so enter-on-submit is the default for all forms? Clicking Enter on the Jenkins Job Configure form does not auto-submit for me on Chrome....why is that the desirable behavior on IE9?

          If something in the Jenkins DOM or default JS scripts is interfering with the standard IE 9 Enter key behavior then finding the root cause of that to restore standard behavior generically seems like logical fix. However, if this is intended to change the default form-handling behavior of IE, then isolating this change to specific forms where submit-on-enter is specifically known to be highly desirable and non-breaking seems more appropriate (for example, the login form).

          Spike Washburn added a comment - Beware that a generic JS hook to submit the form on Enter keypress may interfere with controls that are designed to consume Enter, like textarea [very bad] . This may also interfere with plugins that customize the behavior of Enter [bad for unknown subset of plugins] . Finally, hooking forms during onload will miss form elements that are injected into the DOM after onload [bad since it creates inconsistencies in form handling] . Is the goal here to really make it so enter-on-submit is the default for all forms? Clicking Enter on the Jenkins Job Configure form does not auto-submit for me on Chrome....why is that the desirable behavior on IE9? If something in the Jenkins DOM or default JS scripts is interfering with the standard IE 9 Enter key behavior then finding the root cause of that to restore standard behavior generically seems like logical fix. However, if this is intended to change the default form-handling behavior of IE, then isolating this change to specific forms where submit-on-enter is specifically known to be highly desirable and non-breaking seems more appropriate (for example, the login form).

          After reviewing with Tom, it turns out that the configure page does actually have the submit-on-enter behavior for standard input elements in the form. It happened that the input I tested with previously was specialized (number input) and was likely overriding the Enter behavior. So finding what's blocking this standard Jenkins form behavior seems worthwhile.

          Spike Washburn added a comment - After reviewing with Tom, it turns out that the configure page does actually have the submit-on-enter behavior for standard input elements in the form. It happened that the input I tested with previously was specialized (number input) and was likely overriding the Enter behavior. So finding what's blocking this standard Jenkins form behavior seems worthwhile.

          Tom FENNELLY added a comment - - edited

          Looked at this again today and think I found a more appropriate fix. See new version of https://github.com/tfennelly/jenkins/tree/JENKINS-22373

          I tracked the issue down to the YUI button. It's not correctly firing Enter keypress events for IE >= 9 (should call dispatchEvent instead of fireEvent for IE >= 9). The change in the above branch fixes the issue for the login screen and any other "submit-button" inputs that hudson-behavior.js" is applying YUI to. YUI calls fireEvent in other places, so this issue might raise its head again in another form.

          How have ye been minifying this code on other such changes (I see there have been a few)?

          Tom FENNELLY added a comment - - edited Looked at this again today and think I found a more appropriate fix. See new version of https://github.com/tfennelly/jenkins/tree/JENKINS-22373 I tracked the issue down to the YUI button. It's not correctly firing Enter keypress events for IE >= 9 (should call dispatchEvent instead of fireEvent for IE >= 9). The change in the above branch fixes the issue for the login screen and any other "submit-button" inputs that hudson-behavior.js" is applying YUI to. YUI calls fireEvent in other places, so this issue might raise its head again in another form. How have ye been minifying this code on other such changes (I see there have been a few)?

          Jesse Glick added a comment -

          By the way the more helpful link (precursor to a PR) is: https://github.com/tfennelly/jenkins/compare/JENKINS-22373

          Jesse Glick added a comment - By the way the more helpful link (precursor to a PR) is: https://github.com/tfennelly/jenkins/compare/JENKINS-22373

          Jesse Glick added a comment -

          I am not sure how minifying works. I once did a change to something like, IIRC in Prototype, and just manually edited the minified version (ick). Obviously integrating a Maven plugin to do the minification during a build would be ideal.

          Jesse Glick added a comment - I am not sure how minifying works. I once did a change to something like, IIRC in Prototype, and just manually edited the minified version (ick). Obviously integrating a Maven plugin to do the minification during a build would be ideal.

          Tom FENNELLY added a comment -

          Talked to KK about this. He was not aware that changes were being made to the YUI code. 6 have been made in total since the update to v2.9 (not including this change). See JENKINS-23405.

          Re minification... it's all obfuscated so changing by hand is a last resort imo. I tried an online YUI compressor. Output is formatted differently and the obfuscation is not exactly the same, but it seems to work (pushed to the same branch if you want to look). Might be dangerous though I think? Maybe we need to fork YUI2 as suggested by KK in JENKINS-23405.

          Tom FENNELLY added a comment - Talked to KK about this. He was not aware that changes were being made to the YUI code. 6 have been made in total since the update to v2.9 (not including this change). See JENKINS-23405 . Re minification... it's all obfuscated so changing by hand is a last resort imo. I tried an online YUI compressor. Output is formatted differently and the obfuscation is not exactly the same, but it seems to work (pushed to the same branch if you want to look). Might be dangerous though I think? Maybe we need to fork YUI2 as suggested by KK in JENKINS-23405 .

            tfennelly Tom FENNELLY
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: