Tags autocomplete does not show all results because it is case-sensitive (lower-case, upper-case, missing results, skips, wrongly, capitalization)

VERIFIED FIXED in Firefox 3.6a1

Status

()

defect
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: bugzilla2007, Assigned: mak)

Tracking

({fixed1.9.1})

Trunk
Firefox 3.6a1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre

In the current Minefield nightly, the new tag autocomplete feature doesn't work as expected because it acts case-sensitive, which seems wrong under the circumstances. Sample scenario:



Reproducible: Always

Steps to Reproduce:
1. User has tags with the following names:
tag1
tag2
Tag3
Tag4

2. In the "Edit this bookmark" dialogue of a bookmark without tags, user wants to apply "tag1", but he doesn't remember the correct capitalization when he starts typing (mind capitalization):
"Tag"

3.
Actual Results:  
For search term "Tag", Firefox will offer the following autocomplete entries:
Tag3
Tag4
For search term "Tag1", Firefox will offer no autocomplete entries, thus falsely suggesting that there is no existing tag by the name "Tag1": What actually happens is that as soon as user confirms "Tag1" (mind capitalization), the existing tag "tag1" will be renamed into "Tag1" and then applied to the bookmark. In other words, user successfully applied an existing tag even though autocomplete claimed there was none.
Even if "renaming on the fly" should get removed (as I feel it should), the problem remains: Since Firefox is case-insensitive when it comes to tags (you can't have two tags with same name but different capitalization, and rightly so!), entering "Tag1" would then simply apply the existing "tag1", only without changing the capitalization of "tag1". The problem remains that autocomplete for "Tag1" currently wouldn't show the existing "tag1".


Expected Results:  
When user types "Tag1" [sic], tag autocomplete should show the existing "tag1" [sic] (which will eventually get applied) in the list of autocomplete entries.
In other words, Tag autocomplete should be case-insensitive to show all relevant results, because for good reasons, Firefox handles tags (mostly) case-insensitive as explained above.

In the above example, typing either "Tag" or "tag" should always show all of the four tags as autocomplete entries (tag1, tag2, Tag3, Tag4).
Version: unspecified → Trunk
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre

Confirmed, requesting blocking due to the fact that tags are really case-insensitive, yet at *all* the entry points they are considered case-sensitive!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3.5?
Flags: in-testsuite?
(In reply to comment #1)
> Confirmed, requesting blocking due to the fact that tags are really
> case-insensitive, yet at *all* the entry points they are considered
> case-sensitive!
Er, didn't Firefox 3.0 behave the same way?  We really should only be requesting blocking if the behavior has changed from 3.0...
Yes it did, only now it's a lot more visible with the autocomplete. My intention was not to morph this bug, only to note the fact that when patched, that should be kept in mind. Another problem with this is that when changes, upper-case beats lower-case. Eg:

If I have a tag "business" and I tag another website with "Business" the tag will now be named "Business". That's pretty bad, IMHO, and should be considered dataloss of some sort.
i agree with Shawn, this is no regression, and i think no blocker.
personally i always thought supporting case sensitivity for tags is quite useless and we should always convert them to lowercase, but someone could find that useful.
(In reply to comment #3)
> Yes it did, only now it's a lot more visible with the autocomplete.
> Another problem with this is that when changes,
> upper-case beats lower-case. Eg:

Not exactly. It works both ways: Lower-case might also beat upper-case. Just whatever you type last will cause the original tag to change in terms of capitalization.

> If I have a tag "business" and I tag another website with "Business" the tag
> will now be named "Business". That's pretty bad, IMHO, and should be 
> considered dataloss of some sort.

This has been filed as Bug 490252: Applying existing tags by typing them with different capitalization should not rename/alter capitalization of the existing tag. Pretty bad, indeed, especially in combination with wrong sort order as reported in  Bug 490130: Tags list of "Edit this Bookmark" popup dialogue is not sorted correctly (wrong sorting: upper-case a to z, lower-case a to z, umlaute). Which means the renamed tag even changes position in the alphabetical list (only in the popup).

@Marco's comment #4:
Tags with proper capitalization are way easier to recognize than all-lower-case tags. Even more so for languages like German that still have all nouns capitalized (believe it or not). So I disagree that having capitalization for tags is useless. But that's not the point here.
The point here is that if you don't change anything with respect to the current behaviour as reported in this bug 490200, bug 490252, and Bug 490130, you'll make a fool of yourself when you ship autocomplete in its current state:
Please go through the steps of comment #0 again to see that autocomplete just won't find half of your existing tags in everyday usage scenarios!
original comment 0 report should be fixed, because we have to show all tags, regardless of casing.
comment 3 is wontfix, since that's expected behavior.
Posted patch patch v1.0 (obsolete) — Splinter Review
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attachment #374863 - Flags: review?(dietrich)
OS: Windows XP → All
Hardware: x86 → All
Attachment #374863 - Flags: review?(dietrich) → review+
Posted patch patch v1.1Splinter Review
only fixed test functions numbers
Attachment #374863 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/87799243c9e6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Comment on attachment 375025 [details] [diff] [review]
patch v1.1

Asking approval for this highly visible issue with tag autocomplete results.
Attachment #375025 - Flags: approval1.9.1?
not a regression, and doesn't make the feature unusable, just not as useful.

that said, i heartily recommend approving this patch.
Flags: blocking-firefox3.5? → blocking-firefox3.5-
Comment on attachment 375025 [details] [diff] [review]
patch v1.1

a191=beltzner
Attachment #375025 - Flags: approval1.9.1? → approval1.9.1+
This fix makes it impossible to add new tags beginning with upper case letters if there is any tag that already begins with that letter.

For example:  Have a tag of name "test" Then attempt to add a tag "Tuba". You can't because auto-compete is turning the uppercase T to lower case.  

seen with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre

This side affect of this fix may be a worse regression than the bug it fixed.
verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US;
rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre
Status: RESOLVED → VERIFIED
Depends on: 491520
Depends on: 491523
The side effect mentioned in comment #15 is bad indeed, even though some minor details of the behaviour have not been adequately described (E.g., there is a workaround to add new tags with different capitalization when you cursor back in what you typed and change the initial, but that's not very obvious at all and thus no real solution to the prob).

First thoughts on how to fix both bugs:
1.) While user is typing, don't change capitalization of what has been typed, even if there are autocomplete matches that have different capitalization
Say you have "test", and want to add "Tuba":
- user types "T" --> autocomplete leaves T untouched and fills up to "T[est]"
2.) When user confirms autocomplete suggestion, obviously we'll have to apply "test" (NOT "Test"). In other words, fix bug 490252: Applying existing tags by typing them with different capitalization should not rename/alter capitalization of the existing tag (for the rare cases where capitalization of existing tag needs to be changed - once in a tag's lifetime -, user can do so in Bookmark manager > Rename tag. In the long run, we'll need a context menu for "rename tag" that is closer to where tags are applied and defined).

BTW, this is how Thunderbird's (Version 2) address autocomplete works. And with respect to our problem, this seems to work well. I'm in a rush, just first thoughts.

Underlying assumptions are that
a) existing tag's capitalization should be respected unless user explicitly changes it (user has a reason for having defined "test" (and not "Test"), and he doesn't want capitalization to change at random)
b) searching and applying tags should be as easy possible, i. e. case-insensitive (user should be able to type "tuba" to find "Tuba" AND "tuba2" and then apply whichever he pleases)
Blocks: 490130
You need to log in before you can comment on or make changes to this bug.