Closed
Bug 131470
Opened 23 years ago
Closed 21 years ago
Case insensitive history search
Categories
(Core Graveyard :: History: Global, defect)
Core Graveyard
History: Global
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.6final
People
(Reporter: bernard.alleysson, Assigned: Stefan.Borggraefe)
References
Details
(Keywords: fixed1.4.2, fixed1.6, useless-UI)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
neil
:
review+
alecf
:
superreview+
mkaply
:
approval1.4.2+
mkaply
:
approval1.6+
|
Details | Diff | Splinter Review |
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•23 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•23 years ago
|
||
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. ***
Reporter | ||
Comment 4•22 years ago
|
||
one duplicate now confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•22 years ago
|
Component: Browser-General → History: Global
Reporter | ||
Comment 5•22 years ago
|
||
maybe the fix for this bug is to port patch for bug 172272 to Mozilla
Comment 6•22 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•22 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•22 years ago
|
||
Argh. Scratch that. Proposed release note: Mozilla does not allow case insensitive searches of History. (bug 131470)
Updated•22 years ago
|
Severity: enhancement → normal
Comment 11•22 years ago
|
||
*** This bug has been marked as a duplicate of 99091 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 12•22 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•22 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.
Comment 14•21 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•21 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.
Comment 16•21 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•21 years ago
|
Flags: blocking1.4? → blocking1.4-
Comment 17•21 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).
Comment 18•21 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•21 years ago
|
||
This bug should block 1.5 in my opinion.
Comment 20•21 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•21 years ago
|
||
Mozilla crash and burn. No one addresses old bugs anymore.
Comment 22•21 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•21 years ago
|
||
Until this bug can be fixed, history search function should be removed from trunk. Thus, have filed bug 226750.
Comment 24•21 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•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Assignee | ||
Comment 25•21 years ago
|
||
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.
Assignee | ||
Comment 26•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #137427 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 27•21 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•21 years ago
|
||
> 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•21 years ago
|
Attachment #137427 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #137427 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Updated•21 years ago
|
Attachment #137643 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 29•21 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•21 years ago
|
Attachment #137643 -
Flags: superreview?(bryner)
Assignee | ||
Comment 30•21 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•21 years ago
|
Attachment #137643 -
Flags: superreview?(bryner) → superreview?(alecf)
Comment 31•21 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•21 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•21 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
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 34•21 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•21 years ago
|
||
Tested in trunk (1.7 build, 2003122908). It works! Thank you. You are awesome.
Comment 36•21 years ago
|
||
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+
Comment 37•21 years ago
|
||
Checked in to the 1.4 branch.
Assignee | ||
Updated•21 years ago
|
Keywords: fixed1.4.2
Comment 38•21 years ago
|
||
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•21 years ago
|
||
Comment on attachment 137643 [details] [diff] [review] Makes "isnot" case-insensitive, too. a=chofmann for 1.6
Comment 40•21 years ago
|
||
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
Closed: 21 years ago → 21 years ago
Flags: blocking1.4.2?
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•