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

VERIFIED FIXED in mozilla0.9.2

Status

SeaMonkey
Search
P2
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Wesley George, Assigned: Alec Flett)

Tracking

({regression})

Trunk
mozilla0.9.2
regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: 6/8 [ben-radar] fix in hand)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
<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

17 years ago
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

17 years ago
also happens in Mozilla 0.9, windows

Comment 3

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

Comment 4

17 years ago
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

Comment 5

17 years ago
nav triage team:

Neither nsdogfood nor nsCatFood, marking nsCatFood-, nsdogfood-, and p2
Keywords: nsCatFood, nsdogfood → nsCatFood-, nsdogfood-
Priority: -- → P2
Status: NEW → ASSIGNED
Whiteboard: [ben-radar]

Updated

17 years ago
Blocks: 81552
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.

Comment 7

17 years ago
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 ?
(Assignee)

Comment 8

17 years ago
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

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

Comment 10

17 years ago
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

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

Updated

17 years ago
Whiteboard: [ben-radar] → 1 day, 6/8 [ben-radar]
(Assignee)

Comment 12

17 years ago
Created attachment 37437 [details] [diff] [review]
doh! datasource=history, not datasource=rdf:history
(Assignee)

Comment 13

17 years ago
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

Comment 14

17 years ago
doh. that was easy. [s]r=blake

Updated

17 years ago
Blocks: 83989

Comment 16

17 years ago
a= asa@mozilla.org for checkin to the branch and the trunk.
(on behalf of drivers)

Comment 17

17 years ago
(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

17 years ago
No. In 2001060713 branch builds on all platforms this bug is not at all fixed.
(Assignee)

Comment 19

17 years ago
argh, turns out there was a lot more involved.. I'll be attaching a more
monsterous patch soon.
(Assignee)

Comment 20

17 years ago
Created attachment 38102 [details] [diff] [review]
a bunch of bug fixes in one
(Assignee)

Comment 21

17 years ago
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

17 years ago
sr=hewitt

Comment 24

17 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
(Assignee)

Comment 25

17 years ago
ok, fix is in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago
coolio. VERIFIED Fixed with 2001061415 builds
Status: RESOLVED → VERIFIED

Comment 27

17 years ago
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

17 years ago
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... :-)
(Assignee)

Comment 29

17 years ago
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.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.