bookmark keywords are case sensitive

RESOLVED FIXED

Status

Camino Graveyard
Bookmarks
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: timeless, Assigned: froodian (Ian Leue))

Tracking

({fixed1.8.1.1})

Trunk
x86
SunOS
fixed1.8.1.1

Details

Attachments

(1 attachment)

1.64 KB, patch
Sean Murphy
: review+
Mike Pinkerton (not reading bugmail)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

11 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

11 years ago
Created attachment 248249 [details] [diff] [review]
Patch

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

Updated

11 years ago
Attachment #248249 - Flags: review? → review?(camino)

Comment 2

11 years ago
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

11 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

11 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

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

Comment 6

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

Comment 7

11 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

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

Comment 10

11 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.