Especially for the first time after browser start there is noticeable delay in autocomplete popup display that I don't remember to be present in the previous version.

See also: 1279864

Alright, so my bug 1291939 is getting marked as a duplicate -- I just want to ensure the specific issue I described doesn't get lost in the presumption that it's the same as what's described here, so I'm going to outline that issue in this comment ... search results list doesn't update until user stops typing (unless user types slowly) 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. It has been suggested that this is merely a performance issue and might best be addressed by improving the speed of search lookups. I'm not sure that I agree. It doesn't seem to be an issue so much with performance as it is apparently an issue of the async results either being postponed until the user stops typing or (what i think is more likely) of earlier lookups being canceled when another character is typed. if the user types "fire", the search presumably starts looking for matches; if the user doesn't stop typing and completes as "firefox", it seems the earlier lookups ("f", "fi", "fir", "fire", etc.) get canceled, which means that if the delay between each character press is less than the delay in completing a search, the results pane won't be updated until the user stops typing. it would be better if earlier searches were not canceled but allowed to complete with the most recent completed search getting displayed until a later search result becomes available. i believe that regarding this as a performance issue is probably not valid, because: 1) the results are updated very quickly -- perhaps within a tenth of a second on my computer; this isn't a delay that I find problematic in and of itself. if the result pane showed results that were a tenth of a second behind what i've typed, it wouldn't be a problem -- the problem is that if i keep typing, the results are postponed indefinitely (until I stop typing). 2) if this is regarded merely as a performance issue, it may never be addressed for all users, as some computers may not be fast enough to produce a new result in less time than it takes a user to press the next key. it would be better if prior searches were allowed to complete and the most recent completed results were displayed when they become available. 3) "fixing" a performance issue is not necessarily realistic, particularly since the performance is arguably very good as is for comparison, google suggest doesn't have this problem -- i would guess they avoid it not through better performance but rather through not canceling earlier searches.

(In reply to rixuafli from comment #4) As Pols12 said in bug 1279864, it's same in previous versions. I just tested with 46 and 49, the results is the same: If I hold "e", it will only show the results of "e" but not "ee", "eee", ... etc. until I released "e". Proof: https://www.youtube.com/watch?v=k7Hklt4KZ5A Actually, it's the same for the Chrome: if I hold "e", it will only show results of "e" or sometimes "ee", but never "eee". And that scenario is not realistic to typing anyway. When you're typing, no matter how fast you are, you are not HOLDING a key. Instead, you're constantly pressing and release keys. There is no such finale timing called "stops typing"; it happens constantly during your typing process. And every time you release a key, Firefox will try to match. That matching will be cancelled if you are pressing another key; and it will try again with the new keyword (since you typed more letters) after you release the key. It's the case for the old, new, and even Chrome's location bar, nothing was changed. It IS a performance issue. Like I said before, if the updating respond time is 1/10s, when as soon your time speed is slower than that it would be ok. But the problem now is the new location bar updates much slower than the old one (let's say from 1/20s to 1/10s), and your type interval is shorter than 1/10 but longer than 1/20, you won not feel weird in old version but new one.

(In reply to Benjamin Peng from comment #5) > As Pols12 said in bug 1279864, it's same in previous versions. Actually, Pols12 qualified with "I believe" and "Am I right?" > I just tested with 46 and 49, the results is the same: That's useful information -- even more useful information ... I just tested versions 42.0 and 43.0 (among others) -- I am not able to reproduce the problem in 42.0, but I am able to reproduce in 43.0 (i.e. the problem has existed since at least 43.0, perhaps starting there as well). 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. > If I hold "e", it will only show the results of "e" but not "ee", "eee", ... > etc. until I released "e". That's confirmation of the symptom, not the cause. > And that scenario is not realistic to typing anyway. It was meant only as an easy means to reproduce the issue (I specifically stated: "the above is just to illustrate the issue in the easiest way possible") -- I encounter this issue by merely typing, and while I'm no slouch, I'm not a typing prodigy either. > every time you release a key, Firefox will try to match. That matching will > be cancelled if you are pressing another key; and it will try again with the > new keyword And if it didn't cancel, the issue wouldn't exist.... > nothing was changed. You must not follow the releases too closely -- the awesome bar is under near constant revision. And if nothing was changed, why did you dupe all these bugs to your report which posits that these one-hundred-percent-unquestionably performance-only issues started with 48? > It IS a performance issue. Like I said before, if the updating respond time > is 1/10s, when as soon your time speed is slower than that it would be ok. OR, if it didn't cancel all earlier searches it would be okay. What you're saying is like saying that if Firefox was programmed to quit if it doesn't load within a tenth of a second, and Firefox quits for that reason, the cause of the problem is performance rather than the fact that it's programmed to quit.

I may be on to something with the feature introduced in 43.0 ... I notice that, while I'm not able to reproduce the issue in the location/awesome 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 awesome bar in 43.0, the programmer applied the same restriction on all location/awesome bar searches that apply to suggest searches.

I tested 46 because your bug report said it's a bug of 48. If you feel it's introduced in 43, you should try to find the regression window. >That's confirmation of the symptom, not the cause. I never said it is. It's just that "do no search when hold a key" is not a problem in practice. It's introduced in 43 (assuming what you said it right), but people only find it annoying starting from 48. Which means that change itself is non-issue. >You must not follow the releases too closely -- the awesome bar is under near constant revision. And if nothing was changed, why did you dupe all these bugs to your report which posits that these one-hundred-percent-unquestionably performance-only issues started with 48? Please keep the the discussion on the bug, what "I do" is irrelevant to the topic.

(In reply to Benjamin Peng from comment #8) > I tested 46 because your bug report said it's a bug of 48. If you feel it's > introduced in 43, you should try to find the regression window. No, my bug report says "I first noticed this issue in Firefox 48". I can't help your assumptions. I do however appreciate your testing -- it has produced helpful information, which also lead to more testing (of 42.0 and 43.0) which has narrowed this down further. > "do no search when hold a key" is not a problem in practice. It's introduced > in 43 (assuming what you said it right), but people only find it annoying > starting from 48. Which means that change itself is non-issue. The suggestion to hold a key down is for easy reproduction only. I experience the issue merely typing in Firefox 43.0 onward (confirmed through testing). It is not only noticeable/annoying in 48. I see no difference in practice between 43 and 48 with respect to this issue. Neither 43 nor 48 update results while I'm typing. This problem does not manifest for me in 42. > Please keep the the discussion on the bug, what "I do" is irrelevant to the > topic. It's relevant in that you keep asserting things (e.g. "nothing was changed") which are not backed by fact, and if what you "do" is mark several unrelated bugs as duplicates of your own, it's certainly relevant. I assume you're trying to help, however, I'm doing my best to point out where you are making unsupported assertions because I'm afraid those assertions are confusing the issues. If the bug I reported started in 43 and the bug you reported started in 48, they deserve separate bug reports, right?

> mark several unrelated bugs > they deserve separate bug reports Your bug is no longer a duplicate of "mine", I've reverted that immediately after you pointed out yesterday. I don't know why you keep bring that point.

You didn't revert it, you marked it a duplicate again, of this bug, based upon your assertion that my bug was due to a performance issue introduced in 48. You had marked this bug, too, a duplicate of yours, for a total of 7 bugs yesterday. Across 3 bugs you have repeatedly asserted that the issue I reported must be due to a performance issue you reported. It's okay, everyone makes mistakes. But we need to try to clean up this mess now. Should I move this back to my original bug report? Maybe these two bugs (bug 1287418 and bug 1291939) should be be submitted as new bugs, and then you can mark the old ones as duplicates of the new cleaned up ones?

(In reply to rixuafli from comment #11) >You had marked this bug, too, a duplicate of yours I never say I didn't. But it was also reverted immediately. I failed to say why that was relevant to the discussion. >your assertion that my bug was due to a performance issue introduced in 48 I ASSUMED. Because you reported with 'Version: 48 Branch'. If you make it clear in your bug it's 43 I won't even bother to begin with. My opinion on that remains the same: it is changed in 43 (actually I think that change was intentional; but that's just my guess, don't call it "assertion" again please), but it's not a "bug/problem" per se because it has no practical impact *until* the new location bar design made default in 48 which has performance issue.

say->see

(In reply to Benjamin Peng from comment #12) > I failed to see why that was relevant to the discussion. It's relevant because it demonstrates that your assertions don't have credibility on this issue, because it shows a pattern where you have continued to go out of your way to portray unrelated issues as being your own, going so far as to chase me across multiple bugs and repeatedly assert that my bug is due to a performance issue you reported even though the evidence shows that's not where the issue started. It's relevant because, even though the evidence shows the issue started in 43, you still in your latest comment make the unfounded assertion that there was "no practical impact *until* the new location bar design made default in 48 which has performance issue" -- based upon what do you draw that conclusion? My testing shows that there is no difference with respect to this between 43 and 48 (and I'm not referring to just with respect to the reproduction steps, but with my normal typing), as I've already stated, and you keep on making the unfounded assertion. > I ASSUMED. Because you reported with 'Version: 48 Branch'. If you make it > clear in your bug it's 43 I won't even bother to begin with. My original report, and all further references stated only "I first noticed this issue in Firefox 48" -- I didn't assert that it STARTED in 48. That's the difference here, is I don't try to make unfounded assertions. Testing later revealed that the issue goes back to 43. > My opinion on that remains the same: it is changed in 43 (actually I think > that change was intentional; but that's just my guess, don't call it > "assertion" again please) Well there's no problem with your statement about believing it's intentional because it's properly labeled ("I *think*" and "my *guess*"). These are important qualifiers to differentiate between fact and supposition, which matters in a bug report. Regarding my stating that some of your other statements have been assertions, please reference Merriam-Webster (or any other reputable dictionary): assert: "to state or declare positively and often forcefully or aggressively" (http://www.merriam-webster.com/dictionary/asserting) Yes, you made statements/declarations, yes, they were presented positively (as if certain). You've already matched the minimum requirements of the definition. You were also pretty forceful/aggressive in your statements as you've followed me to repeat them across 3 bugs and multiple comments and have continued to repeat them after evidence indicated that the statements were not only unfounded but inaccurate. Examples include: "nothing was changed." "It IS a performance issue." "the problem now is the new location bar updates much slower than the old one" "people only find it annoying starting from 48." "it has no practical impact *until* the new location bar design made default in 48 which has performance issue" I have tried to be polite, and I've tried to work with you here, but it's like talking to a wall. The bottom line is that you're not only being unhelpful, but you're introducing a whole bunch of factual confusion to these bug reports, you're causing discussion of unrelated bugs to get intermingled by incorrectly marking duplicates, and most importantly, you refuse to stop doing these things. My interest is only in clear bug reports. I'm going to recreate these two bugs to clean things up. If you want to get on record with a response, please do so here so as not to bring this mess to yet more bug reports. You can have the last word. Just please don't bring it to the new bug reports. You have made some valid points, such as (paraphrased): "improving performance is another way this issue could be addressed" -- I will include and credit in new report. Please mark this bug as a duplicate of the new cleaned-up bug 1298678 -- thank you.

(In reply to rixuafli from comment #14) I am sorry but you are the one keeps bringing irrelevant personal attack in the comments. I told you that in comment 8 already but you seem didn't want to stop. Fine, I will not comment any more.

Firefox 49 contains some perf improvements for the location bar, that maybe can help a little bit with pure perf. Regardless, the first search in a session will always be a little bit slower, cause a bunch of caches need to be populated. We can't do much about that. 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. Unfortunately running queries while you type is more likely to slowdown our autoFill. 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). From what I got you would like us to let previous searches to run until you stop typing for some ms. While it's technically feasible, it may introduce unfortunate race conditions. I don't have clear ideas for now, but I'll keep this around for more thoughts.

(In reply to Marco Bonardo [::mak] from comment #16) > Regardless, the first search in a session will always be a little bit > slower, cause a bunch of caches need to be populated. We can't do much about > that. Not really. If we know that form now on, by design Firefox addressbar could appear sluggish we can prepopulate caches or mitigate this in other way (depending on exact problem). > 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. > Unfortunately running queries while you type is more likely to slowdown our > autoFill. 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). > > From what I got you would like us to let previous searches to run until you > stop typing for some ms. While it's technically feasible, it may introduce > unfortunate race conditions. Maybe use more than one open, ordered connection to query search engine with no canceling and populate if there wasn't something more recent?

(In reply to Stefan Plewako [:stef] from comment #18) > Not really. If we know that form now on, by design Firefox addressbar could > appear sluggish we can prepopulate caches or mitigate this in other way > (depending on exact problem). The sqlite connection page cache is populated at the first query, unless we fire a fake query (which one, since we can't predict what the user searches more), I'm not sure how you'd do that. And slowing down general startup to speed up the first search doesn't sound like a win. > Maybe use more than one open, ordered connection to query search engine with > no canceling and populate if there wasn't something more recent? It's technically possible, but each connection takes 6MB of memory and hits the disk, and we can't assume everyone has an SSD for fast I/O. It's not free, for sure. It would be more feasible to search/cancel on a timeout, but from past experience that comes with its own rac-y behaviors.

(In reply to Marco Bonardo [::mak] from comment #16) > If we'd not cancel we should wait for the previous query before > we can query again. I believe this would be an improvement for all cases ... In best case, result is always available before user presses next key, so this is not an issue. In worst case (what I'm seeing), result is never available before user presses next key, so it'd be better to update the results with something that's temporarily a few characters behind than to never update it at all.

(In reply to Marco Bonardo [::mak] from comment #19) > (In reply to Stefan Plewako [:stef] from comment #18) > > Not really. If we know that form now on, by design Firefox addressbar could > > appear sluggish we can prepopulate caches or mitigate this in other way > > (depending on exact problem). > > The sqlite connection page cache is populated at the first query, unless we > fire a fake query (which one, since we can't predict what the user searches > more), I'm not sure how you'd do that. And slowing down general startup to > speed up the first search doesn't sound like a win. We can assume (or test) that first query is probably in range a-z and I'm not suggesting slowing down general startup. I'm not sure if 24 queries would be needed to warm up db (depends on the caches probably). Even in the worst case scenario, when user starts browser with one tab and wants to start typing right away there should be enough time to do that. That is of course assuming that sync-async query change is the real problem. Why would it be? What we are gaining by introducing it? (maybe revert it if not much while typing). Why History and Bookmarks do not suffer similarly? Could the code be refactored to not be slower and not jump visually and in general to behave like the previous implementation.

bug 1283329 should help us a little bit.

Please test current Nightly and report progress. While this doesn't fix the cancelation problem (we can evaluate that apart) it should fix the delay.

(In reply to Marco Bonardo [::mak] from comment #23) > Please test current Nightly and report progress. It seems even worse to me in latest Nightly - part of that probably coming from additional elements (Search text and searchplugin icons rows) displayed on the bottom of the popup.

one-off buttons caching is something we discussed and we should look into that. You can try setting browser.urlbar.oneOffSearches = false for your testing. But it shouldn't really be worse. Note we are only trying to show the first result sooner and thus handle Enter sooner, we didn't change anything related to the cancelation problem you reported (not canceling previous queries)

(In reply to Marco Bonardo [::mak] from comment #25) > one-off buttons caching is something we discussed and we should look into > that. You can try setting browser.urlbar.oneOffSearches = false for your > testing. I don't think we understand each other. The problem is not with the buttons displaying slowly but with search results. Adding anything to the bottom of the autocomplete popup makes the ugliness only more obvious. > But it shouldn't really be worse. Note we are only trying to show the first > result sooner and thus handle Enter sooner, First?!!!!1 Why on earth only the first and not whole set? > we didn't change anything > related to the cancelation problem you reported (not canceling previous > queries) And I didn't measure the times, it feels slower and I didn't report cancellation problem.

(In reply to Stefan Plewako [:stef] from comment #26) > I don't think we understand each other. The problem is not with the buttons > displaying slowly but with search results. If the buttons take N ms to show up cause we must rebuild them every time, they will also slow down showing other results. Provided so far this is a Nightly only feature, so I was suggesting to disable those buttons to test. > > But it shouldn't really be worse. Note we are only trying to show the first > > result sooner and thus handle Enter sooner, > > First?!!!!1 Why on earth only the first and not whole set? Cause the first result has a fast path, any other result can take any time from 1ms to seconds. They are added when they arrive, no way to change that, it depends on querying time. Unfortunately, I cannot reproduce any slowdown we didn't address yet, Firefox 50 is the first version with all the fixes we could land so far. The only known problem left, is the first search after startup. Unfortunately in that small timeframe there are so many things ongoing and components starting up that is quite hard to get a responsive experience.

(In reply to Marco Bonardo [::mak] from comment #27) > (In reply to Stefan Plewako [:stef] from comment #26) > If the buttons take N ms to show up cause we must rebuild them every time, > they will also slow down showing other results. Provided so far this is a > Nightly only feature, so I was suggesting to disable those buttons to test. Tested, delay still there, even for first search with row. > Cause the first result has a fast path, any other result can take any time > from 1ms to seconds. They are added when they arrive, no way to change that, > it depends on querying time. Well, not really true - in the previous version results were displayed without this problem and it is not the one and only way to query db. > The only known problem left, is the first search after startup. > Unfortunately in that small timeframe there are so many things ongoing and > components starting up that is quite hard to get a responsive experience. Maybe part of it is in fact related to the startup but not that much for sure - one can test this easily by waiting some time before doing anything.

Another reason this issue is problematic ... as I've mentioned, the results don't get updated until i pause typing ... a consequence of this is that the search results for the first character typed (basically a random list from my bookmarks, since I clear history on shutdown (for most users this would be a random list from their history)) will show throughout my typing, which means if someone is sitting next to me or looking over my shoulder, they'll get to see a random list of items from my bookmarks/history until I stop typing. example: yesterday, someone asked me to go to verizonwireless.com, so I opened my browser and started typing this into the location bar. the results for "v" showed up and included bookmarks I'd rather no one see. this wouldn't be a problem if the results continued to be narrowed down as I typed "e", "r", etc., because the original results would have been gone before most people would be able to read them; but instead the results for "v" continued to show until I finished typing "verizonwireless.com", which took about 2 seconds, which is plenty of time for an onlooker to read some of the "v" results.

(In reply to rixuafli from comment #29) > this > wouldn't be a problem if the results continued to be narrowed down as I > typed "e", "r", etc., because the original results would have been gone > before most people would be able to read them This sounds like the opposite. Showing results for "v", "ve", "ver" would expose even more results to the casual observer. And not everyone may be as fast as you typing, so a more general solution is needed for that case. By the way, note there are already tools to protect your privacy like Clear Recent History, Forget about Site and Private Browsing, that are there exactly for that purpose. We should likely hide unmatching previous results when the input string changes. The problem though, is that this will cause visual flickering. Fwiw, this is covered by bug 1291927. Also, bug 1319727 may help speeding up querying since currently we still have to wait after a query cancellation before starting the next one.

(In reply to Marco Bonardo [::mak] from comment #30) > (In reply to rixuafli from comment #29) > > this > > wouldn't be a problem if the results continued to be narrowed down as I > > typed "e", "r", etc., because the original results would have been gone > > before most people would be able to read them > > This sounds like the opposite. > Showing results for "v", "ve", "ver" would expose even more results Marco, your logic is wrong here. There are more (and more random) matches to the less specific "v" than there are to the more specific "ver". The more characters that are entered, the more the results are narrowed down (fewer matches), and the more relevant they become. If I'm typing verizonwireless.com in front of someone, obviously I don't mind if they see items from my history matching "verizon", whereas if I'm a morman, maybe I don't want them seeing results for "vodka". "vodka" doesn't appear for "ver", whereas it does appear for "v". Plus, keep in mind the "v" doesn't even have to be the first letter to match. The point I was making is that, if the results continued to be updated as I typed, an onlooker would be less likely to be able to see *unrelated* items from my history with each additional character I type. > not everyone may be as fast as you typing, so a more > general solution is needed for that case. Sure, but not everyone is slow enough that this isn't a problem. Maybe this should be a configurable option -- e.g. default to current behavior (cancel prior search as soon as next key is pressed), versus allowing user to set it to finish in-progress search before starting a search based upon the most recent full string. Please understand that, as things stand, affected users have search results which are basically useless as they type (only matching the first letter they type). If a general solution you have in mind addresses the problem for users like me, I'm all for it. If the solution you have in mind is "type slowly", I don't think that's a productive way to look at the problem. > By the way, note there are already tools to protect your privacy like Clear > Recent History, Forget about Site and Private Browsing, that are there > exactly for that purpose. As I've stated, my history is cleared on shutdown. The search results in the example I noted were after first opening firefox and were therefore based exclusively on my bookmarks. Short of disabling results for bookmarks (which I don't want to do), your suggestions don't cover my use case. > We should likely hide unmatching previous results when the input string > changes. The problem though, is that this will cause visual flickering. I assume by "unmatching previous results" you just mean "previous results", since, according to my understanding of the problem, Firefox doesn't know the previous results no longer match, as it hasn't completed the subsequent started and canceled searches. Maybe the solution should be to hide the results if the user has typed say 2 additional characters without firefox producing a result in time for either. Along that line of thought, maybe once a search is canceled for the first time (per location bar focus), firefox should switch from canceling prior search as soon as another character is entered to completing prior search and only starting another one based upon the latest full string once the prior search has completed. Please note that this would solve my use case, since the results are actually extremely fast for me, so the lag wouldn't even be noticeable. Actually, I don't understand why this isn't just made the default behavior (instead of canceling in-progress search, let it complete and only start a new search based upon latest full string once prior search completes) -- see comment 20.

(In reply to rixuafli from comment #31) > Actually, I don't understand why this isn't just made the default behavior > (instead of canceling in-progress search, let it complete and only start a > new search based upon latest full string once prior search completes) Because some parts of the search may take multiple seconds, and I assume you don't want to wait for seconds every time you type a new letter. It's edge cases, but they exist. Some will be solved with future architectural rewrites. While results seems to come fast for you, there may be results incoming you don't ever see cause you are faster than them making a choice. Plus the chrome.omnibox API we now support pretends the add-on implementing it can take infinite time to add its own results, so we can't ever consider the lookup complete (it's dumb, but that's how Chrome designed this API). So no, we can't just wait the previous search to complete.

Marco, I'm hoping you can clarify, because I must misunderstand something (probably due to so many people discussing this across so many bugs), or none of what you said makes sense ... My understanding is that, if a search remains in progress when the user types the next character, the in-progress search is canceled and a new search is started based upon the new (usually) longer string. Please clarify if this understanding is incorrect. If that's the case, I don't understand your comments: > Because some parts of the search may take multiple seconds, and I assume > you don't want to wait for seconds every time you type a new letter. if a new search is started, instead of allowing the in-progress search to complete, the clock for the seconds-long wait is restarted. this means the user has to wait even longer for results. and considering that each new search will generally have more characters, wouldn't you expect each new search to generally take even longer than the prior search which wasn't allowed to complete? I tested my assumption with the time and grep command line tools: time grep -r 'o' . real 0m0.002s user 0m0.002s sys 0m0.000s time grep -r 'op' . real 0m0.039s user 0m0.000s sys 0m0.002s time grep -r 'opt' . real 0m1.172s user 0m0.029s sys 0m0.027s these results indicate that my assumption appears to be generally correct with respect to string searches. Let's take this back and apply numbers to your quote -- let's say that each search takes 5 seconds, and the user types at 1 character per second. we'll also assume the first search is never canceled (because it doesn't appear that it ever is) and that the first result comes up "instantly" (within say 1/10 second, because it always seems to). the user types "mozilla firefox" ... as things currently stand, results for "m" would show up as soon as "m" is entered. no further updates would occur for the next 19 seconds (after which time the results are updated to matches for "mozilla firefox"). that's one search in 19 seconds. on the other hand, if in-progress searches weren't canceled, results for "m" would still show up immediately, then results for "mo" would show up 5 seconds after "o" is entered, and results for "mozilla" would show up 5 seconds after that, and results for "mozilla fire" would show up 5 seconds after that, and final results for "mozilla firefox" would show up 5 seconds later ... that's 4 searches in 20 seconds. it took just 1 second longer to complete an extra 3 searches and actually show the user narrowing results as they type in this hypothetical very-slow-search case. i don't see how canceling the prior search is going to help users to see results faster -- i would expect the opposite to be true, as indicated by the scenarios outlined above. > While results seems to come fast for you, there may be results incoming > you don't ever see cause you are faster than them making a choice. No kidding -- i never see the results because they're canceled every time. I used to be able to type 40WPM, it's probably more like 30WPM now. these aren't world records. I've never seen a search take more than a fraction of a second. if in-progress searches were allowed to complete, and a new search based upon the latest full string only started after that, a lag of a fraction of a second would be much better than a lag that effectively lasts until i stop typing. even if the lag were several seconds, it would be an improvement (see again scenario outlined above). > the chrome.omnibox API we now support pretends the add-on implementing it can > take infinite time to add its own results, so we can't ever consider the > lookup complete (it's dumb, but that's how Chrome designed this API). So no, > we can't just wait the previous search to complete. i assume you mean you can't wait to update the results. i don't object to updating results; i object to the in-progress search being canceled, which prevents new results from appearing as you type.

(In reply to rixuafli from comment #33) > on the other hand, if in-progress searches weren't canceled You are reasoning with multiple database connections in mind, but we don't have that available, cause it would have an high memory cost, so it's a no-go. In future things may change, but first we need to add an FTS index and reduce memory usage for each connection. Just those things may even take up a whole year to be ready to ship (and they are already planned). We have low hanging fruit bugs to cancel queries faster, so we can start the next query sooner. This is something that can be done in weeks, rather than years and it would have a more immediate impact. I think it's unrealistic to discuss now something that will probably be available in 1 or 2 years. Thus, I don't see a reason to further discuss something we can't do.

Marco, I appreciate your effort to explain the issue. I hope you can appreciate my intention to bring to light what appears to me to be the problem and what appears to be the solution (wrong as I may be, I haven't heard a convincing explanation). Do you understand that the issue did not exist in 42 and earlier versions? You speak of functionality that was in 42 as if it's an impossible feat. This is a regression. > You are reasoning with multiple database connections in mind, Am I? I didn't think I was, but maybe I don't understand that what I'm proposing for some reason would take multiple database connections? Let's say user types "firefox" when they hit "f" a search starts. let's say the search doesn't finish before they hit "i" ... I'm not suggesting a search for "fi" start in parallel to the search for "f" -- I'm suggesting search for "f" be allowed to complete before starting another search, and that other search would be based upon the *latest-full-string-at-the-time-the-previous-search-completes*. so a search for "fi" may never even happen -- instead, if the search for "f" doesn't complete until just after the user types "r", then the 2nd search would be for "fir", and then maybe the search for "fir" doesn't complete until the user has typed "e" and "f", so as results for "fir" are added to the dropdown, the 3rd search for "firef" starts, and then maybe this search doesn't complete until just after the user finishes typing "o" and "x", at which point results for "firef" are put in the dropdown and final search for "firefox" begins, and when the results become available, the dropdown is updated once more. in this hypothetical, the following searches were performed (serially) while the user typed "firefox": "f" "fir" "firef" "firefox" is there some reason this isn't possible? for comparison, this is how this is done since 43 (assume results don't come back before next user key press): "f" (first search appears to always be allowed to complete) "fi" canceled "fir" canceled "fire" canceled "firef" canceled "firefo" canceled "firefox" results finally displayed when user stops typing Here, 75% more queries were required than in the hypothetical slow-results situation outlined with my proposed solution above, and yet only half as many result sets were ever put into the dropdown. I understand that a goal of making the searches fast enough that this isn't an issue isn't a realistic solution within the foreseeable future, which is why i've been suggesting a different approach that would seem to address the issue and would not depend upon performance of individual machines, as the best available search results would be presented as they become available, instead of trying and failing to deliver search results for every combination of characters entered into the location bar as is done now.

I'll undupe your bug and post my considerations there, I think there's one possibility.

Marco, we were just discussing this in a Quantum Flow triage session. At face value, this felt like it should remain as a Quantum Flow P1 bug but we're interested in your thoughts and plans here. Thanks.

(In reply to Andrew Overholt [:overholt] from comment #37) > Marco, we were just discussing this in a Quantum Flow triage session. At > face value, this felt like it should remain as a Quantum Flow P1 bug but > we're interested in your thoughts and plans here. Thanks. I don't think the situation is bad as it was before, especially after the recent perf work. Provided there's always space for profiling and improving things, the currently known issues here are: 1. the first location bar search after starting up the browser has to initialize a bunch of components, so it's slower than the next ones. This doesn't involve much main-thread stuff, if you care about that, it's just that sometimes in the startup path we need to do this work. And it's also a bit slower now that it is async, compared to when it was starting up on main-thread. We exchanged main-thread jank for a little bit longer waiting here. (what this bug was about at the beginning before becoming a collection of various complains). 2. we don't have the possibility to interrupt long queries, but bug 1320301, that would allow that, was marked as [qf-]. 3. previous search results are not cleared immediately, but actually fixing that may make things look slower than faster, from a perception point of view (bug 1291927) so it must be done with care. Also won't save any work. 4. we cancel no more relevant queries to save work, and that makes so that we often don't show results until the user stops typing (bug 1291939). Fixing that will make us do MORE work, so it's unclear what we want. To sum up, the only relevant thing here that will make the browser do less work is bug 1320301, but if you're looking for main-thread jank, that's not what you are looking for. All the other fixes here will make code do more work, in some cases things *may* "look" faster, but it's not a given. So, conceptually it sounds like a P1, but it's very different from what you're likely looking for.

Andrew, we just discussed this with Marco and it sounds like this bug is not interesting for QF tracking. The actionable bugs are in the dependencies, with bug 1320301 being the most important one, which we are already tracking from a Search and Photon POV. I'll reset the tracking flag so you all can have another look.