1291939 - search results list doesn't update until user stops typing (unless user types slowly)

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P3)

Description

[rixuafli]

I first noticed this issue in Firefox 48 ...

If the user types something into the location bar at a reasonable speed, the results list won't be updated to remove results which no longer match what has been typed until the user stops typing.

To reproduce:
1) type something that produces a lot of results. I suggest just typing the letter "e"
2) now hold down the "e" key and notice that the results list doesn't get updated until you let go of the "e" key

Keep in mind the above is just to illustrate the issue in the easiest way possible.

I have found this bug to be problematic because the way I get to bookmarks is to start typing a search and not stop typing until the results are narrowed to 1-3 results, at which point I stop typing and then press the down arrow to select the appropriate result. Since the results are no longer getting updated while I type, I no longer have a cue for when I can stop typing and select my result.

Comment 4

[Marco Bonardo [:mak]]

un-duping.
This bug is about letting previous searches to continue while a new one starts, so that previous results may still appear while typing.
My thoughts:
It's not possible to wait for the search of "f" to complete before starting the search for "fi", cause we don't have a "done" handler anymore, a search is never complete, it is only either running or canceled. 

Versions before 42 had other downsides (blocking the UI thread and very complex code), but the cancelation was a little bit delayed there because the query didn't have to promptly answer user's input, like the new one.

A middle-way fix may involve using 2 connections, one for inline completion and one for the rest, and then we could let the second one continue a little bit more. That would very likely restore the old behavior.
It would still have some downsides:
1. more complex code (must try to see how much)
2. more memory for the additional connection (likely we could go with a 2MB connection, so it may be acceptable)

Comment 5

[rixuafli]

hey, Marco -- if your suggested solution would address the issue i described and gets implemented, i'd be thrilled :-)

however, it's clear that you feel that suggested solution is less than optimal. i'm a solutions-oriented guy, and i'd like to be able to suggest something you find more palatable, but i guess I don't really understand the problem. why is it that it's not possible to detect when a search is complete? can't e.g. the search send back a message saying something like <searchComplete forString="firef" bySearchProvider="history"/>

sorry if i'm being dense.

Comment 6

[Marco Bonardo [:mak]]

Add-ons don't have an API to say "I'm done", so we can't know when an add-on is done adding results. Their API was just designed like that by Chrome dev team, and we inherited that (imho horrible) API when we moved to web extensions.
A similar problem happens for remote matches that come from the network (search suggestions), we can't predict the network latency/speed (we do have a long timeout though).
Finally, when you stop typing, you want the most relevant results to be there asap, not "once the query for the previous string is done and the new one is started and done".

The suggested solution would bring us back to the pre-43 behavior, that afaict was satisfying for you.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

The awesomebar's current behavior stems from the fact that the user's attention will either be at the keyboard (while typing) or at the result panel (when contemplating which one to pick). We are optimizing for these two use cases because they represent the vast majority, based on our research data. Updating the results at each key press will degrade the performance for these two common cases for a fringe use case. This is a classic engineering trade-off and I believe we have made the right choice.

Comment 8

[avada]

(In reply to Panos Astithas [:past] (please needinfo?) from comment #7)
> The awesomebar's current behavior stems from the fact that the user's
> attention will either be at the keyboard (while typing) or at the result
> panel (when contemplating which one to pick). We are optimizing for these
> two use cases because they represent the vast majority, based on our
> research data. Updating the results at each key press will degrade the
> performance for these two common cases for a fringe use case. This is a
> classic engineering trade-off and I believe we have made the right choice.

So moving past ignoring those who can type without glaring at the keyboard, how on earth would it degrade performance for those who can't?.
Either they're typing in which case they're not watching the results, or watching the results in which case they're not typing so there's nothing to update...

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

The performance degradation stems from the additional concurrent history lookups that happen for each character. They compete for resources with the latest history lookup (which is the only one that matters, but not always the only one still pending) and the UI handling code. We are going to improve things further with bug 1320301.

Comment 10

[rixuafli]

Please clarify ... my understanding of Marco Bonardo's multiple comments is that the lookups are *not* concurrent (that a new lookup cancels the prior lookup) ...

> We also can't avoid canceling the previous search, cause the connection is serialized. If we'd not cancel we should wait for the previous query before we can query again. ... and we have a 0ms timeout for a new search, so every char immediately tries to start a search (and then maybe it's immediately canceled).
(bug 1287418 comment 16)

> You are reasoning with multiple database connections in mind, but we don't have that available, cause it would have an high memory cost
(bug 1287418 comment 34)

Now, if I'm understanding you correctly, you're saying the opposite is true, that a search for "firefox" (typed quickly) results in all of the following lookups occurring simultaneously (thus competing for resources):
"f"
"fi"
"fir"
"fire"
"firef"
"firefo"
"firefox"

Comment 11

[Marco Bonardo [:mak]]

I think there is just some misunderstanding, the important part is "the latest history lookup (which is the only one that matters".
We don't want to spend our (and the users' machines) resources on this at this time, maybe in the future, when we won't have a lot of users on single and dual cores with mechanical disks.

Comment 12

[rixuafli]

marco, if you care about users' machine resources (and if you're "optimizing" for the expected (according to Panos) scenario that a user will not look at results until they finish typing), shouldn't there be a delay before initiating these searches? according to Panos, Mozilla doesn't expect or want users to be looking at the results as they type, so why is Mozilla causing user machines to start 7 searches as the user types "firefox" if the CPU cycles are getting wasted for the first 6 and Mozilla only expects and wants users to look at the results once they've finished typing? shouldn't mozilla use a heuristic to guess when the user might have stopped typing then? wouldn't that be better than showing -- indefinitely -- the results of a search for the first character typed, as the matches for a single character are essentially random? does mozilla also not care about the privacy implications of displaying -- indefinitely -- an essentially random collection of links from the user's history as they type, which can be seen by an onlooker (and an onlooker alone, according with mozilla's logic)?

Comment 13

[Marco Bonardo [:mak]]

(In reply to rixuafli from comment #12)
> marco, if you care about users' machine resources (and if you're
> "optimizing" for the expected (according to Panos) scenario that a user will
> not look at results until they finish typing), shouldn't there be a delay
> before initiating these searches?

There is a delay indeed. Since all the searches happen on a separate thread, we can cancel a query even before it starts doing anything. Bug 1320301 will help with further cancelation if we can get it right.
If you are a slow typer, surely you could get and see results as you type since the cancelation wouldn't hit soon enough.

But honestly, here are conflating completely opposite requirements, and that's another very valid reason why this bug is a wontfix, we can't make everyone happy:
1. one side is asking for us to show results as-you-type.
2. the other side is asking to not show them, because of privacy implication.

Who is right? No one, as usual, everyone has different opinions and priorities.
We just decided we'll follow a "less I/O" target, that is in the end half and half of the above requests; indeed a quick typer will likely only see results at the end, a slow typer may see some of the results as he types.

For privacy there are better tools like Clear Recent History and Private Browsing, nothing here can protect you from an onlooker better than your self judgement and care.

All the rest sounds just like advocacy, and I don't plan to address it here. If you think mozilla is doing something wrong with your privacy this is not the place to express your concerns, you can reach out our mailing lists and governance.

I hope this clarifies once and for all our target. You can disagree, you have expressed your disagreement, that's fine.
Please let's now not cross the advocacy edge.

Comment 14

[rixuafli]

> There is a delay indeed.

I'm referring to a delay intended to distinguish between ms between key presses vs ms after user has stopped typing. You said in bug 1287418 comment 16 that "we have a 0ms timeout for a new search" -- am I misunderstanding something?

> here are conflating completely opposite requirements
> 1. one side is asking for us to show results as-you-type.
> 2. the other side is asking to not show them, because of privacy implication.

Actually, the privacy issue would be mitigated if the results were updated better as-you-type, as was the case in prior versions of firefox, because the more a user types, the more specific the results. E.g., if a user is typing "party supplies", the first character they enter is "p" ... the results might include something embarrassing like "porn" or "penis enlargement", whereas once the user types the next letter "a", the new search for "pa", if completed quickly, would eliminate the more random results. The more the user types, the less chance for irrelevant, potentially embarrassing results to be displayed for more than the brief moment between key presses. as a user, I like to have the suggestions, but I do occasionally enter a search with an onlooker, and it bothers me enormously that essentially random items from my history are displayed the entire time I'm typing.

Also, to clarify, my first preference would be for the results to be updated more faithfully as you type, as was the case in prior versions of firefox, but failing that, and given your statement that mozilla only cares about the results that show when the user stops typing, i'd prefer that results not be shown until i stop typing, because as things stand, only the result of the first character pressed is getting shown (again, essentially random items from my history) until I stop typing. given my second preference, and your statement of mozilla's preference to only attempt to show results once the user has stopped typing, wouldn't a heuristic be advisable? maybe time between key presses can be distinguished from the pause after the user stops typing by an average (maybe it's say 50ms), or maybe this ms value could be configured per user, or maybe firefox could "learn" the user's typing speed.

> We just decided we'll follow a "less I/O" target

wouldn't attempting to distinguish when the user has stopped typing result in less I/O? as opposed to starting a bunch of searches which ultimately are never finished?

> a quick typer will likely only see results at the end

as best I can tell, the search for the first character typed is ALWAYS completed. I can't produce any other result if I try by e.g. tapping the same key repeatedly as fast as I can. therefore, a fast typer sees results for the first character typed until they stop typing, as opposed to only seeing results at the end.

> For privacy there are better tools like Clear Recent History and Private Browsing

even if the user clears their history regularly, there are still bookmarks that show in the results.

> All the rest sounds just like advocacy
> If you think mozilla is doing something wrong with your privacy this is not the place to express your concerns

I'm not sure what this means. I was seeking clarification regarding mozilla's position regarding the relevance of this bug. unfortunately this bug was moved around a lot and discussion of the privacy implications of the issue described in this bug hadn't made it here previously. this bug affects not only user experience but also privacy. you have dismissed the user experience aspect by stating that "most users" don't look at the results as they type, however, you have not yet addressed the privacy aspect.

Comment 15

[Marco Bonardo [:mak]]

(In reply to rixuafli from comment #14)
>, if a user is
> typing "party supplies", the first character they enter is "p" ... the
> results might include something embarrassing

This is pointless and it's a poorman solution that sooner or later will break and leave you naked in public. Private Browsing, CRH and care. Add-ons could also help, like one could make an add-on that removes from history anything containing words out of a blacklist.

> as best I can tell, the search for the first character typed is ALWAYS
> completed.

We're just fast.
You know what happens if we wait? Users will file a bug because we are slow to reply to what he's typing.
We will address part of the problem through bug 1320301 and part through Bug 1291927.

I honestly think I answered everything, and the conversation is going in circles. I don't plan to spend further time on replies unless there's new technical and relevant information.