This issue goes back to at least 43.0. I am not however able to reproduce the issue in 42.0, indicating that it may have started in 43.0. Note that 43.0 is when the following feature was introduced: "Users can choose search suggestions from the Awesome Bar" This may be related, but note that I am able to reproduce with search suggestions disabled. I notice that, while I'm not able to reproduce the issue in the location bar in 42.0, I am able to reproduce in the dedicated search bar in 42.0. Perhaps when the suggestions feature was added to the location bar in 43.0, the programmer applied the same restriction on all location bar searches that apply to suggest searches? 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: hold down the "e" key and notice that, while the results for the first "e" get displayed, the results list doesn't get updated again until you let go of the "e" key Keep in mind the above is just to illustrate the issue in the easiest way possible. The issue occurs for me while merely typing into the location bar. 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. Benjamin Peng suggests that one way to address this issue would be to improve the performance of the search lookup. That is certainly one possibility. However, as it appears that each key press cancels any in-progress searches which have yet to complete and display results (unless heuristics are postponing lookups until there is a certain short idle period), another way to address the issue might be to not cancel all earlier searches, instead allowing them to complete and then displaying whichever available result best matches what the user has typed as it becomes available. e.g., if the user is typing "firefox", has typed as far as "firefo" and the best result available yet is for "fire", display the results for "fire" until a better result becomes available. This as opposed to continuing to show the less specific results for "f" (due to later searches apparently getting canceled). Please note that the search performance on my computer is quite good, with results appearing perhaps within a tenth of a second after I stop typing. The tenth of a second delay would not be a problem if the results lagged what I had typed by that amount, but as things currently stand, the results updates are postponed indefinitely (until I stop typing). As a point of comparison, google suggest doesn't exhibit this problem.
I think this is a dupe of bug 1287418, the request looks the same, and https://bugzilla.mozilla.org/show_bug.cgi?id=1287418#c16 explains some of the reasoning. Since we already have that bug to track the request, I'm duping this one.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1287418
You need to log in before you can comment on or make changes to this bug.