250ms as a delay made sense in the context of 2006 (bug 339441, for the curious). However, it feels _impossibly_ slow after using Chrome or google.com's suggestions. They don't appear to have any meaningful delay. bug 612453 doesn't have a delay implemented, and while it's yet to land, switching between that and the searchbar in testing has illustrated just how much of a lag 250ms can be. On top of that, if you type quickly enough you won't hit the timeout until well into a longer search, meaning the feature doesn't give you help unless you pause, or type slowly. Given all of this, I'd like to start with dropping the timeout attribute entirely. If that doesn't create problems, we're good. If there's issues, we can restore a minimal timeout. Thoughts/concerns?
This feels dramatically better to me. Without it, I can type long phrases (like 'this is a test of the emergency broadcast system') without seeing a suggestion. With it I'm seeing suggestions pretty much instantly, updating as I type.
It would help if I qreffed first.
This will result in Google's (and other providers') suggest endpoints being hit more frequently in practice. It would be great if we had some way to model that difference. Can we add a simple telemetry probe for search suggest request volume/frequency and see what happens on Nightly/Aurora/Beta?
There's already a bug around that modelling (bug 1001093). Since this is Google's behaviour across the board (and as far as I can tell, Yahoo/Bing's default as well), I don't think there's a need to block this change on that measurement.
I can propose bug 1001093 for backlog if you want make this depend on it. Having 1001093 fixed would expedite our ability to get Amazon suggestions added.
I don't know if this should depend on it. We're matching what search engines do themselves, and what Chrome does for them, so I'm pretty sure they can handle it. Gavin?
I wonder what impact this would have on bug 542990.
It's somewhat better in low-latency situations, but to address it fully we'd probably need to implement behaviour that delays invalidation until there are new results.
Attachment #8420191 - Flags: review?(gavin.sharp) → review+
Summary: Evaluate lowering or removing the timeout for searchbar autocomplete → remove the delay for searchbar autocomplete
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33
You need to log in before you can comment on or make changes to this bug.