The default bug view has changed. See this FAQ.

History and Bookmarks search result is wrong. Searching history and bookmarks is completely useless for managing them.

RESOLVED FIXED in Firefox 8

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

({regression})

Trunk
Firefox 8
x86
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 537099 [details]
Search result in the Library

Build Identifier: 
http://hg.mozilla.org/releases/mozilla-aurora/rev/436da90e737a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2) Gecko/20110508 Firefox/6.0a2 ID:20110602042006
http://hg.mozilla.org/mozilla-central/rev/9a6c139a4e58
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110602 Firefox/7.0a1 ID:20110602030726

History and Bookmarks search result is wrong.
Searching history and bookmarks is completely useless for managing them.

Reproducible: Always

Steps to Reproduce:
1. Open Library
2. Search https://bugzilla --only 3 items found in my case --it is _wrong_.

3. Search bugzilla --8655 items found in my case --It is correct perhaps.


Actual Results:  
History and Bookmarks search result is wrong.
Number of result is completely wrong.

Expected Results:  
Search of history and Bookmarks should be performed properly.

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/2e5e4197b9db
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110418 Firefox/6.0a1 ID:20110418013520
Fails:
http://hg.mozilla.org/mozilla-central/rev/202537779786
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110418 Firefox/6.0a1 ID:20110418054324
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2e5e4197b9db&tochange=202537779786
Suspencted Bug:
24f177c8b6f6	Marco Bonardo — Bug 630225 - Expose frecency as a sorting order for the history sidebar (with slight query builder optimization). r=dietrich
I suspect that's because the search strips http and https from the url before starting the search.
The reason is practically the same as bug 658242, since now the locationbar and the search box share the same code, they have the same behavior.

We should figure out a non-breaking (add-ons) way of matching like the old search, we could maybe add a MATCH_ANYWHERE_PLAIN behavior that won't do any magic filtering or normalization.
should have been fixed by the patch in bug 658242
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 658242
Resolution: --- → FIXED

Updated

6 years ago
Target Milestone: --- → Firefox 8
You need to log in before you can comment on or make changes to this bug.