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 ?
ok 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 confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
This should have a release note. Prosed released note: Mozilla does not allow case sensitive searches of History. (bug 131470)
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: nsbeta1 → helpwanted, nsbeta1-
--> History: Global. Reassign.
QA Contact: claudius → kasumi
*** This bug has been marked as a duplicate of 99091 ***
Status: NEW → RESOLVED
Last Resolved: 16 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 simple.
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.
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.
Status: RESOLVED → REOPENED
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.
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).
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.
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
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 concern.
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 on attachment 137427 [details] [diff] [review] Port of the fix for Firebird to Seamonkey Aren't you missing a comparator in the isnot method?
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. ;-)
Attachment #137427 - Attachment is obsolete: true
Attachment #137643 - Flags: review?(neil.parkwaycc.co.uk)
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+
Attachment #137643 - Flags: superreview?(bryner)
Taking bug. This would be nice to have for 1.6 final.
Assignee: blake → borggraefe
Status: REOPENED → NEW
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 nsCaseInsensitiveUTF8StringComparator
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.
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 ago → 15 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.
Status: RESOLVED → REOPENED
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.
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 <-- nsGlobalHistory.cpp new revision: 22.214.171.124; previous revision: 1.189 done removing blocking1.4.2 as this is now checked in there
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.