User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160606200529 Steps to reproduce: It's very obvious when you copy some keywords (for search) or URL externally and paste it to location bar. Try copy some keywords to location bar and follow a quick enter. In 47 Firefox will respond instantly and start to load in no time. However in 48, it often takes a while (~1s) to respond. It gets better after you used it several times (I guess it has some cache mechanism), but still feel really lagging. I also want to node the severity of this performance issue highly depends on your history/bookmark size. It goes much more smooth if you have a brand new profile. I personally have very heavy profile with 6 months history and around 1k bookmarks. That said, there is no such lag in 47's old location bar.

I can't reproduce but I wonder whether this is really related to the new style or to some other change we made. If it's really a problem related to the new style, the size of your places database would probably not matter. Marking P1 because we should probably investigate this soon.

Please try to cleanup the db with my add-on: https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ Also please try in Safe mode, so we can exclude add-on issues: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode finally, it would be great if you could attach a log from about:support FWIW, pasting should have a delay for security reasons, but that is likely broken from quite some time.

(In reply to Marco Bonardo [::mak] from comment #2) > Please try to cleanup the db with my add-on: > https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ > > Also please try in Safe mode, so we can exclude add-on issues: > https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe- > mode > > finally, it would be great if you could attach a log from about:support > > FWIW, pasting should have a delay for security reasons, but that is likely > broken from quite some time. I tried both. It doesn't help. I made a video to show the bug better, if any of you cannot reproduce it. https://www.youtube.com/watch?v=PXpjP7tvTsw FWIW, it doesn't happen all the times. After more testings I found it's not even relevant to my history size (which means after deleting my history, cookie and whatnot sqlite, it CAN still be reproduced). However, sometimes it will suddenly become totally normal without explicitly changing any factors. Weird indeed.

The search is asynchronous and we have to wait for it before we can confirm your Enter press, otherwise results would be unpredictable. In the google.com case, I don't see anything different from what we may expect, I don't think there's much space for improvement. We just changed from sync -> async, a small delay is expected regardless. In the latter case (pasting a long string), since your string is unlikely to match anything, we have to go through the whole db to look for a match. That is expensive and I/O bound. We should check if we are doing our best to handle the Enter press in a meaningful time (as soon as the first match arrives and not further than that).

google.com "case" is not a case. I just open a random website to begin with. That one has no problem. You didn't comment on the last case, pasting a long URL? That one has the worst delay, about 1 sec. 1 sec delay is not "a small delay", it's super annoying and breaks workflow (it has been numerous times that I accidentally cancelled my search/navigating because I ctrl+tab'd to another tab during that unexpected "delay"). Not to mention, none of these explains why it didn't have ANY delay in 47. I guess you haven't really experience this bug yet. Because as I said, it doesn't happen all the time. When it's NOT happening, I can paste and enter very fast just as in 47. You said it needs time to load the first match, but when this bug NOT happening, it doesn't seem to bother load the first match, that the speedy response. When you encounter it you will know my pain. Trust me, it's not something small that is "expected" because of sync->async. Anyway, I will try my best to isolate a more accurate repro :) p.s. did you test it in 48 beta? Because I haven't be able to consistently repro it in Nightly.

Typo: but when this bug NOT happening, it doesn't seem to bother load the first match, that the speedy response -> but when this bug is NOT happening, it doesn't seem to bother load the first match, thus the speedy response

(In reply to Benjamin Peng from comment #5) > You didn't comment on the last case, pasting a long URL? That one has the > worst delay, about 1 sec. I commented on that at the end of comment 2 in reality, pasting urls *should* have a delay for security reasons before we autocomplete (bug 717772). But that's likely broken and I'm not sure what's the code status currently. > "delay"). Not to mention, none of these explains why it didn't have ANY > delay in 47. As I explained, it's async VS sync behavior, firefox 47 does a query synchronously and while it looks like it's "instant" in reality it can cause UI jankiness. > p.s. did you test it in 48 beta? Because I haven't be able to consistently > repro it in Nightly. Nightly has some performance work that Beta doesn't have yet.

Thanks for the quick reply. While I respect your opinion, I still don't think that long delay showed in the video is normal or expected, even after factoring in all these changes. I will wait and see others' opinion on this.

it's not an opinion, I'm just explaining why it happens, while I still think we should try to reduce this problem as far as possible.

As I said, it doesn't happen all the time. I think the delay introduced by 48+ that you were talking about should be the delay in those "normal/working" cases, which is totally acceptable. My case (this bug) is about something abnormal on top of that.

While I still haven't successfully isolate the cause to minimum, I can provide some more observations. When this bug did NOT happen, when you copy some keywords or URLs to location bar, it will INSTANTLY show "Visit {your url}" or "{your keywords} Search with {your search engine}" and at the same time it will try to search your history/bookmark/whatnot for matches. The latter process takes some time depending on the size of your database (it could be more than 1 sec) BUT it will NOT break your further operation (like pressing Enter), even if it's not loaded. Thus there is no delay/sluggishness. But when this bug HAPPENED, when you copy some keywords or URLs to location bar, the drop down menu will be either 1. totally blank 2. It shows your PREVIOUS inputs (NOT your current URL) for a quite while (sometimes up to 1 sec as well) and THEN it will slowly change to that "Visit {your url}" or "{your keywords} Search with {your search engine}", together with possible matches (if any). And more importantly, during this delay, you can't do anything, all your inputs will not be responded until the delay "finished". This new short video showed that slow update: https://www.youtube.com/watch?v=IqkxM7f8gLw The webpage I am using for testing, which seems can cause this bug relatively easily: http://raconteur.net/culture/the-worlds-most-inspirational-people The funny thing is that the probability of this bug happening seem affected by the web pages you opened. If you just open a blank page / new tab page, chances are this bug will NOT happen. However, if you just opened batch of heavy web pages (like commercial news sites), it will be super common and obvious. It's not definite though, I still feel this bug is very random to reproduce. I doubt this is actually more about the new "browser.urlbar.unifiedcomplete" feature we introduced several months ago, which is that "Visit {your url}" or "{your keywords} Search with {your search engine}" thing and apparently it's sometimes stuck. It's worth noting that I knew there is another bug about that in 48 https://bugzilla.mozilla.org/show_bug.cgi?id=1279425

I suspect some of this is due to disk activity and bottleneck. if the disk is very busy, it may take a while to reply to our requests. (In reply to Benjamin Peng from comment #11) > I doubt this is actually more about the new "browser.urlbar.unifiedcomplete" > feature we introduced several months ago As I already said, it's likely, since it's changing the first entry from being synchronous I/O (eventually blocking the main-thread UI) to be async, that means we must wait for the disk to answer us.

From what I can see in "Resource monitor", There is no significant disk activity (let alone heavy) when this happens.

And I am using SSD for FWIW.

Since I have updated my Firefox to 48 (from 45, 46 or 47 I did not know any more), I have been noticing a real performance issue with location bar (I sometimes wait 2 seconds). I think it is related to bug 1296983, bug 1297441, bug 1293042, bug 1291939, bug 1287418 and bug 1269070.

(In reply to Pols12 from comment #15) > Since I have updated my Firefox to 48 (from 45, 46 or 47 I did not know any > more), I have been noticing a real performance issue with location bar (I > sometimes wait 2 seconds). > > I think it is related to bug 1296983, bug 1297441, bug 1293042, bug 1291939, > bug 1287418 and bug 1269070. thanks for collecting the related bugs. I will start to add "see also" for those bugs since I think this one has most info (even a video in comment 3) and people can discuss in one place.

That part "and often blocks user's <Enter> input" is clearly bug 1240217. Therefore bug 1296983, bug 1297441 should not be marked as duplicate of this bug, which is "noticeable delay". Please remove "and often blocks user's <Enter> input" from summary to avoid confusion, and don't steal my bug report.

(In reply to arni2033 from comment #21) > That part "and often blocks user's <Enter> input" is clearly bug 1240217. > Therefore bug 1296983, bug 1297441 should not be marked as duplicate of this > bug, which is "noticeable delay". Please remove "and > often blocks user's <Enter> input" from summary to avoid confusion, and > don't steal my bug report. ... No one "stole" your bug report. I don't even know your reports existed. All these bug reports are related to the new location bar, starting in 48. Your bug report said it's version 39. I failed to see how they are the same thing.

Marco, with the wave of reports coming with 48's release, can you re-evaluate the seriousness of this bug/problem? Thanks.

while bug 1291939 and bug 1287418 may be related to each other, I'm not sure whether they have anything to do with this bug report that you've marked them as duplicates to. they outline specific issues which aren't mentioned in your report. perhaps it would make more sense for you to create a meta bug regarding performance, rather than marking issues different from what you reported here as duplicates?

bug 1291939 doesn't seem to be an issue so much with performance even 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 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 a user types quickly enough, the results pane won't be updated until the user stops typing. it would be better if the most recent search that has yet yielded results were displayed until a later result becomes available.

(In reply to rixuafli from comment #26) > while bug 1291939 and bug 1287418 may be related to each other, I'm not sure > whether they have anything to do with this bug report that you've marked > them as duplicates to. they outline specific issues which aren't mentioned > in your report. perhaps it would make more sense for you to create a meta > bug regarding performance, rather than marking issues different from what > you reported here as duplicates? Check my comment 11, especially the video. I mentioned about the slow update of the drop down menu there, at least the behavior of bug 1287418 (blank dropdown menu). On the other hand, in Bug 1291939 you said it "doesn't update until stop typing", but how to define "typing"? If I type very slowly, say one letter every 5 seconds, it can update just fine. So I think the actual problem should be described as "it updates too *slow*"; and every time you typed a new letter, it will cancel the old search and start a new one, thus it feels it never updates until you stop typing. I do agree with you that the slowness of the drop-down menu update could be another different ticket from this one "not responding to <enter>", since my comment on that was not clear in the first comment but buried in later comments. I could change bug 1291939 to be a duplicate of bug 1287418, does it work for you?

(In reply to Benjamin Peng from comment #28) > how to define "typing"? If I type very slowly, say one letter > every 5 seconds, it can update just fine. So I think the actual problem > should be described as "it updates too *slow*"; and every time you typed a > new letter, it will cancel the old search and start a new one, thus it feels > it never updates until you stop typing. I disagree. it updates very quickly (perhaps within a tenth of a second). the issue isn't with a tenth of a second delay, it's with results never being updated due to earlier searches apparently being canceled. the solution isn't likely "make it faster", but rather "don't cancel earlier searches, show the most recent completed search"

(In reply to rixuafli from comment #30) > (In reply to Benjamin Peng from comment #28) > > how to define "typing"? If I type very slowly, say one letter > > every 5 seconds, it can update just fine. So I think the actual problem > > should be described as "it updates too *slow*"; and every time you typed a > > new letter, it will cancel the old search and start a new one, thus it feels > > it never updates until you stop typing. > > I disagree. it updates very quickly (perhaps within a tenth of a second). > the issue isn't with a tenth of a second delay, it's with results never > being updated due to earlier searches apparently being canceled. the > solution isn't likely "make it faster", but rather "don't cancel earlier > searches, show the most recent completed search" It is a good idea (do not cancel searches as soon as user type letters), however I believe searches in previous versions already cancelled earlier searches: I think it was less visible because search process was faster. Am I right?

Marco Bonardo and Benjamin Peng: To clarify, in bug 1296983 (now marked as a duplicate of this bug), no matter how long I wait after pasting a URL, the Awesome Bar drop-down doesn't show up at all. Of course in that state, Enter does nothing.

Hi Benjamin, Thanks for linking my thread to this one. I had tried searching for a duplicate but I didn't find one, but now that there is an original thread, it's better with more people that understand how annoying this issue is. I'm really surprised as to why this feature isn't discarded. It's a no-brainer. When something wasn't broken in the past releases, why go ahead and break it? I don't recall any issues with releases up to 47. 48 has now introduced this and it's neither needed nor useful. It just breaks workflow. As far as the sync -> async causing UI jankiness in 47 ... maybe that's true, but it's never happened. I really think such features that are nowhere near core-requirements of users be tested thoroughly before being released. After I posted my thread, I was so annoyed by it that I've downgraded to 47. I was expecting it to be fixed by now, but I guess not. If anybody is testing this and not having the issue, please realise that you need a browser that has been in use. Not a test setup that has clean chache and no database to lookup. It needs to be tested on something that is either the real, work environment or at least a duplicate of it. Testing on the browser with clean history/cache has no point because you'll be testing query speed on non-existent data.

(In reply to Benjamin Peng from comment #25) > Marco, with the wave of reports coming with 48's release, can you > re-evaluate the seriousness of this bug/problem? Thanks. How exactly could I evaluate it higher than P1?

(In reply to Benjamin Peng from comment #23) > ... No one "stole" your bug report. I don't even know your reports existed. Now that you know it, don't steal it. > All these bug reports are related to the new location bar, starting in 48. Your > bug report said it's version 39. I failed to see how they are the same thing. You need to read the bug first to understand why Enter key not working is most likely bug 1240217. Also, you can't simply claim w/o any reason that your bug indeed started in Firefof 48: I don't see any reliable way to reproduce here. You can't reproduce it on a clear profile, right? This may as well be external software on your machine or something related to your profile. Therefore your remark about version is wrong. "Version 39" only indicates that long-standing bug 1240217 was broken to the state when even people who don't usually notice bugs could see it.

(In reply to Marco Bonardo [::mak] from comment #34) > (In reply to Benjamin Peng from comment #25) > > Marco, with the wave of reports coming with 48's release, can you > > re-evaluate the seriousness of this bug/problem? Thanks. > > How exactly could I evaluate it higher than P1? Sorry, I didn't notice that. By the way, the performance has been dramatically improved in 49. And I appreciate your work.

taking for investigation, will like file dependencies as soon as I have some patches.

There are some test builds in https://bugzilla.mozilla.org/show_bug.cgi?id=1283329#c21 if you wish to try and report improvements, ALWAYS use a NEW PROFILE and copy your places.sqlite to it. Remember to always backup your profile before testing builds, in any case.

(In reply to Marco Bonardo [::mak] from comment #39) > There are some test builds in > https://bugzilla.mozilla.org/show_bug.cgi?id=1283329#c21 if you wish to try > and report improvements, ALWAYS use a NEW PROFILE and copy your > places.sqlite to it. > Remember to always backup your profile before testing builds, in any case. Use try build win32 for a while, seem fine. I'll use it with my daily profile and keep that way before this bug is fixed, so far so good. Will let you know if regression is noticed.

Please test current nightly and report if the issue is gone.

Does some of fix have been implemented into newest beta 50 (b3 to be exact)? I noticed improvement.

some is in 50b3, some will be in 50b4.

Could you please check beta 4 and let me know if the bug still reproduces?

As far as I can tell, it works pretty good!

Thanks, then I'm resolving this cause looks like the improvements in the dependency bugs hit the nail on the head :) If you should notice other issues with different STR, please file a new bug in Location Bar and we'll track it accordingly.

I reproduced this issue using Fx 48.0, build ID: 20160606200529, on Windows 10 x64. I can confirm the issue is fixed, I used Windows 10 x64, Mac OS X 10.11.6 and Ubuntu 14.04. I verified on: - Fx 50.0b6 (20161010144024) - Fx 51.0a2 (20161010004016) - Fx 52.0a1 (20161010030204) Cheers!