Applying existing tags by typing them with different capitalization should not rename/alter capitalization of the existing tag

RESOLVED WONTFIX

Status

()

Firefox
Bookmarks & History
RESOLVED WONTFIX
9 years ago
9 years ago

People

(Reporter: Thomas D., Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9

In "Edit this bookmark" popup dialogue, when you type the name of an existing tag but with different capitalization, the existing tag will be renamed to match the capitalization pattern you last typed. This is unexpected and not useful. Existing tags should not be changed on the fly just because I accidentally enter them with, say, lowercase instead of the original's uppercase. For example, original tag's name is OEM, when you type oem (just once), existing tag becomes oem for all affected bookmarks but shouldn't. Should stay and be applied as OEM until I explicitly change the tag's name in tag manager. I think average user will want changes in capitalization only very rarely, but many people will benefit from not having to worry about capitalization when they type their tag to apply.


Reproducible: Always
based on code this is the expected behavior, i personally think there's simply no point in supporting casing on tags, btw we have to take some final decision on this renaming behavior.
(Reporter)

Comment 2

9 years ago
Steps to reproduce

1. Say this is an existing tag of yours which you have defined before (all upper-case letters):
"OEM"

2. In "Edit this bookmark" popup dialogue of a bookmark without tags, type "oem" (all lower-case) into the tag edit box

Actual Result:
Existing tag ("OEM") is renamed on the fly to "oem" (so it's now all lower-case for all of the respective bookmarks) and applied to the current bookmark.

Expected Result:
Existing tag should NOT be renamed, but just be applied as-is
Type "oem" --> apply existing tag "OEM"
Type "OEM" --> apply existing tag "OEM"
Type "oEm" --> apply existing tag "OEM"
etc.
In other words, original capitalization of the tag should be respected and preserved "for the eye" (better recognition with proper capitalization), but for greater ease of use, typing a tag's name to apply should be case-insensitive (no matter how I type it, I'll get the tag anyway).
Wontfix per discussion with dietrich, we want to allow users to capitalize their tags and change capitalization at will. So this is expected behavior.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

9 years ago
(In reply to comment #3)
> Wontfix per discussion with dietrich, we want to allow users to capitalize
> their tags and change capitalization at will. So this is expected behavior.

I am glad that we agree that
a) users should be able to use capital letters in their tags and
b) they should be able to change capitalization AT WILL (i. e. WHEN they ACTUALLY WANT it).
FIXING this bug will achieve just that for an assumed majority of users.
Therefore, I request REOPENING of this bug:

Typing lowercase is the easiest and fastest way to apply any existing tag. When the fix for bug 490200 lands, tag autocomplete will act case-insensitive, i. e. when you type "tag", autocomplete will show everything, say "tag1", "TAG2", or even "tAG3" [sic]. Say I have "Tag1" as an existing tag, then typing "tag1" will trigger a full autocomplete match (or not?). Are you trying to tell me that whenever/just because I use the fastest and most intuitive way of searching (all lowercase), all my predefined tags having capital letters in them will be forcibly changed into all-lowercase tags? You must be kidding.

Honestly, searching/applying tags and changing a tag's capitalization pattern are two entirely different functions that shouldn't be mixed in any way. You can change capitalization of a tag's name by going into bookmark manager > Tags > YourTag, just as you have to go there when you actually want to RENAME your tag (say from "YourTag" into "YourTag_renamed"). Oh, bookmark manager is too far away? Very true, the command of RENAMING a tag (which includes changing its capitalization pattern as a subset) should be much closer to the actual tag item that I see, e.g. as a context menu entry of each tag in the checkboxed tags list, or even of the typed-text-tag (sort of bubble UI).

I think we can safely assume that there are a lot of users who'll search for tags using all lower-case all the time, but you are not honestly trying to tell me that there are many users out there who will want to change the capitalization of their tags more than once per tag (if at all). Allowing capital letters in tags and force-changing them back to lowercase during apply time just doesn't make sense. In other words, making this wontfix is likely to annoy a lot of users who make use of capital letters in their tag's names (including, but not limited to, folks like the Germans who still use capital initials for all their nouns). Imagine you would be forced to have all your tags capitalized just because of doing an intuitive and easy search... Wontfix really doesn't look like a sustainable choice for this bug. Better implement a proper context menu RENAME instead, and you'll hit two birds with one stone.

Requesting REOPEN.
(Reporter)

Comment 5

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090614 Minefield/3.6a1pre

I would have appreciated a little feedback, but anyway, the good news is, the bug is gone. So...

Thank you for fixing this bug! Sometimes Firefox people improve their product without even noticing... :)
Resolution: WONTFIX → FIXED
this is still wontfix, the current fix is that we preserve user casing, but tags will still be renamed.
Resolution: FIXED → WONTFIX
(Reporter)

Comment 7

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090615 Minefield/3.6a1pre

In comment #6, Marco wrote:
> this is still wontfix,

Marco, let me ask you 4 questions:
1) [The point of having capitalized tags]
In your opinion, why does FF allow capitalized tags?
(I think we can safely assume that the answer on 1) is that FF wants to cater for those people and languages (like German) who prefer proper capitalization of their tags for improved readability / easier recognition of tags)

2) [Frequency of the use case "change capitalization of existing tag"]
If FF let's users define capitalized tags (like "Peter", "OEM", "UN", "Software"), how often in a tag's lifetime do you think these users will deliberately want to change the original capitalization of their existing tags (say to "peter", "oem", "un", "software")?

3) [Frequency of the use case "apply existing tag as-is to other bookmarks"]
If the whole point of tags is to easy retrieval and categorization (grouping together) of information, then how often in a tag's lifetime do you think an existing (predefined) tag might (possibly) be applied to other bookmarks?

4) [The difference between initial definition and fast'n'easy application of existing tags]
Why do you personally prefer all-lowercase tags (and so do I, when it comes to *applying* tags)? (That's how I understand Marco's comment #1: "I personally think there's simply no point in supporting casing on tags")
Hint: Ever wondered why, while we can define a capitalization pattern to our own taste, FF doesn't allow to define "tag1" and "Tag1" as two *different* tags?

I'll be very interested to hear your answers hoping that they'll help me to understand the reasons for marking this bug "wontfix" as per the two-line comment #1. In case you're interested, please find my answers to these questions in comment #2, unfortunately I haven't received any feedback on that one so far. 

> the current fix is that we preserve user casing,
> but tags will still be renamed. [where renaming here means changing capitalization, proper rename is currently only available from bookmark library; T.D.]

In today's nightly, I can't reproduce the behaviour claimed/preferred by Marco ("change capitalization on the fly as you apply"). I think I was able to reproduce it once, but now no more. So although this bug is currently wontfix, the behaviour as requested by this bug is exactly what FF currently does: 

- Situation: have some bookmark with an existing tag "ytag" (and no other tags starting with y)
- Steps: in the yellow-star "Edit this bookmark" popup dialogue of that same bookmark or any other bookmark, type "Ytag"[now capitalized] into the Tags-textbox (which should change capitalization on the fly, according to Marco)
- Result --> In the very moment when I press enter, the entered string "Ytag" is correctly changed to "ytag" and then applied, because "ytag" is the existing tag and FF respects my original definition of the tag in terms of capitalization, as requested by this bug.

That's why I still think this bug 490252 is de facto fixed (and should therefore be resolved fixed).
(In reply to comment #7)
> 1) [The point of having capitalized tags]
> In your opinion, why does FF allow capitalized tags?

for readability.

> 2) [Frequency of the use case "change capitalization of existing tag"]
> If FF let's users define capitalized tags (like "Peter", "OEM", "UN",
> "Software"), how often in a tag's lifetime do you think these users will
> deliberately want to change the original capitalization of their existing tags
> (say to "peter", "oem", "un", "software")?

most likely once if they notice they wrote them wrongly

> 3) [Frequency of the use case "apply existing tag as-is to other bookmarks"]
> If the whole point of tags is to easy retrieval and categorization (grouping
> together) of information, then how often in a tag's lifetime do you think an
> existing (predefined) tag might (possibly) be applied to other bookmarks?

a lot

> 4) [The difference between initial definition and fast'n'easy application of
> existing tags]
> Why do you personally prefer all-lowercase tags (and so do I, when it comes to
> *applying* tags)? (That's how I understand Marco's comment #1: "I personally
> think there's simply no point in supporting casing on tags")

imo tags are an informations wrapper, and casing does not bring any additional information to me. This is personal opinion only.

> Hint: Ever wondered why, while we can define a capitalization pattern to our
> own taste, FF doesn't allow to define "tag1" and "Tag1" as two *different*
> tags?

because the information they bring is the same.

> I'll be very interested to hear your answers hoping that they'll help me to
> understand the reasons for marking this bug "wontfix" as per the two-line
> comment #1

my opinion/answer won't contain the reason for the wontfix, that reason is simply that the team has taken such a decision, could change in future, but for now that's what was decided.
Tag casing is there for readability and users must be able to change casing easily without having to look around for a way to do that.

> In today's nightly, I can't reproduce the behaviour claimed/preferred by Marco
> ("change capitalization on the fly as you apply"). I think I was able to
> reproduce it once, but now no more. So although this bug is currently wontfix,
> the behaviour as requested by this bug is exactly what FF currently does: 

the behavior now is better, but this bug is more about completely stop changing tag casing, unless we do that in the Library. And this part for now is a wontfix, even if we thought about the approach, and could make sense.
You need to log in before you can comment on or make changes to this bug.