show 8 or 10 rows (instead of 6) in the url bar autocomplete results jesse writes: "I think we should show more than 6. IE/Win shows 8 (without a scrollbar) and Safari/Mac shows 10 (with a scrollbar)." fix in hand

Comment on attachment 273842 [details] [diff] [review] patch r=me, enthusiastically might as well kill the #ifndef MOZILLA_1_8_BRANCH stuff now, while you're in the neighbourhood, i think we've really deviated between branch and trunk now.

carrying over mconnor's r= and beltzner's ui-r=

fixed. Checking in browser.xul; /cvsroot/mozilla/browser/base/content/browser.xul,v <-- browser.xul new revision: 1.351; previous revision: 1.350 done

http://litmus.mozilla.org/show_test.cgi?id=4518 in-litmus+

Verified FIXED: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007080208 Minefield/3.0a7pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre In all cases, we display 10 dropdown autocomplete results and have a scrollbar for the rest.

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...