Bug in new 2.3.1 AutoComplete enter key behavior on Mac

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:

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.

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:

The Autocomplete widget's _onTextboxKeyDown() fires, and switches to case 13 (the Enter key).

Just before exiting case 13 of _onTextboxKeyDown(), calls oSelf._selectItem(oSelf._oCurItem).

In _oSelf._selectItem(), handles selecting the item the user was on when he pressed Enter, including the final line, which closes the suggestion container.

_onTextboxKeyDown() finishes.

The Autocomplete widget's _onTextboxKeyPress() fires, and switches to case 13 (the Enter key).

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

>
> 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

> 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: