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

Re: Bug in new 2.3.1 AutoComplete enter key behavior on Mac

Expand Messages
  • 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 1 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 2 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 3 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 4 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.