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