BuildID: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3pre) Gecko/20100801 Minefield/4.0b3pre Steps to reproduce: 1.Create a new profile. 2.Visit 10 sites. 3.CTRL+L (or focus the URL bar) 4.Select “Down Arrow” icon in URL bar. 5.ESC and focus again the URL bar. 6.Press the DOWN_ARROW key on your keyboard. Expected results: The display is the same for steps 4 and 6. Actual results: The list of results is displayed without the scroll bar after step 4 (see attached screenshot)

It shows 10 results after step 4, 6 visible results after step 6

Here's the TC on Litmus: https://litmus.mozilla.org/show_test.cgi?id=10439 I don't see any reason why we'd have different behavior in mentioned situations. Scroll bar should be displayed for step 4 as well.

As mentioned in bug 587909 and its associated project page[1], the plan is to remove the scrollbar entirely and display all returned results after both step 4 and step 6. [1] https://wiki.mozilla.org/Improve_display_of_location_bar_results

This patch simply makes it so the maximum number of visible rows in the urlbar always equals the maximum number of results, which is controlled by the browser.urlbar.maxRichResults pref. There's some code in autocomplete.xml [1] that handles the case where the dropmarker and autocomplete results show a different number of items (see showHistoryPopup and maxDropMarkerRows). I didn't touch it in case something else uses that functionality, but if it's useless outside of the urlbar I can get rid of it. It looks like the patch doesn't break any tests: https://tbpl.mozilla.org/?tree=Try&rev=220b9420f127 [1] https://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml#393

Comment on attachment 629908 [details] [diff] [review] v1 - Make maxRows property in urlbar always equal maxResults This looks fine to me. We already handle the case where browser.urlbar.maxRichResults would show more results than would fit on the screen by showing a scrollbar. (In reply to Andrew Hurle [:ahurle] from comment #4) > There's some code in > autocomplete.xml [1] that handles the case where the dropmarker and > autocomplete results show a different number of items (see showHistoryPopup > and maxDropMarkerRows). I didn't touch it in case something else uses that > functionality, but if it's useless outside of the urlbar I can get rid of it. > > [1] > https://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/ > autocomplete.xml#393 I think it's fine not to affect other autocomplete users.

Any reason this (results without scrollbars) was fixed by increasing the size to show 12 results instead of showing 6 results? All the mockups have just 5 results, but it's not clear if it's just for the mockup or by design to keep it a certain height.

Comment on attachment 629908 [details] [diff] [review] v1 - Make maxRows property in urlbar always equal maxResults (In reply to Edward Lee :Mardak from comment #8) > Any reason this (results without scrollbars) was fixed by increasing the > size to show 12 results instead of showing 6 results? > > All the mockups have just 5 results, but it's not clear if it's just for the > mockup or by design to keep it a certain height. I think this comes down to a difference in interpretation of "Remove scrollbar" (original feature page text). Stephen, how many results should be shown now that there is no scrollbar (unless we hit the edge of the screen)?

Once the remaining question has been figured out the associated Litmus test has to be updated. Setting the flag.

(In reply to Matthew N. [:MattN] from comment #9) > Stephen, how many results should be shown now that there is no scrollbar > (unless we hit the edge of the screen)? We should show six. It is the number that was visible before we removed the scrollbar, gives enough results to know if you need to refine, doesn't feel too heavy and gives us some room to grow a little bit with the new slightly larger layout.

Changing browser.urlbar.maxRichResults to 6 should do the trick

Comment on attachment 641614 [details] [diff] [review] Patch to change number of results shown >+++ b/browser/app/profile/firefox.js >-pref("browser.urlbar.maxRichResults", 12); >+pref("browser.urlbar.maxRichResults", 6); Should the previous patch be backed out with this fix?

(In reply to Edward Lee :Mardak from comment #13) > Should the previous patch be backed out with this fix? I say yes so the that when people change the maxRichResults pref to something high (ie. 20) that we don't try to show 20 results at a time.

(In reply to Matthew N. [:MattN] from comment #14) > (In reply to Edward Lee :Mardak from comment #13) > > Should the previous patch be backed out with this fix? > > I say yes so the that when people change the maxRichResults pref to > something high (ie. 20) that we don't try to show 20 results at a time. As I recall, that was the whole reason for adding the scroll bars, for those that wanted more results, but didn't want to hide all the content on the page behind the drop-box. Please, put the scroll-bar back.

Comment on attachment 641614 [details] [diff] [review] Patch to change number of results shown r+ with a backout of attachment 629908 [details] [diff] [review]

https://tbpl.mozilla.org/?tree=Try&rev=ceb10e038e0b Some tests were relying on the maxRichResults pref being above some number, so I temporarily increased it for them. Windows tests aren't done yet, so we'll see if any more need to be fixed...

Comment on attachment 641758 [details] [diff] [review] v2 of pref change patch - fix some failing tests File a new bug. This one is resolved.

(In reply to Stephen Horlander from comment #11) > We should show six. It is the number that was visible before we removed the > scrollbar, gives enough results to know if you need to refine, doesn't feel > too heavy and gives us some room to grow a little bit with the new slightly > larger layout. Why is requiring the user to refine better than providing more results (with or without scrolling)? Note that refining may not always lead to the wanted result, as the user may not remember all relevant details in the title or URL. If I recall correctly, I frequently used to scroll down and actually found the result I was looking for.

The attached patch landed on mozilla-central. There may be legitimate reasons for backing it out, such that it didn't get ui-review. Until it's actually backed out, please stop messing with this bug.

Just my 2 cents: most of the "issues" with results matching in the awesomebar are due to the fact we have far too many data sources fighting for that few results (history, bookmarks, tags, adaptive, switch-to-tab). Cutting in half the number of results without providing a way to "search more" is just going to make that problem worse.

One of the UX best practices is to keep a list of choices within the 7 +- 2 range [1], as any more than 9 choices becomes too large for the user to keep in memory while and less than 5 choices should use a different user interface. [1] http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

You don't need to keep anything in memory here. You just scan the results list until you find the item you were looking for.

(In reply to Dão Gottwald [:dao] from comment #19) > (In reply to Stephen Horlander from comment #11) > > We should show six. It is the number that was visible before we removed the > > scrollbar, gives enough results to know if you need to refine, doesn't feel > > too heavy and gives us some room to grow a little bit with the new slightly > > larger layout. > > Why is requiring the user to refine better than providing more results (with > or without scrolling)? Note that refining may not always lead to the wanted > result, as the user may not remember all relevant details in the title or > URL. If I recall correctly, I frequently used to scroll down and actually > found the result I was looking for. It's true that sometimes the result you are looking for may be beyond the top six results. However it could also be beyond the top 12 results, it could just as easily be the 13th or the 25th and still require refining. The max displayed results just needs to be large enough to show enough results for you to either find what you are looking for or to let you know you need to be more specific; but not so large as to be overwhelming. 12 at once feels like too many, but six might not be enough. A better balance might be eight or nine.

(In reply to Marco Bonardo [:mak] from comment #21) > Just my 2 cents: most of the "issues" with results matching in the > awesomebar are due to the fact we have far too many data sources fighting > for that few results (history, bookmarks, tags, adaptive, switch-to-tab). > Cutting in half the number of results without providing a way to "search > more" is just going to make that problem worse. Doesn't "adaptive" encompass all of those other results? Conceptually history, bookmarks and tabs are all the same thing just in different states so intermingling them shouldn't be a problem. As long as you are correctly finding what you want I am not sure the classification is that important. So I don't really know that these are "issues" unless people are having a hard time finding what they want with the current UI. It might become more of an issue if we add new types of results e.g. search or apps. That said, I wouldn't be opposed at all to a better way to do deep and more comprehensive searches :) Searching in the Library is kind of awkward. But I think that would require a more comprehensive re-design of how we handle bookmarks, history and tabs.

For context, bug 406257 is about the last change to maxRows/browser.urlbar.maxRichResults. I think regardless of which numbers we decide on, the previous patch should be backed out because it hurts users who have set maxRichResults to a high number with the expectation that their entire screen won't be taken up by results. (In reply to Stephen Horlander from comment #24) > 12 at once feels like too many, but six might not be enough. A better > balance might be eight or nine. Clearly everyone seems to have a different opinion on what the best number of results is and how many of them one tends to scroll through (esp. if you look at the bug above). We can't really make any confident assertions about what's best for most users without some data to back it up. Matt proposed that we could leave the numbers as-is (after the backout), then put in some telemetry probes to report the index of the result the user clicked on, then try to figure out our numbers from that data at a later date. If we're going to stick with a new number for now, Matt and I like 9 visible results. It aligns with the number of pages on the New Tab Page, which makes sense for the dropmarker case. It's midway between the probably-too-little 6 results and probably-too-many 12 results, like Stephen said. It's within 7 +/- 2, if that matters. The scrollbar should return for those who have maxRichResults set larger than 9. (In reply to Stephen Horlander from comment #25) > That said, I wouldn't be opposed at all to a better way to do deep and more > comprehensive searches :) Dolske mentioned that we could have something like "Search your Library" as the final result in the autocomplete results, which would open the library and search for whatever you had typed in. Would make it easier to transition into that deeper search mode. Just a thought, but that's something for another bug.

(In reply to Andrew Hurle [:ahurle] from comment #26) > I think regardless of which numbers we decide on, the previous patch should > be backed out because it hurts users who have set maxRichResults to a high > number with the expectation that their entire screen won't be taken up by > results. Ok, I'll back it out. > (In reply to Stephen Horlander from comment #24) > > 12 at once feels like too many, but six might not be enough. A better > > balance might be eight or nine. > > Clearly everyone seems to have a different opinion on what the best number > of results is and how many of them one tends to scroll through (esp. if you > look at the bug above). We can't really make any confident assertions about > what's best for most users without some data to back it up. Matt proposed > that we could leave the numbers as-is (after the backout), then put in some > telemetry probes to report the index of the result the user clicked on, then > try to figure out our numbers from that data at a later date. Sounds good to me. Without data suggesting something else, I think 6+6 is our best bet. It seems to have served us well. > If we're going to stick with a new number for now, Matt and I like 9 visible > results. It aligns with the number of pages on the New Tab Page, which > makes sense for the dropmarker case. It's midway between the > probably-too-little 6 results and probably-too-many 12 results, like Stephen > said. 12 might be overwhelming if you're immediately faced with all items, but this becomes moot after the backout... I.e. this is why we have the scroll bar.

backed out: http://hg.mozilla.org/mozilla-central/rev/868caa9a50c0

(In reply to Stephen Horlander from comment #25) > Doesn't "adaptive" encompass all of those other results? Conceptually > history, bookmarks and tabs are all the same thing just in different states > so intermingling them shouldn't be a problem. As long as you are correctly > finding what you want I am not sure the classification is that important. Searches have to run in a certain order and apppend to a limited list since getting "all" results and coalescing later would be too slow. For example suppose you have 6 max results and adaptive steals the first 4 ones, you are left with 2 results for all of the other matching sources. If you're lucky adaptive found what you were looking for, otherwise the possibility to find your match is bound to number of remaining results, if this number is really low it's likely you'll always have to refine. That said, we really need a telemetry that tells us which are the most commonly autocompleted indices, guessing 6, 9 or 12 is just guessing, may even be 6 is damn good and we don't know.

(In reply to Marco Bonardo [:mak] from comment #29) > That said, we really need a telemetry that tells us which are the most > commonly autocompleted indices There was some data from a test pilot study a while back that I summarized in bug 658120: For searches that end up with a press down and return (to select the first result), the average query length is 3.49 characters. For searches that have any down presses then return, those queries have an average of 3.22 characters and 1.23 downs before return. So at least with those two initial findings, people trade off typing more letters for pressing more down. And they're likely to press down one or two times. It would still be interesting to see how many prefix matches there are for people's adaptive history, but I doubt that it's more than a few for only some prefixes.

Anyone who is working on this bug? We are failing quite constantly in one of our Mozmill tests with a zh-TW build. See bug 818128. It only happens with some locales.

(In reply to Henrik Skupin (:whimboo) from comment #32) > Anyone who is working on this bug? We are failing quite constantly in one of > our Mozmill tests with a zh-TW build. See bug 818128. It only happens with > some locales. That sounds unrelated to this bug, which is about changing the autocomplete popup's maxRows and maxResults settings.

Can this be nominated for the backlog ?

I don't think this is an actionable engineering bug until we have settled on what we actually want to do - some people say 9 results, some 6, some 6 + 6 in the scrollbar (what we have now). The data in comment #30 only provides averages, which makes it impossible to tell how often the result was in the second 6 items (ie how much we'd gain from displaying 9/12/1-million results). And in fact, even if it did, there's the question of whether *showing* 9 results would change the results of the test, because then would people refine differently so as to get things to show up in the 9 results? I don't think this should be backlog+ until we have a plan that's backed by data and/or the UX folks, which it doesn't seem like we do. Gavin?

(In reply to :Gijs Kruitbosch from comment #35) > I don't think this should be backlog+ until we have a plan that's backed by > data and/or the UX folks, which it doesn't seem like we do. Gavin? Why not turn this bug into a [UX] one ?

(In reply to Guillaume C. [:ge3k0s] from comment #36) > (In reply to :Gijs Kruitbosch from comment #35) > > I don't think this should be backlog+ until we have a plan that's backed by > > data and/or the UX folks, which it doesn't seem like we do. Gavin? > > Why not turn this bug into a [UX] one ? I'd be fine with that in principle, but it isn't one right now, isn't one in our estimation spreadsheet, and it's had patches already landed (and backed out) so it seems simpler to keep this an implementation bug and to file a separate UX bug.

I feel like this might be wontfix, but UX exploration into a better overall solution might be valuable.

(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #38) > I feel like this might be wontfix, but UX exploration into a better overall > solution might be valuable. I don't think wontfix is the solution here. Especially considering inconsistencies such as clicking one time the dropdown arrow and then having all the items shown without scrollbar until the browser is restarted. Can UX take this one ?

(In reply to Guillaume C. [:ge3k0s] from comment #39) > (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #38) > > I feel like this might be wontfix, but UX exploration into a better overall > > solution might be valuable. > > I don't think wontfix is the solution here. Especially considering > inconsistencies such as clicking one time the dropdown arrow and then having > all the items shown without scrollbar until the browser is restarted. Please file a separate bug if you think something is broken with the current behavior. It's intentional that clicking the dropdown shows all items, but maybe we should remove this special treatment, I don't know. "until the browser is restarted" definitely sounds like a bug (which I cannot reproduce). In any case, this stuff can be addressed separately, none of this is a compelling reason to change how many results we show when typing.

Filed bug 1060340. Anyway it would be nice to get rid of the scrollbar.

There's actually a tradeoff here: The more items you display, the harder it is to scan them. Addittionally, the awesomebar suggestions are much more likely to be what you are looking for at the top. When clicking the arrow on the other hand, there's no frecency ordering. Plus you probably already know where the item you're looking for will appear. We can (and should) do some A/B testing to find out how we can maximize user performance here. I filed bug 1061755 about this.

(In reply to Philipp Sackl [:phlsa] from comment #42) > There's actually a tradeoff here: The more items you display, the harder it > is to scan them. There's also the issue of covering up more of the page when more items are shown. I've run into cases where I'm trying to copy/type some information from the page that gets covered up by the results, so I end up scrolling down in the page. (Not sure how common this behavior is.) > When clicking the arrow on the other hand, there's no frecency ordering. To be clear, the ordering should be the same as if you typed " " in the location bar -- i.e., it has frecency ordering including the adaptive ranking. The only difference is that currently all 12 results are shown when clicking instead of 6 + 6 scrollable.

(In reply to Ed Lee :Mardak from comment #43) > (In reply to Philipp Sackl [:phlsa] from comment #42) > > When clicking the arrow on the other hand, there's no frecency ordering. > To be clear, the ordering should be the same as if you typed " " in the > location bar -- i.e., it has frecency ordering including the adaptive > ranking. The only difference is that currently all 12 results are shown when > clicking instead of 6 + 6 scrollable. and it only shows typed entries. So frecency-sorted typed urls. I'm not sure why we show 12 results in that case though.

I think this is fixed by bug 1195054, right?

right