Open Bug 1009439 Opened 10 years ago Updated 10 years ago

a) Comment tags inline autocomplete prevents free/new tag input ("foo"; "foo2" unless typed very fast), if unique match "barfoobaz" exists as predefined tag. b) apparently fails to show all results (or strange interaction with browser autocomplete)

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

4.5.4
defect
Not set
normal

Tracking

()

People

(Reporter: thomas8, Unassigned)

References

Details

Thanks for the nice comment tags feature on bugzilla, looks like a great thing with potential for more. Here's an irritating behaviour when entering new/free tags which happen to be contained STR 1 click on [tag] link above comment to show tag bar 2 type "sol" slowly and/or pause shortly after the "l" (with an intention of typing "solution" as a new/free tag, or even just "sol" if that existed) 3 delete all tag text input and retype "solu" Actual result After 2: * due to inline autocomplete (probably for unique matches), your text input suddenly changes and becomes "obsolete", with "olete" highlighted. * can't finish typing new/free tag "solution" (would end up typing "obsution") * no way of setting "sol" as a new/free tag (if that was required); i.e. cannot define a new, short tag "foo" if it happens to be contained in a longer predefined tag ("barfoobaz") * can't even intuitively finish typing "solete" IF that's what I'm after (user has already typed "sol", so would end up typing "obsete") -> Effectively, direct inline completion, if based on "contains" matches, is useless for all 3 scenarios (new/free tag "solution", new/free tag "sol" vs. existing tag "obsolete") After 3: Probably unrelated, but I'll file this here anyway: For my scenario (already having entered "solution" successfully into the tag input before), when I type "solu" into tag box, I get only "solution" as a an autocomplete suggestion (both in the dropdown and inline). However, why didn't I see "solution" suggested before, when I just typed "sol"? Iow, when I type "sol", shouldn't I see both "obsolete" and "solution" as an offer in the dropdown, instead of only "obsolete"? This might result from interaction between application autocomplete and browser autocomplete, but the net effect is confusing anyway and it feels wrong. Expected: After 2: - should not mess up user's new/free tag typing; both "sol" and "solution" are legitimate new/free tags - should not prevent typing new/free tags which happen to be contained in predefined tags (new "sol" vs. existing "obsolete") - do not inline-autocomplete for "contains" matches, even when they are unique - if at all, you'd have to use "sol >> obsolete" style (as in TB recipient autocomplete), so that user can continue typing at his own speed without interference - otherwise, just let user pick from autocomplete dropdown in cases where inline autocomplete is disruptive After 3: Browser autocomplete or not, when user types "sol", both "obsolete" and "solution" should be offered consistently (no reason why "solution" should only show up for "solu", but not for "sol").
Summary: Comment tags inline autocomplete (for unique matches) messes up free/new tag input unless typed very fast; apparently fails to show all results (or strange interaction with browser autocomplete) → a) Comment tags inline autocomplete (for unique matches) messes up free/new tag input unless typed very fast. b) apparently fails to show all results (or strange interaction with browser autocomplete)
(In reply to Thomas D. from comment #0) > Thanks for the nice comment tags feature on bugzilla, looks like a great > thing with potential for more. > > Here's an irritating behaviour when entering new/free tags (like "sol" or "let" if that was required) > which happen to be contained... ...as a substring of an existing tag (like "obsolete").
Blocks: 793963
Summary: a) Comment tags inline autocomplete (for unique matches) messes up free/new tag input unless typed very fast. b) apparently fails to show all results (or strange interaction with browser autocomplete) → a) Comment tags inline autocomplete prevents free/new tag input ("foo"; "foo2" unless typed very fast), if unique match "barfoobaz" exists as predefined tag. b) apparently fails to show all results (or strange interaction with browser autocomplete)
No longer blocks: 793963
Depends on: 793963
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → 4.5.4
You need to log in before you can comment on or make changes to this bug.