131470 - Case insensitive history search

Status: RESOLVED FIXED

(Core Graveyard :: History: Global, defect)

Description

[Bernard Alleysson]

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

Comment 1

[Bernard Alleysson]

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 ?

Comment 2

[Bernard Alleysson]

ok
no comment so far
moving to browser-general to find the right component

Comment 3

[Wesha]

*** Bug 158147 has been marked as a duplicate of this bug. ***

Comment 4

[Bernard Alleysson]

one duplicate now
confirming

Comment 5

[Bernard Alleysson]

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

Comment 6

[Andrew Hagen]

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.

Comment 7

[Andrew Hagen]

This should have a release note. Prosed released note:

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

Comment 8

[Andrew Hagen]

Argh. Scratch that. Proposed release note:

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

Comment 9

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 10

[Andrew Hagen]

--> History: Global. Reassign.

Comment 11

[Andrew Hagen]

*** This bug has been marked as a duplicate of 99091 ***

Comment 12

[Jay Davis]

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

[Jay Davis]

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.

Comment 14

[marten.strom]

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

[Andrew Hagen]

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.

Comment 16

[Jay Davis]

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.

Comment 17

[seren]

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

Comment 18

[Jay Davis]

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

[Jay Davis]

This bug should block 1.5 in my opinion.

Comment 20

[Jay Davis]

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

[Jay Davis]

Mozilla crash and burn.  No one addresses old bugs anymore.

Comment 22

[Andrew Hagen]

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. 

Comment 23

[Andrew Hagen]

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

Comment 24

[Jay Davis]

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.

Comment 25

[Stefan Borggraefe]

This was fixed for Firebird via this checkin.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F10%2F2002+17%3A50%3A00&maxdate=11%2F10%2F2002+17%3A52%3A00&cvsroot=%2Fcvsroot

I think only the changes to nsGlobalHistory.cpp are relevant for this bug.

Comment 26

[Stefan Borggraefe]

Attachment: Port of the fix for Firebird to Seamonkey

Comment 27

[[e-mail]]

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?

Comment 28

[Stefan Borggraefe]

Attachment: 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. ;-)

Comment 29

[[e-mail]]

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

Ah, but "is" is now useful, just in "case" you forget :-)

Comment 30

[Stefan Borggraefe]

Taking bug. This would be nice to have for 1.6 final.

Comment 31

[Alec Flett]

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

Comment 32

[Stefan Borggraefe]

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.

Comment 33

[Stefan Borggraefe]

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.

Comment 34

[Stefan Borggraefe]

Reopening, because the Mozilla 1.6 Release-Stauts page only lists bugs on the
"Bugs Awaiting Drivers' Approval"-page that are not yet resolved.

Comment 35

[Andrew Hagen]

Tested in trunk (1.7 build, 2003122908).

It works! Thank you. You are awesome.

Comment 36

[Mike Kaply [:mkaply]]

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

Comment 37

[Boris Zbarsky [:bzbarsky]]

Checked in to the 1.4 branch.

Comment 38

[Mike Kaply [:mkaply]]

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

1.6 is still open. check it in. r=mkaply

Comment 39

[chris hofmann]

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

a=chofmann for 1.6

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

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