Case insensitive history search

RESOLVED FIXED in mozilla1.6final

Status

--
critical
RESOLVED FIXED
17 years ago
3 months ago

People

(Reporter: bernard.alleysson, Assigned: Stefan.Borggraefe)

Tracking

({fixed1.4.2, fixed1.6, useless-UI})

Trunk
mozilla1.6final
fixed1.4.2, fixed1.6, useless-UI
Bug Flags:
blocking1.4 -
blocking1.6 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
1) Ctrl+H (History)
2) Ctrl+F (Search history...)

I lost a few minutes search for a URL I've visited today
just because history search does *case sensitive search*

It would be nice if the search history dialog had an option
"Match upper/lower case" like the "Find in this page..." dialog
(Reporter)

Comment 1

17 years ago
I've tested bookmark search and it appears that bookmark search
does a case insensitive search
Maybe Search history... should do the same ?
There would be no need for a case insensitive check box ?
(Reporter)

Comment 2

17 years ago
ok
no comment so far
moving to browser-general to find the right component
Component: History: Global → Browser-General

Comment 3

17 years ago
*** Bug 158147 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 4

17 years ago
one duplicate now
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Component: Browser-General → History: Global
(Reporter)

Comment 5

16 years ago
maybe the fix for this bug is to port patch for bug 172272 to Mozilla

Comment 6

16 years ago
A bug, not an enhancement. Is this really working on Linux and the Mac? 

Regardless of whether history search should be case sensitive or not for URLs,
it should definitely be insensitive as for titles. 

Maybe this: case insensitive for titles, protocols, and the address parts of
URLs; case sensitive for the other parts of the URL.

Buffy should have this.
Severity: enhancement → normal
Keywords: nsbeta1

Comment 7

16 years ago
This should have a release note. Prosed released note:

Mozilla does not allow case sensitive searches of History. (bug 131470)
Keywords: relnote

Comment 8

16 years ago
Argh. Scratch that. Proposed release note:

Mozilla does not allow case insensitive searches of History. (bug 131470)

Comment 9

16 years ago
Nav triage team: nsbeta1-
Severity: normal → enhancement
Keywords: nsbeta1 → helpwanted, nsbeta1-

Updated

16 years ago
Severity: enhancement → normal

Comment 10

16 years ago
--> History: Global. Reassign.
QA Contact: claudius → kasumi

Comment 11

16 years ago

*** This bug has been marked as a duplicate of 99091 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 12

16 years ago
This bug doesn't read at all like 99091 to me.  What's going on here?

Try to search for a site you recently visited, like maybe Apple Computer.  If
you search for "apple", it's simply not going to come up.  The problem is the
search IS case sensitive.  That other bug is complaining of case insensitivity
and doesn't refer to the Title of the web page.  Am I right or not?

This bug has been severely hampering history, in my opinion.  It appears very
simple.

Comment 13

16 years ago
Sorry, despite the fact that it looks like 2 bugs in one on that report since
maybe it's the same cause, I guess my prior comment is wrong.  The comments
mention the problem that *this* bug details, so it is apparently being worked on
over there.

Updated

16 years ago
QA Contact: kasumi → petersen

Comment 14

16 years ago
I agree with comment #12 (ignoring #13 ;-)) - this can't be a duplicate of
99091. We can imagine an enhanced search in the future where the user can
specify the search to be case-sensitive or not - this has nothing to do with the
History:Session problem described in 99091.

The default behaviour in search should be case-insensitive, which currently
fails and is described this bug report. I think this must be re-opened and
treated as a separate bug. 


Comment 15

16 years ago
Okay, reopening. 

A case sensitive history search renders history search useless. This can't be
difficult to fix.

Could someone please check this on a Mac or on Linux? I'd be shocked if this
were limited to Windows.
Status: RESOLVED → REOPENED
Flags: blocking1.4?
Keywords: useless-UI
Resolution: DUPLICATE → ---

Comment 16

16 years ago
It's my opinion that this bug will keep slipping through the cracks because many
people never care about where they've been, but the sizable minority that does
is very seriously in need of a well functioning history.  Case insensitivity is
the only logical choice for History Search.  I think something needs to be done,
so I'm suggesting that we make this bug a 1.4 blocker.

Updated

16 years ago
Flags: blocking1.4? → blocking1.4-

Comment 17

16 years ago
I heartily endorse fixing this bug ASAP. I always wondered why the Mozilla
history find function seemed broken, but only figured out that it was
case-sensitivity recently. In the real world, this is broken behavior. For
example, which letter in "ebay" would you have to capitalize in a title-search
to get results for www.ebay.com (hint: it's not "e")?

 Assuming that Mozilla should to be useful to normal users rather than just unix
weenies (of which I'm one), searches should be case-insensitive. This is how all
major search engines work as well as DNS. It would be nice to have it "just
work" rather than "work if you know exactly what you're searching for" (in which
case you probably wouldn't be searching your history in the first place).

Updated

16 years ago
Keywords: relnote

Comment 18

15 years ago
This bug needs to be addressed.  History is in poor shape in general but if
nothing else, Blake Ross should be commenting on how things are proceeding in
fixing the case sensitivity issue.

Blake Ross, how are things proceeding in fixing the case sensitivity issue?

Comment 19

15 years ago
This bug should block 1.5 in my opinion.

Updated

15 years ago
Flags: blocking1.6a+

Updated

15 years ago
Flags: blocking1.6a+

Comment 20

15 years ago
Bob, I totally agree with your point that in some proper nouns, like people or
place names or brand or company names, you would have to go through several
permutations of the spelling and many people don't spell very well anyway.  This
makes History Search terribly frustrating to users and extremely ineffective.

Comment 21

15 years ago
Mozilla crash and burn.  No one addresses old bugs anymore.

Comment 22

15 years ago
Critical. This is a defect that you never realize is there, because there is
nothing that seems wrong. Your searches just fail quietly. That reason alone is
sufficient to justify fixing it. 
Severity: normal → critical
Flags: blocking1.6?
Flags: blocking1.4.2?
OS: Windows 2000 → All
Hardware: PC → All

Comment 23

15 years ago
Until this bug can be fixed, history search function should be removed from
trunk. Thus, have filed bug 226750.

Comment 24

15 years ago
Both Firebird and Mozilla should be blocked from further releases until the
Firebird developer who worked on History or someone else fixes this issue in
Mozilla.  This bug leaves Mozilla too impaired and the Firebird programmer who
worked on this knows that.  At some level it is imperative that there should be
an expectation of parity between the two products' development.  Certainly this
is that level.  Firebird coders shouldn't be fixing issues that make Mozilla
unusable by a large group of users and then proceeding on to new issues, without
concern.

Updated

15 years ago
Flags: blocking1.6? → blocking1.6-
(Assignee)

Comment 26

15 years ago
Created attachment 137427 [details] [diff] [review]
Port of the fix for Firebird to Seamonkey
(Assignee)

Updated

15 years ago
Attachment #137427 - Flags: review?(neil.parkwaycc.co.uk)

Comment 27

15 years ago
Comment on attachment 137427 [details] [diff] [review]
Port of the fix for Firebird to Seamonkey

Aren't you missing a comparator in the isnot method?
(Assignee)

Comment 28

15 years ago
Created attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

> Aren't you missing a comparator in the isnot method?

I corrected this. Blake missed it too when he fixed this in Firebird. But I
think it isn't worth a bug report since in FB only "contains" seems to be used
anyway. Furthermore no sane person will use "is" or "isnot" in history search,
because you wouldn't search for a page when you already exactly know its title
or location. ;-)
(Assignee)

Updated

15 years ago
Attachment #137427 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #137427 - Flags: review?(neil.parkwaycc.co.uk)
(Assignee)

Updated

15 years ago
Attachment #137643 - Flags: review?(neil.parkwaycc.co.uk)

Comment 29

15 years ago
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

Ah, but "is" is now useful, just in "case" you forget :-)
Attachment #137643 - Flags: review?(neil.parkwaycc.co.uk) → review+
(Assignee)

Updated

15 years ago
Attachment #137643 - Flags: superreview?(bryner)
(Assignee)

Comment 30

15 years ago
Taking bug. This would be nice to have for 1.6 final.
Assignee: blake → borggraefe
Status: REOPENED → NEW
Keywords: helpwanted
Target Milestone: --- → mozilla1.6final
(Assignee)

Updated

15 years ago
Attachment #137643 - Flags: superreview?(bryner) → superreview?(alecf)

Comment 31

15 years ago
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

hmm. This is ok for latin-1 strings, but we really need a
nsCaseInsensitiveUTF8StringComparator
Attachment #137643 - Flags: superreview?(alecf) → superreview+
(Assignee)

Comment 32

15 years ago
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

Low risk fix (similar change was applied to Firebird over a year ago) for a bug
that is severe because of its *low* visibility.
Attachment #137643 - Flags: approval1.6?
Attachment #137643 - Flags: approval1.4.2?
(Assignee)

Comment 33

15 years ago
This was just checked in, so this is fixed in the trunk (this is what will
become Mozilla 1.7 alpha). Still waiting for approval for 1.6 and 1.4.2.
Status: NEW → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 34

15 years ago
Reopening, because the Mozilla 1.6 Release-Stauts page only lists bugs on the
"Bugs Awaiting Drivers' Approval"-page that are not yet resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 35

15 years ago
Tested in trunk (1.7 build, 2003122908).

It works! Thank you. You are awesome.
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

I like this for 1.4.2 - nice improvement

a=mkaply for 1.4.2 ONLY
Attachment #137643 - Flags: approval1.4.2? → approval1.4.2+
Checked in to the 1.4 branch.
(Assignee)

Updated

15 years ago
Keywords: fixed1.4.2
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

1.6 is still open. check it in. r=mkaply
Attachment #137643 - Flags: approval1.6? → approval1.6+

Comment 39

15 years ago
Comment on attachment 137643 [details] [diff] [review]
Makes "isnot" case-insensitive, too.

a=chofmann for 1.6
checked in to 1.6 branch
Checking in nsGlobalHistory.cpp;
/cvsroot/mozilla/xpfe/components/history/src/nsGlobalHistory.cpp,v  <-- 
nsGlobalHistory.cpp
new revision: 1.189.10.1; previous revision: 1.189
done

removing blocking1.4.2 as this is now checked in there
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Flags: blocking1.4.2?
Resolution: --- → FIXED
(Assignee)

Updated

15 years ago
Keywords: fixed1.6

Updated

3 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.