71903 - Search History returns all possible results, instead of just the result for the defined search parameter.

Status: VERIFIED FIXED

(SeaMonkey :: Search, defect, P2)

Description

[Wesley George]

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

Comment 1

[Alexander Dietrich]

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.

Comment 2

[David Jensen]

also happens in Mozilla 0.9, windows

Comment 3

[Claudius Gayle]

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

Comment 4

[Claudius Gayle]

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.

Comment 5

[Paul Chen]

nav triage team:

Neither nsdogfood nor nsCatFood, marking nsCatFood-, nsdogfood-, and p2

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

I see this only for history. Over to alec. 

Comment 7

[Alexander Dietrich]

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 ?

Comment 8

[Alec Flett]

ben, this used to work, the only thing that's changed recently is your
conversion of the history window to match the bookmarks stuff

Comment 9

[Claudius Gayle]

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

Comment 10

[Erich Kutschinski]

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

Comment 11

[Claudius Gayle]

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

Comment 12

[Alec Flett]

Attachment: doh! datasource=history, not datasource=rdf:history

Comment 13

[Alec Flett]

could I get an sr= from ben, and r= from anyone else?

Comment 14

[Blake Ross]

doh. that was easy. [s]r=blake

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

nice! r=[e-mail]

Comment 16

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the branch and the trunk.
(on behalf of drivers)

Comment 17

[selmer (gone)]

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

Comment 18

[Claudius Gayle]

No. In 2001060713 branch builds on all platforms this bug is not at all fixed.

Comment 19

[Alec Flett]

argh, turns out there was a lot more involved.. I'll be attaching a more
monsterous patch soon.

Comment 20

[Alec Flett]

Attachment: a bunch of bug fixes in one

Comment 21

[Alec Flett]

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

Comment 22

[Joe Hewitt (gone)]

sr=hewitt

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

nice. r=[e-mail]

Comment 24

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 25

[Alec Flett]

ok, fix is in

Comment 26

[Claudius Gayle]

coolio. VERIFIED Fixed with 2001061415 builds

Comment 27

[Alexander Dietrich]

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

Comment 28

[Erich Kutschinski]

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

Comment 29

[Alec Flett]

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.