Closed Bug 131470 Opened 23 years ago Closed 21 years ago

Case insensitive history search


(Core Graveyard :: History: Global, defect)

Not set


(Not tracked)



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



(Keywords: fixed1.4.2, fixed1.6, useless-UI)


(1 file, 1 obsolete file)

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
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 ?
no comment so far
moving to browser-general to find the right component
Component: History: Global → Browser-General
*** Bug 158147 has been marked as a duplicate of this bug. ***
one duplicate now
Ever confirmed: true
Component: Browser-General → History: Global
maybe the fix for this bug is to port patch for bug 172272 to Mozilla
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
This should have a release note. Prosed released note:

Mozilla does not allow case sensitive searches of History. (bug 131470)
Keywords: relnote
Argh. Scratch that. Proposed release note:

Mozilla does not allow case insensitive searches of History. (bug 131470)
Nav triage team: nsbeta1-
Severity: normal → enhancement
Keywords: nsbeta1helpwanted, nsbeta1-
Severity: enhancement → normal
--> History: Global. Reassign.
QA Contact: claudius → kasumi

*** This bug has been marked as a duplicate of 99091 ***
Closed: 22 years ago
Resolution: --- → DUPLICATE
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
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.
QA Contact: kasumi → petersen
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. 

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.
Flags: blocking1.4?
Keywords: useless-UI
Resolution: DUPLICATE → ---
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.
Flags: blocking1.4? → blocking1.4-
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 (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).
Keywords: relnote
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?
This bug should block 1.5 in my opinion.
Flags: blocking1.6a+
Flags: blocking1.6a+
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.
Mozilla crash and burn.  No one addresses old bugs anymore.
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
Until this bug can be fixed, history search function should be removed from
trunk. Thus, have filed bug 226750.
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
Flags: blocking1.6? → blocking1.6-
Attachment #137427 - Flags: review?(
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?
> 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. ;-)
Attachment #137427 - Attachment is obsolete: true
Attachment #137427 - Flags: review?(
Attachment #137643 - Flags: review?(
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?( → review+
Attachment #137643 - Flags: superreview?(bryner)
Taking bug. This would be nice to have for 1.6 final.
Assignee: blake → borggraefe
Keywords: helpwanted
Target Milestone: --- → mozilla1.6final
Attachment #137643 - Flags: superreview?(bryner) → superreview?(alecf)
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
Attachment #137643 - Flags: superreview?(alecf) → superreview+
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?
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.
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Reopening, because the Mozilla 1.6 Release-Stauts page only lists bugs on the
"Bugs Awaiting Drivers' Approval"-page that are not yet resolved.
Resolution: FIXED → ---
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.
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 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  <-- 
new revision:; previous revision: 1.189

removing blocking1.4.2 as this is now checked in there
Closed: 21 years ago21 years ago
Flags: blocking1.4.2?
Resolution: --- → FIXED
Keywords: fixed1.6
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.