bookmark keywords are case sensitive

RESOLVED FIXED

Status

RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: timeless, Assigned: froodian)

Tracking

({fixed1.8.1.1})

Trunk
x86
SunOS
fixed1.8.1.1

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
product parity, firefox, seamonkey, mozilla, none of them are. just camino.

steps: have a 'bug' keyword that loads bugzilla bugs.

try using Bug 10000, it doesn't work in camino, but works everywhere else.
(Assignee)

Comment 1

13 years ago
Posted patch PatchSplinter Review
The nil check is because caseInsensitiveCompare doesn't like nil arguments.
Assignee: nobody → stridey
Status: NEW → ASSIGNED
Attachment #248249 - Flags: review?
(Assignee)

Updated

13 years ago
Attachment #248249 - Flags: review? → review?(camino)
Erm, this is arguably a useful feature.

Not that I use it, but I can see how it would be useful.

cl
(Assignee)

Comment 3

13 years ago
If it's a question of feature-parity, I'm not sure we can afford to sacrifice "works the same way" for "arguably useful."
Given that nothing else in an HFS world is case-sensitive, this seems odd ;)  It will also cause problems for people importing bookmarks when migrating from Firefox....

Comment 5

13 years ago
Comment on attachment 248249 [details] [diff] [review]
Patch

r=me for the patch itself, since it looks great and works without any trouble.

I'll leave it up to the sr and other opinions as to whether we should actually institute a change in how keywords are resolved.  I am only worried if some (probably very few if any) users were taking advantage of the current behavior and storing multiple keywords differing only by case.  Anyone is this situation will now experience bug 357214, which describes what happens when two or more bookmarks have same keyword.

My opinion: Case-insensitive keywords will most likely help far more users than the ones we'd anger (the ones who are currently using identical-except-for-case keywords).  Since we strive for excellent usability and a simple design, case insensitivity seems like to way to go here.

As a side note, adding a keyword manager (see bug 201723 comment 20 - which would be easy after bug 352250 is in place) could be a nice accompaniment to this and help those crazy people taking advantage of case-sensitive keywords, who now need to change several at once.
Attachment #248249 - Flags: review?(camino) → review+
(Assignee)

Updated

13 years ago
Attachment #248249 - Flags: superreview?(mikepinkerton)

Comment 6

13 years ago
Case sensitivity as a feature here seems very fringe; I think we want this change.
(Assignee)

Comment 7

12 years ago
Comment on attachment 248249 [details] [diff] [review]
Patch

a=pink, targeting sr to smorgan.
Attachment #248249 - Flags: superreview?(mikepinkerton) → superreview?(stuart.morgan)
Comment on attachment 248249 [details] [diff] [review]
Patch

sr=pink
Attachment #248249 - Flags: superreview?(stuart.morgan) → superreview+
(Assignee)

Comment 9

12 years ago
Checked in on 1.8branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1.1
Resolution: --- → FIXED
(Reporter)

Comment 10

12 years ago
I'll verify this later. in case it isn't obvious, I'm usually a power user- your edge case is edgier than I am.
You need to log in before you can comment on or make changes to this bug.