Loading ...
Sorry, an error occurred while loading the content.

Bug in new 2.3.1 AutoComplete enter key behavior on Mac

Expand Messages
  • Jason Levine
    I noticed that there was a change in how AutoComplete was behaving on my Mac over the weekend, and then in looking at the YUI 2.3.1 readme, I see that a change
    Message 1 of 11 , Oct 1, 2007
    • 0 Attachment
      I noticed that there was a change in how AutoComplete was behaving on my Mac over the weekend, and then in looking at the YUI 2.3.1 readme, I see that a change was made in how it responds to the enter key on Macs.  I think there's a bug in the new implementation.

      On my Mac, when an AutoComplete container is visible and I select an entry in the container with the Enter key, the whole form is submitted -- the change doesn't appear to be restricted to when the container is collapsed, as the readme says it is.  Is this intentional?  It's certainly breaking expected functionality; I suspect I have a big chunk of time ahead of me today figuring out how to work around this new behavior.  I put together a short demo of what I'm seeing:

      http://jzone.queso.org/yui231acbug/index.html 

      I haven't tested it in anything but a Mac, but certainly on my Macs, choosing an option with the Enter key from the suggestion container submits the entire form... again, this breaks what should happen, and is a somewhat annoying problem to have to figure a workaround out for.

      --- In ydn-javascript@yahoogroups.com, georgiann puckett <gpuckett@...> wrote:
      >AutoComplete
      >- When suggestion container is collapsed, Mac users no longer needto type

      >Enter twice to submit input.



    • Jason Levine
      I think I found the cause for this bug, after a few hours worth of debugging the route that the events take through the code when a user uses the Enter key to
      Message 2 of 11 , Oct 1, 2007
      • 0 Attachment
        I think I found the cause for this bug, after a few hours' worth of debugging the route that the events take through the code when a user uses the Enter key to select an option in the autocomplete suggestion box.  I think it all comes down to onTextboxKeyPress() firing before onTextboxKeyDown(), meaning that a race occurs in which the suggestion container gets closed before the test is run which decides whether to use the new Enter key behavior.  Here's what I've come up with:
        1. Autocomplete suggestion box pops up, and a user uses the arrow keys (or not) to choose an item.
        2. User presses the Enter key to select item.
        3. The Autocomplete widget's _onTextboxKeyDown() fires, and switches to case 13 (the Enter key).
        4. Just before exiting case 13 of _onTextboxKeyDown(), calls oSelf._selectItem(oSelf._oCurItem).
        5. In _oSelf._selectItem(), handles selecting the item the user was on when he pressed Enter, including the final line, which closes the suggestion container.
        6. _onTextboxKeyDown() finishes.
        7. The Autocomplete widget's _onTextboxKeyPress() fires, and switches to case 13 (the Enter key).
        8. In _onTextboxKeyPress(), tests whether the suggestion container is still open -- and since it's no longer open (because of it being closed in step 5), the key press event doesn't get interrupted, meaning that the Enter keypress submits the form.
        I've verified this every way I know how... and now, I need to figure out how to prevent it from happening, in a way that doesn't interfere with the normal operation of the Autocomplete widget.

        Any suggestions?

        Jason


        --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@...> wrote:
        >
        > I noticed that there was a change in how AutoComplete was behaving on my
        > Mac over the weekend, and then in looking at the YUI 2.3.1 readme, I see
        > that a change was made in how it responds to the enter key on Macs. I
        > think there's a bug in the new implementation.
        >
        > On my Mac, when an AutoComplete container is visible and I select an
        > entry in the container with the Enter key, the whole form is submitted
        > -- the change doesn't appear to be restricted to when the container is
        > collapsed, as the readme says it is. Is this intentional? It's
        > certainly breaking expected functionality; I suspect I have a big chunk
        > of time ahead of me today figuring out how to work around this new
        > behavior. I put together a short demo of what I'm seeing:
        >
        > http://jzone.queso.org/yui231acbug/index.html
        > <http://jzone.queso.org/yui231acbug/index.html>
        >
        > I haven't tested it in anything but a Mac, but certainly on my Macs,
        > choosing an option with the Enter key from the suggestion container
        > submits the entire form... again, this breaks what should happen, and is
        > a somewhat annoying problem to have to figure a workaround out for.

      • jennykhan
        Hi Jason, Thanks for the detailed info. Please expect this issue to be fixed in the next release of AutoComplete. In the meantime, I ve posted a workaround
        Message 3 of 11 , Oct 2, 2007
        • 0 Attachment
          Hi Jason,

          Thanks for the detailed info. Please expect this issue to be fixed in
          the next release of AutoComplete. In the meantime, I've posted a
          workaround here:
          http://developer.yahoo.com/yui/autocomplete/#knownissues

          Regards,
          Jenny



          --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@...>
          wrote:
          >
          > I think I found the cause for this bug, after a few hours' worth of
          > debugging the route that the events take through the code when a user
          > uses the Enter key to select an option in the autocomplete suggestion
          > box. I think it all comes down to onTextboxKeyPress() firing before
          > onTextboxKeyDown(), meaning that a race occurs in which the suggestion
          > container gets closed before the test is run which decides whether to
          > use the new Enter key behavior. Here's what I've come up with:
          >
          > 1. Autocomplete suggestion box pops up, and a user uses the arrow
          > keys (or not) to choose an item.
          > 2. User presses the Enter key to select item.
          > 3. The Autocomplete widget's _onTextboxKeyDown() fires, and switches
          > to case 13 (the Enter key).
          > 4. Just before exiting case 13 of _onTextboxKeyDown(), calls
          > oSelf._selectItem(oSelf._oCurItem).
          > 5. In _oSelf._selectItem(), handles selecting the item the user was
          > on when he pressed Enter, including the final line, which closes the
          > suggestion container.
          > 6. _onTextboxKeyDown() finishes.
          > 7. The Autocomplete widget's _onTextboxKeyPress() fires, and
          switches
          > to case 13 (the Enter key).
          > 8. In _onTextboxKeyPress(), tests whether the suggestion
          container is
          > still open -- and since it's no longer open (because of it being closed
          > in step 5), the key press event doesn't get interrupted, meaning that
          > the Enter keypress submits the form.
          > I've verified this every way I know how... and now, I need to figure out
          > how to prevent it from happening, in a way that doesn't interfere with
          > the normal operation of the Autocomplete widget.
          >
          > Any suggestions?
          >
          > Jason
          >
          >
          > --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@>
          > wrote:
          > >
          > > I noticed that there was a change in how AutoComplete was behaving on
          > my
          > > Mac over the weekend, and then in looking at the YUI 2.3.1 readme, I
          > see
          > > that a change was made in how it responds to the enter key on Macs. I
          > > think there's a bug in the new implementation.
          > >
          > > On my Mac, when an AutoComplete container is visible and I select an
          > > entry in the container with the Enter key, the whole form is submitted
          > > -- the change doesn't appear to be restricted to when the container is
          > > collapsed, as the readme says it is. Is this intentional? It's
          > > certainly breaking expected functionality; I suspect I have a big
          > chunk
          > > of time ahead of me today figuring out how to work around this new
          > > behavior. I put together a short demo of what I'm seeing:
          > >
          > > http://jzone.queso.org/yui231acbug/index.html
          > > <http://jzone.queso.org/yui231acbug/index.html>
          > >
          > > I haven't tested it in anything but a Mac, but certainly on my Macs,
          > > choosing an option with the Enter key from the suggestion container
          > > submits the entire form... again, this breaks what should happen, and
          > is
          > > a somewhat annoying problem to have to figure a workaround out for.
          >
        • David Lin
          Hi Jenny, I observed the same symptoms on Mozilla 1.7, enter key would trigger a a form submit instead of just setting the value in the text field. I couldn t
          Message 4 of 11 , Nov 13, 2007
          • 0 Attachment
            Hi Jenny,

            I observed the same symptoms on Mozilla 1.7, enter key would trigger a
            a form submit instead of just setting the value in the text field. I
            couldn't identify any workarounds you pointed out that is applicable.

            I use YAHOO.widget.DS_XHR.TYPE_JSON and I can't find any references to
            myDataSource.ERROR_*. Did I missed something?

            Thanks,

            David

            --- In ydn-javascript@yahoogroups.com, "jennykhan" <jennyhan@...> wrote:
            >
            > Hi Jason,
            >
            > Thanks for the detailed info. Please expect this issue to be fixed in
            > the next release of AutoComplete. In the meantime, I've posted a
            > workaround here:
            > http://developer.yahoo.com/yui/autocomplete/#knownissues
            >
            > Regards,
            > Jenny
            >
            >
            >
            > --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@>
            > wrote:
            > >
            > > I think I found the cause for this bug, after a few hours' worth of
            > > debugging the route that the events take through the code when a user
            > > uses the Enter key to select an option in the autocomplete suggestion
            > > box. I think it all comes down to onTextboxKeyPress() firing before
            > > onTextboxKeyDown(), meaning that a race occurs in which the suggestion
            > > container gets closed before the test is run which decides whether to
            > > use the new Enter key behavior. Here's what I've come up with:
            > >
            > > 1. Autocomplete suggestion box pops up, and a user uses the arrow
            > > keys (or not) to choose an item.
            > > 2. User presses the Enter key to select item.
            > > 3. The Autocomplete widget's _onTextboxKeyDown() fires, and
            switches
            > > to case 13 (the Enter key).
            > > 4. Just before exiting case 13 of _onTextboxKeyDown(), calls
            > > oSelf._selectItem(oSelf._oCurItem).
            > > 5. In _oSelf._selectItem(), handles selecting the item the
            user was
            > > on when he pressed Enter, including the final line, which closes the
            > > suggestion container.
            > > 6. _onTextboxKeyDown() finishes.
            > > 7. The Autocomplete widget's _onTextboxKeyPress() fires, and
            > switches
            > > to case 13 (the Enter key).
            > > 8. In _onTextboxKeyPress(), tests whether the suggestion
            > container is
            > > still open -- and since it's no longer open (because of it being
            closed
            > > in step 5), the key press event doesn't get interrupted, meaning that
            > > the Enter keypress submits the form.
            > > I've verified this every way I know how... and now, I need to
            figure out
            > > how to prevent it from happening, in a way that doesn't interfere with
            > > the normal operation of the Autocomplete widget.
            > >
            > > Any suggestions?
            > >
            > > Jason
            > >
            > >
            > > --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@>
            > > wrote:
            > > >
            > > > I noticed that there was a change in how AutoComplete was
            behaving on
            > > my
            > > > Mac over the weekend, and then in looking at the YUI 2.3.1 readme, I
            > > see
            > > > that a change was made in how it responds to the enter key on
            Macs. I
            > > > think there's a bug in the new implementation.
            > > >
            > > > On my Mac, when an AutoComplete container is visible and I select an
            > > > entry in the container with the Enter key, the whole form is
            submitted
            > > > -- the change doesn't appear to be restricted to when the
            container is
            > > > collapsed, as the readme says it is. Is this intentional? It's
            > > > certainly breaking expected functionality; I suspect I have a big
            > > chunk
            > > > of time ahead of me today figuring out how to work around this new
            > > > behavior. I put together a short demo of what I'm seeing:
            > > >
            > > > http://jzone.queso.org/yui231acbug/index.html
            > > > <http://jzone.queso.org/yui231acbug/index.html>
            > > >
            > > > I haven't tested it in anything but a Mac, but certainly on my Macs,
            > > > choosing an option with the Enter key from the suggestion container
            > > > submits the entire form... again, this breaks what should
            happen, and
            > > is
            > > > a somewhat annoying problem to have to figure a workaround out for.
            > >
            >
          • jennykhan
            Hi David, Sorry, this workaround is temporarily unavailable on the website. You can expect this bug to be fixed in the upcoming release, but in the meantime,
            Message 5 of 11 , Nov 18, 2007
            • 0 Attachment
              Hi David,

              Sorry, this workaround is temporarily unavailable on the website. You
              can expect this bug to be fixed in the upcoming release, but in the
              meantime, paste the following code after the 2.3.1 build of AutoComplete:

              // Implementers should append the following JavaScript patch
              // to the 2.3.1 AutoComplete build file as a workaround for the bug
              being tracked at
              //
              http://sourceforge.net/tracker/index.php?func=detail&aid=1779618&group_id=165715&atid=836476
              YAHOO.widget.AutoComplete.prototype._onTextboxKeyDown =
              function(v,oSelf) {
              var nKeyCode = v.keyCode;
              switch (nKeyCode) {
              case 9:
              if(oSelf._oCurItem) {
              if(oSelf.delimChar && (oSelf._nKeyCode != nKeyCode)) {
              if(oSelf._bContainerOpen) {
              YAHOO.util.Event.stopEvent(v);
              }
              }
              oSelf._selectItem(oSelf._oCurItem);
              }
              else {
              oSelf._toggleContainer(false);
              }
              break;
              case 13:
              var isMac =
              (navigator.userAgent.toLowerCase().indexOf("mac") != -1);
              if(!isMac) {
              if(oSelf._oCurItem) {
              if(oSelf._nKeyCode != nKeyCode) {
              if(oSelf._bContainerOpen) {
              YAHOO.util.Event.stopEvent(v);
              }
              }
              oSelf._selectItem(oSelf._oCurItem);
              }
              else {
              oSelf._toggleContainer(false);
              }
              }
              break;
              case 27:
              oSelf._toggleContainer(false);
              return;
              case 39:
              oSelf._jumpSelection();
              break;
              case 38:
              YAHOO.util.Event.stopEvent(v);
              oSelf._moveSelection(nKeyCode);
              break;
              case 40:
              YAHOO.util.Event.stopEvent(v);
              oSelf._moveSelection(nKeyCode);
              break;
              default:
              break;
              }
              };

              YAHOO.widget.AutoComplete.prototype._onTextboxKeyPress =
              function(v,oSelf) {
              var nKeyCode = v.keyCode;
              var isMac = (navigator.userAgent.toLowerCase().indexOf("mac") != -1);
              if(isMac) {
              switch (nKeyCode) {
              case 9:
              if(oSelf._oCurItem) {
              if(oSelf.delimChar && (oSelf._nKeyCode != nKeyCode)) {
              YAHOO.util.Event.stopEvent(v);
              }
              }
              break;
              case 13:
              if(oSelf._oCurItem) {
              if(oSelf._nKeyCode != nKeyCode) {
              if(oSelf._bContainerOpen) {
              YAHOO.util.Event.stopEvent(v);
              }
              }
              oSelf._selectItem(oSelf._oCurItem);
              }
              else {
              oSelf._toggleContainer(false);
              }
              break;
              case 38:
              case 40:
              YAHOO.util.Event.stopEvent(v);
              break;
              default:
              break;
              }
              }
              else if(nKeyCode == 229) {
              oSelf._queryInterval = setInterval(function() {
              oSelf._onIMEDetected(oSelf);
              },500);
              }
              };



              --- In ydn-javascript@yahoogroups.com, "David Lin" <vegdave@...> wrote:
              >
              > Hi Jenny,
              >
              > I observed the same symptoms on Mozilla 1.7, enter key would trigger a
              > a form submit instead of just setting the value in the text field. I
              > couldn't identify any workarounds you pointed out that is applicable.
              >
              > I use YAHOO.widget.DS_XHR.TYPE_JSON and I can't find any references to
              > myDataSource.ERROR_*. Did I missed something?
              >
              > Thanks,
              >
              > David
              >
              > --- In ydn-javascript@yahoogroups.com, "jennykhan" <jennyhan@> wrote:
              > >
              > > Hi Jason,
              > >
              > > Thanks for the detailed info. Please expect this issue to be fixed in
              > > the next release of AutoComplete. In the meantime, I've posted a
              > > workaround here:
              > > http://developer.yahoo.com/yui/autocomplete/#knownissues
              > >
              > > Regards,
              > > Jenny
              > >
              > >
              > >
              > > --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@>
              > > wrote:
              > > >
              > > > I think I found the cause for this bug, after a few hours' worth of
              > > > debugging the route that the events take through the code when a
              user
              > > > uses the Enter key to select an option in the autocomplete
              suggestion
              > > > box. I think it all comes down to onTextboxKeyPress() firing before
              > > > onTextboxKeyDown(), meaning that a race occurs in which the
              suggestion
              > > > container gets closed before the test is run which decides
              whether to
              > > > use the new Enter key behavior. Here's what I've come up with:
              > > >
              > > > 1. Autocomplete suggestion box pops up, and a user uses the
              arrow
              > > > keys (or not) to choose an item.
              > > > 2. User presses the Enter key to select item.
              > > > 3. The Autocomplete widget's _onTextboxKeyDown() fires, and
              > switches
              > > > to case 13 (the Enter key).
              > > > 4. Just before exiting case 13 of _onTextboxKeyDown(), calls
              > > > oSelf._selectItem(oSelf._oCurItem).
              > > > 5. In _oSelf._selectItem(), handles selecting the item the
              > user was
              > > > on when he pressed Enter, including the final line, which closes the
              > > > suggestion container.
              > > > 6. _onTextboxKeyDown() finishes.
              > > > 7. The Autocomplete widget's _onTextboxKeyPress() fires, and
              > > switches
              > > > to case 13 (the Enter key).
              > > > 8. In _onTextboxKeyPress(), tests whether the suggestion
              > > container is
              > > > still open -- and since it's no longer open (because of it being
              > closed
              > > > in step 5), the key press event doesn't get interrupted, meaning
              that
              > > > the Enter keypress submits the form.
              > > > I've verified this every way I know how... and now, I need to
              > figure out
              > > > how to prevent it from happening, in a way that doesn't
              interfere with
              > > > the normal operation of the Autocomplete widget.
              > > >
              > > > Any suggestions?
              > > >
              > > > Jason
              > > >
              > > >
              > > > --- In ydn-javascript@yahoogroups.com, "Jason Levine" <yahoo.com@>
              > > > wrote:
              > > > >
              > > > > I noticed that there was a change in how AutoComplete was
              > behaving on
              > > > my
              > > > > Mac over the weekend, and then in looking at the YUI 2.3.1
              readme, I
              > > > see
              > > > > that a change was made in how it responds to the enter key on
              > Macs. I
              > > > > think there's a bug in the new implementation.
              > > > >
              > > > > On my Mac, when an AutoComplete container is visible and I
              select an
              > > > > entry in the container with the Enter key, the whole form is
              > submitted
              > > > > -- the change doesn't appear to be restricted to when the
              > container is
              > > > > collapsed, as the readme says it is. Is this intentional? It's
              > > > > certainly breaking expected functionality; I suspect I have a big
              > > > chunk
              > > > > of time ahead of me today figuring out how to work around this new
              > > > > behavior. I put together a short demo of what I'm seeing:
              > > > >
              > > > > http://jzone.queso.org/yui231acbug/index.html
              > > > > <http://jzone.queso.org/yui231acbug/index.html>
              > > > >
              > > > > I haven't tested it in anything but a Mac, but certainly on my
              Macs,
              > > > > choosing an option with the Enter key from the suggestion
              container
              > > > > submits the entire form... again, this breaks what should
              > happen, and
              > > > is
              > > > > a somewhat annoying problem to have to figure a workaround out
              for.
              > > >
              > >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.