<summary> Search Bookmarks/History returns all possible results, instead of just the result for the defined search parameter. <repro environment> build 03-12-04 + Win2000-JA build 03-12-04 + Mac OS 9.04-JA <repro steps> perform a search using a parameter (e.g., name, contains, ...) for an existing bookmark or history keyword <result> Search returns all possible results, instead of just the result for the defined search parameter.
Most of the returned results are not even relevant to your search. It looks like the complete history is returned, for both history and bookmark searches. This behaviour goes away when you manually clear the history. This happens in Milestone 0.8.1, Windows and Linux.
also happens in Mozilla 0.9, windows
*** Bug 78067 has been marked as a duplicate of this bug. ***
I've copied the keywords(adding regression) and target milestone from the dupe bug 78067 (the nsbeta1+ came from pchen in Nav triage). Reassigning to Ben because he owns the code.
Assignee: matt → ben
Keywords: nsbeta1+, nsCatFood, nsdogfood, regression
Target Milestone: --- → mozilla0.9.2
nav triage team: Neither nsdogfood nor nsCatFood, marking nsCatFood-, nsdogfood-, and p2
Keywords: nsCatFood, nsdogfood → nsCatFood-, nsdogfood-
Priority: -- → P2
17 years ago
Status: NEW → ASSIGNED
I see this only for history. Over to alec.
Assignee: ben → alecf
Status: ASSIGNED → NEW
Summary: Search Bookmarks/History returns all possible results, instead of just the result for the defined search parameter. → Search History returns all possible results, instead of just the result for the defined search parameter.
I can confirm this for Windows build 2001052720, although the old search dialog that this bug was created for apparently has gone missing. The new separate search dialogs reveal themselves only after you cast the Ctrl+H Ctrl+F or Ctrl+B Ctrl+F combo. I hope we'll get the old one back eventually ?
ben, this used to work, the only thing that's changed recently is your conversion of the history window to match the bookmarks stuff
*** Bug 83334 has been marked as a duplicate of this bug. ***
Reporting from Linux/PC, Moz build 2001-05-30-08 (with the new, two separate search windows for bookmarks and history, and the extra window popping up for the search results), to clear things up a bit: * search in history still returns _whole_ history (as it did before the window splitting) * search in bookmarks works ok now, and does no longer also return the hits from history. Still the old combined window seemed more practical to me, esp. for refining/revising a search manually after getting the results...
*** Bug 83998 has been marked as a duplicate of this bug. ***
Created attachment 37437 [details] [diff] [review] doh! datasource=history, not datasource=rdf:history
could I get an sr= from ben, and r= from anyone else?
Status: NEW → ASSIGNED
Whiteboard: 1 day, 6/8 [ben-radar] → 6/8 [ben-radar] fix in hand
doh. that was easy. [s]r=blake
a= email@example.com for checkin to the branch and the trunk. (on behalf of drivers)
(from lchiang) - claudius, is this fixed in the latest branch build from afternoon of 6-7? paw told me no so I need to double check. Thanks.
No. In 2001060713 branch builds on all platforms this bug is not at all fixed.
argh, turns out there was a lot more involved.. I'll be attaching a more monsterous patch soon.
ok, that patch: - fixes this bug by implementing the correct search criteria, like "is", "isnot", etc and updating the search resources to their "base" names (i.e. "Name" instead of "http://home.netscape.com/NC-rdf#Name" - removes the "resources" directory from the build, because resource exporting/bundling is already handled by the chrome target in xpfe/components - fixes bug 82277 by doing minimal initialization with mIgnorePrefixes - fixes bug 83490 by changing the "value" attribute of nsIAutoCompleteItem to an nsAString and updating all consumers - fixes bug 85364 by switching to nsAutoString - adds some #if 0'ed code that a few people beside myself need...
a= firstname.lastname@example.org for checkin to the trunk. (on behalf of drivers)
ok, fix is in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
coolio. VERIFIED Fixed with 2001061415 builds
Status: RESOLVED → VERIFIED
Sorry, still seems to be buggy in Windows build 2001061720: the search for entries by "location" does work now, as far as I have tested it, but searching by "name" returns nothing (contains, starts with) or invalid results (doesn't contain).
confirming this bug on build 2001061821/Linux: * searching history for name returns no results for (contains, startsWith, endsWith, is) and all entries for (isNot, doesNotContain). * searching history for location works ok, except for (startsWith, is) - but I could just be too ignorant too guess the right Strings from the locations displayed in the history window... :-)
well, can you file bugs on the individual types of failures? the bulk of the work has been done, but it might be that specific fields or search types fail.
You need to log in before you can comment on or make changes to this bug.