Bug #327
Feature #14: tags for projects
Edits ignored in tag edit field while autocomplete menu visible
Status: | New | Start date: | 2011-11-11 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | Luis Figueira | % Done: | 0% | |
Category: | - | |||
Target version: | - |
Description
- Type something into the tag edit field and wait for autocomplete menu to appear (doesn't matter whether autocomplete gets any results or not)
- When the menu is visible, type some more and hit Return before the next autocomplete lookup begins
- Observe that any text you typed in the previous step is missing from the submitted tag
For example, in the attached image, the text field currently says "weev". If I added "il" and hit Return before the next autocomplete had happened, the submitted tag would still only say "weev".
This makes it quite difficult to type a long tag and add it successfully unless you deliberately stop for a moment before hitting Return. (I was about to submit a report saying that multi-word tags weren't working, until I realised it was just that only the first part of the tag had appeared because of this problem.)
History
#1 Updated by Chris Cannam about 13 years ago
- Description updated (diff)
I think the problem is that when the autocomplete menu appears, its first element is already highlighted (even though I haven't hit the down-arrow at all).
So:
- if I type into the tag field and the autocomplete finds at least one match, it will pop up a menu with the first match highlighted. If I then type some more text and quickly hit return, the highlighted match is selected instead of the text I was typing.
- if I type into the tag field and the autocomplete finds no matches, it will pop up a menu with Add new... as its only element (highlighted). If I then type more text and quickly hit return, only the text that was present when autocomplete began is used for the new tag -- what seems to happen is that the "Add New" function is invoked, but with the tag text as it was when the autocomplete search began.
The behaviour I initially reported was the second of these -- because I had so few tags in my test site, autocomplete usually failed to find any match.
So there are two bugs here:
- The autocomplete menu has its first entry selected by default, so when you hit Return on the text field, the menu entry is used instead of the text field's contents;
- The Add New... entry on the menu adds the text that existed in the field when the autocomplete search began, not the text that exists when the menu function is invoked.
We could mitigate the second one by including the tag text in the Add New... label, e.g. make it say New tag: "weev" in the above example. Then at least you'd know what you were getting.