reduce the number of rows in url bar autocomplete from 10 to 6 when we had one line of text per result, I increased it to 10. http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.xul#264 see bug #389584 now that we have two lines per result, 10 rows is pretty tall. note, in the original design for the "faabar", alex suggested 7 http://people.mozilla.com/~faaborg/files/granParadisoUI/places_UnifyingSearch_i2.png thoughts?

I would much rather keep the more results and just drop down the font sizes so it takes up less room.

It's too big of an area to visually look at at once. I have to scan up and down to see all of them, which is slow, and kind of defeats the point.

when using three lines per result (as per bug 406241 ), will you bring it down to three results (seems rather few to me)? Or to "as many as fit onscreen, with scrollbar" (I'd prefer, but maybe it would hurt performance)? Or to something else?

I think 6 is quite possibly too few, and I'd rather make the area smaller (on Mac the fonts are _huge_ for some reason) by reducing font size, as Dave suggested.

In addition to changing the fonts, fixing bug #407804 would also use less space.

I see this as 2 bugs. 1. enough url drop down entries to reach the bottom of the screen. There's 13.5 entries. I'd say there should be about 9-10 (like the autocomplete). 2. when typing in the url bar, the auto complete shows 10 entries. I'd say around 7, as long as it's less than the history. Of course it would still scroll. Does this bug cover both?

Somewhat related is also how many extra results should there be for the user to scroll down to? This affects perf because we try to find those extra results to put into the list. We could do something like 7 rows and 14 or 15 total results. (In reply to comment #4) > I think 6 is quite possibly too few Why would 6 results be too few? Another way to ask.. what is the user doing with the 6 results? Assuming the the autocomplete gives what the user wants as the #1 item (adaptive), the other items aren't as useful. But if they don't find what they want, the extra results can help the user pick words to drill down to make the result they want the #1 result (multi word search).

Perhaps we can reduce the rows by 2 once we get bug 401869 to help users improve the results. We might be able to reduce the rows by another 2 if we get bug 395739 for adaptive learning which will make sure desired pages are in the first few rows.

This is probably OK with multi-word search alone, but I'm marking it depending on bug 395739.

We can get feedback from beta4 which has both multi-word and adaptive.

There's a separate perf issue here as well. How many results do we want to fetch? Right now we fetch 25 rows of results, but if we reduce the size of the autocomplete to show 6 rows, there would still be 3 times the number of pages to scroll through to see the results. If we reduced the number to 15 or 12, results would come back faster as the back-end would stop trying to fetch more results. These are results that the user can't see without scrolling down in the autocomplete popup. Alternatively, if we reduced the number of results to fetch to 6, the popup would never show scrollbars. The user would then rely on typing more words to filter the results to find a desired page.

(In reply to comment #11) Speaking from my own experience, I have never scrolled further than to about the 15th result. If I can't find a page in the top half of the available results, which rarely happens by the way, I usually choose to Google it instead. On the other hand, limiting the number of results to as low as 6 would sometimes hinder my work. It would be enough for accessing bookmarks and other frequently visited pages, but not for re-visting pages for the first time. Pages visited only once are pushed down in the results and I don't always remember the title or the address well enough to filter the results very precisely. In other words, limiting the autocomplete to only 6 results would hinder the use case of "I want to find a page which I came across a week ago and vaguely recall its title, but I know what it was about". I guess that reducing the number to 15 would be a reasonable compromise, assuming it really delivered a noticeable performance gain.

Reduce the number of rows to 6 as well as the number of max results to 12 so that there is at most double the number of entries to look at. Combined with adaptive and multi-word searching, users should be able to easily find/filter the pages that appear in the autocomplete. Additionally, with bug 395161, users have another tool to restrict which pages show up in the list. Perf-wise, the speed of things should double because it only needs to fetch fewer than half the previous number of results. (Results that the user probably wouldn't even have looked at anyway because they require scrolling to find.)

This will not block the final release of Firefox 3.

I'm inclined to think that 6 items: input terms, glance, scroll, improve terms, ... 10 items: input terms, glance, glance, improve terms, ... ...that's to say that 10 items feels easier to give up on, such that there's less of a decision burden between putting effort toward improving search terms vs scrolling -- for which the 6 item box feels a bit constrained, too, after using the 10 items list. Although I'll agree that 10 looks slightly large, if not disturbingly so.

It's not entirely Autocomplete per-say, but is there any reason behind showing 14 rows when pushing the dropdown button? is this number determined dynamically? Small inconsistency more than anything, but figured I'd mention it.

This was taken of the urlbar on 800x600 resolution on WinXP, when using the dropdown (not autocomplete, but history). As you can see, there's 14 items. There's simply too much. I think 6 should be the minimum, and 10 should be the maximum. If you move the focus to the urlbar, and press the down key, the menu shows 10 items. This is how I think it should look.

Clicking the dropdown marker shows more results than if you're typing words. That's by design.

We probably want to satisfy a couple of different goals here: 1. Make sure that the drop-down doesn't "feel" too large 2. Make sure that the drop-down has enough results to maximize the liklihood of finding a match 3. Make sure that the drop-down is scannable as the user's eyes flick back and forth between what they're typing and what's being shown 6 rows is probably a better fit for these goals than 10, so let's go back to that. For the click-the-drop-down case, we can probably scale back to 12.

Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.317; previous revision: 1.316 done Checking in browser/base/content/browser.xul; /cvsroot/mozilla/browser/base/content/browser.xul,v <-- browser.xul new revision: 1.452; previous revision: 1.451 done

in-litmus+; amended the following case to be s/10/6 https://litmus.mozilla.org/show_test.cgi?id=4518

Verified FIXED using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre -and- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre (Verified both the click-on-dropdown-arrow row value of 12, as well as the autocomplete dropdown row value of 6.)

All this talk about "reducing", or "increasing" in another bug, is just simply and totally unnecessary. If possible, the number of lines to be shown "must not be hardcoded" in anyway. Since every user has his/her own preference about the subject only a softcoded option like "browser.urlbar.maxRichResults" to be revealed by "about:config" for advanced configuration will be the most productive and proper solution. Then the discussion should be "is default to be 6 or 10" for such customizable option... I found it quite "vain" for commenters in this and similar bugs demanding a "fixed number of results to their 'liking'" without considering customization, different user needs, accessibility (for disableds), ergonomics (for RSI) and etc. I also strongly suggest 'decision makers' to redefine the "needs" not only by the needs of commenters/authors but also with a greater view including previous perspectives suggested here. If it's the case UI performance versus accessibility/customization, considering today's computing power the latter should weigh more... Not knowing the internals, if this is hardcoded and "can be" softcoded in anyway, then comparing the sake of millions of users versus hardship on the development team, it simply should be softcoded for such...