424797 - The awesomebar doesn't display all results under certain circumstances

Status: RESOLVED INCOMPLETE

(Firefox :: Address Bar, defect)

Description

[Robert [minotaur 11]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032407 Minefield/3.0b5pre

I could reproduce the bug on Ubuntu 7.10 and Windows XP.

Reproducible: Always

Steps to Reproduce:
1.Use the attached places.sqlite test file with 6 Bookmarks (http://a1/, http://a2/, http://a3/, http://ab1/, http://ab2/, http://ab3/) and an entry in the inputhistory for a2
2.Set browser.urlbar.search.chunkSize to 1 and
browser.urlbar.search.timeout to 1000
3.Type "a": Only 5 results are displayed, a1 is missing
4.Type "1": No results displayed.
5.Press space: The result (a1) appears in older builds (around the regression range)



Regression range:
2008022804 a1 displayed in step 3
2008022809 a1 not displayed in step 3

Bonsai query:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-28+04&maxdate=2008-02-28+09%3A59%3A59

Step 4 and 5 could be related to bug 414581. I still see the problematic behavior (results disappear and reappear) sometimes, but i can't reproduce it with the same places.sqlite file on a different OS or PC.

Comment 1

[Robert [minotaur 11]]

Attachment: places.sqlite for testing

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032423 Minefield/3.0b5pre

Confirming that this happens but setting the pref to 1 is a very rare use case. When I set it to 1 it is searching for at least 2 minutes and this is why it is set to a default of 1000. See also Bug 415489.

Comment 3

[Robert [minotaur 11]]

I know that these are not normal/ useful settings, i used them to test bug 424673. Maybe this shows a underlying problem which is difficult to reproduce with normal settings, but still occurs sometimes (like bug 414581 for me).

Comment 4

[Ed Lee :Mardak]

Ok. The problem comes from the adaptive learning putting "ab3" into the list so we filter out the result the second time through, but we don't record it as having more results. Because we have a chunk size of 1, we don't look at other results in the chunk to determine if we need more results.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This also happens to me for a fresh profile without tweaking any of these values. For a simple test just do following:

1. Open as many as possible bugs on bugzilla.mozilla.org
2. Look at the history and see the number of results
3. Go to the location bar and enter "bug"
=> Only a couple of results are displayed.

In my case I've 1847 items within the history which match "bugzilla.mozilla.org". Entering "bug" into the location bar only gives me back 12 results. What about the other 1835 items? Why they are not presented? 

IMO this is a major issue because it decreases the functionality of the Awesome bar. It's designed to give the user the possibility to find an URL as quickly as possible. But without displaying each result it will not be as useful as it should be. I hope that my comment fits into this bug. Otherwise I will create a new bug. I think it's worth asking for blocking meanwhile.

Comment 6

[Ed Lee :Mardak]

Are you talking about how the list only shows 12 items and that it should show 1835 items if you have that many pages that match "bug"?

The list cuts off at 12 for performance and usability to not overwhelm the user with a ton of results that they won't be looking at. If you type words other than "bug", it'll start filtering out pages that don't match all the terms.

Comment 7

[Mike Connor [:mconnor]]

What Edward said.  There's some discussion around adding a "show all matches" option in the future to address the case where users don't keep typing to narrow it down, but that will not block the release.  (For what its worth, Firefox 2 capped at 100 entries, but there was far less intelligent matching, so it was much more common to have to browse the large list of results.)

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

One issue I have is that I'm CC'ed to a lot of plugin related bugs. Searching for "bugzilla plugin" gives me a really small amount of results back and I'm not able to find the right bug. IMO showing only 12 entries is too low while giving the user such an great "search engine".

Comment 9

[Thomas D. (:thomas8)]

Apart from the discussion about how many entries should be shown in the awesomebar result list, what worries me more is that in fact awesomebar doesn't show matching entries even if there are just 2 matches.

I noticed this when I copied a bookmark and changed the title from "Bugzilla" to "[bz] Bugzilla" to reflect the Keyword [sic, not tag] that I assigned to quickly access that bookmark (Writing the keyword in the bookmark's title is a workaround for bug 212605: bookmark keywords not included in location bar autocomplete). Thereafter, typing "[bz" into location bar did NOT bring up the copied bookmark in the location bar dropdown, even though there was just one other match.

Likewise, typing "[" into location bar did not bring up my long-existing and frequently used bookmark titled "[g] google quicksearch", whereas it DID bring up several other bookmarks that I use very rarely (they all have their respective keywords with brackets in their titles). So awesome bar's concept of "frecency" (frequency and recency) does not seem to work on these bookmarks...

In short: Location bar refuses to find certain bookmarks for no apparent reason, even if there is just a very small number of matches (like 2 matches) that have even been frequently used.

Comment 10

[Ben Hutchings]

I'm not seeing all the results I should, with the default awesomebar settings. For example, if I want to go to Amazon and I start typing "am" I do not see any pages in the drop-down, though if I type "www.am" then I see www.amazon.co.uk and www.amazon.com as expected.

Reducing browser.urlbar.search.chunkSize to 100 seems to improve the behaviour. Does this sound like a related or separate bug?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This bug looks related to the problem we have discovered lately with Mozmill. That has been filed as bug 533132. In such a case the autocomplete popup doesn't open at all.

Comment 12

[Marco Bonardo [:mak]]

there are different reports mixed up in this bug, and it's quite old, so there's nothing we can really use to improve today's awesomebar.
If you still notice any issue with a current version please file a new bug.