User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160315153207 Steps to reproduce: Open new tab. Type or paste anything. Press Enter button. Actual results: Sometimes nothing happens. Second press of Enter (which I do after some time has passed) opens the URL. However, next time I start entering the address in address bar FireFox recalls that I pressed Enter twice last time and opens the half-typed URL. No only annoying, but potentially dangerous behavior. I think the bug happens if I press Enter while it's loading something related to suggestions list. FF44 got "Visit ....(URL)" suggestion and that's when it started. Expected results: URL opening

Same stuff here, on Firefox 45.0.x. Got this issue after upgrading from 42.x. In the same time I got this only on FreeBSD in office, and home on Windows FF 45 behaves just fine. From my observations FF ignores Enter in the address bar like 50% of the time, and I cannot localize this issue further or tell what I'm doing when it's ignoring Enter and what I'm not when it doesn't. I saw various complaints in the Internet about this issue, some even from 2013. But I got this on v45 only, and my experience with Firefox is big enough - even on FreeBSD - since 2008th (even longer on Windows), and I've never saw this before. (And I must mention that it's very annoying issue). The only workaround is to press the '->' arrow with a mouse.

Here is a relatively consistent way to reproduce it: Copy some text, e.g. someone's Twitter name. Place the mouse just below address bar, so it's above "Visit ..." item when it's shown. Start entering some address in the address bar. Press End, then Ctrl+V and Enter. Press Enter again. Couldn't make it work on fresh FF, it probably happens only when there's a lot of history and bookmarks to search through.

By "above "Visit ..." item" I mean withing its bounds, so its :hover is triggered.

Workaround: browser.urlbar.unifiedcomplete -> false. Seems like this issue was brought by this new 'weird blue entity' functionality.

(In reply to eugene from comment #4) > Workaround: browser.urlbar.unifiedcomplete -> false. Seems like this issue > was brought by this new 'weird blue entity' functionality. that workaround will go away soon, so not a good idea to rely on it. If you could somehow identify the steps bringing to the cases where it's ignored, it would be really useful. Comment 2 involves pasting a string that is already in the urlbar, and I don't think that's what you usually do when the bug happens, right? So it would be nice to have some steps to reproduce in the normal situations when it happens even if they only work 50% of the times. Though, I suspect it may be related to fast typing+Enter and the fact the search is still ongoing in background... we have some code handling this case (by ignoring Enter until done and then replay it) that may need some tweak.

When Enter is ignored, do you always see a Visit entry, or did you also see it in other cases? Do you see any error reported to the Browser Console?

Yeah, seem like you was right from the very beginning. 'Enter' key really isn't ignored, it's handled as always, only that this 'weird blue entity' adds way more of HDD spinning and of some background work. After it's finished, browser is finally starting to open the desired address, and this can take from 0 to 40 seconds, so when this lag is subjectively high, I'm taking it for 'ignoring Enter' situation. Call me ignorant, but I don't see much difference in functionality with browser.urlbar.unifiedcomplete set on or off, except that lag when it's on (sounds assaulting, but I love FF and appreciate the work Mozilla does on it). As about my HDD, it's a pair of 7200 rpm SATA disks, in mirrored array, plus I use zfs with a large ARC cache, so, I cannot say that my machine is slow. Yes, my history is large enough and I prefer keeping it without periodic flushing.

(In reply to eugene from comment #7) > Yeah, seem like you was right from the very beginning. 'Enter' key really > isn't ignored, it's handled as always, only that this 'weird blue entity' > adds way more of HDD spinning and of some background work. it shouldn't, it does the same work as the previous implementation, but asynchronously instead of synchronously. there is some additional work done for other stuff that we can investigate to check if there's anything abnormally slow. > After it's > finished, browser is finally starting to open the desired address, and this > can take from 0 to 40 seconds, so when this lag is subjectively high, I'm > taking it for 'ignoring Enter' situation. This may be part of the problem. That lag is unexpected, and we should figure out what causes it. Enter should just wait for the next result to come, it shouldn't take more than a few milliseconds, unless the disk is REALLY busy doing something expensive. > Call me ignorant, but I don't see much difference in functionality with > browser.urlbar.unifiedcomplete set on or off, except that lag when it's on > (sounds assaulting, but I love FF and appreciate the work Mozilla does on > it). The difference is mostly technical, unifiedcomplete is a purely asynchronous and more modern implementation that ideally should be less janky than the previous one. > Yes, my history is large enough and I prefer keeping it without > periodic flushing. Does that mean you did something to enlarge or disable history expiration? Would you mind, after a backup, to try running https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ and see if it helps?

(In reply to Marco Bonardo [::mak] from comment #5) > (In reply to eugene from comment #4) > > Workaround: browser.urlbar.unifiedcomplete -> false. Seems like this issue > > was brought by this new 'weird blue entity' functionality. > > that workaround will go away soon, so not a good idea to rely on it. > > If you could somehow identify the steps bringing to the cases where it's > ignored, it would be really useful. > Comment 2 involves pasting a string that is already in the urlbar, and I > don't think that's what you usually do when the bug happens, right? > So it would be nice to have some steps to reproduce in the normal situations > when it happens even if they only work 50% of the times. > > Though, I suspect it may be related to fast typing+Enter and the fact the > search is still ongoing in background... we have some code handling this > case (by ignoring Enter until done and then replay it) that may need some > tweak. Twitter user name is sometimes present on a page somewhere, but yes, pasting is just the fastest way of typing. It's about typing the address before the suggestions list is fully loaded. Blue "Visit ..." suggestion is shown immediately, then there is a delay before other suggestions are shown, then there is another delay before Enter reaction actually happens. Like I said, if I go to the address with a mouse click during these delays, the reaction occurs next time I start typing in the URL bar. Next time I I wonder why Enter reaction is postponed in the first place. That's probably a very dirty hack to fix some other issue. To compare speeds with and without browser.urlbar.unifiedcomplete I'll need to some more testing. Right now, after my experiments with it, suggestions always load super fast. Perhaps because FF has loaded everything it needs (indexes?) from HDD. It would really be great to have such speed from the get go by pre-loading it in the background on browser startup. (In reply to Marco Bonardo [::mak] from comment #8) > > Yes, my history is large enough and I prefer keeping it without > > periodic flushing. > > Does that mean you did something to enlarge or disable history expiration? > Would you mind, after a backup, to try running > https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ and see > if it helps? Same for me, FF by default keeps very little history, so I've increased these parameters back in the day: places.history.expiration.max_pages 1000000 places.history.expiration.transient_current_max_pages 1000000 places.history.expiration.transient_optimal_database_size 304624940 No idea what they actually mean, but this did the job.

(In reply to Sergey Rozhenko from comment #9) > Twitter user name is sometimes present on a page somewhere, but yes, pasting > is just the fastest way of typing. It's about typing the address before the > suggestions list is fully loaded. Blue "Visit ..." suggestion is shown > immediately, then there is a delay before other suggestions are shown, then > there is another delay before Enter reaction actually happens. OK, that delay shouldn't be there. > I wonder why Enter reaction is postponed in the first place. That's probably > a very dirty hack to fix some other issue. Because if you know typing "moz" will autofill "mozilla.org", you may just type "moz" and press enter so fast that we can't have the time to complete to mozilla.org. if we'd not postpone Enter, then you would actually execute a search for "moz" instead of visiting mozilla.org. > (In reply to Marco Bonardo [::mak] from comment #8) > Same for me, FF by default keeps very little history, so I've increased > these parameters back in the day: > places.history.expiration.max_pages > 1000000 ok, this is likely the problem. We expire history because otherwise the awesomebar becomes slow. By enlarging this value you basically disabled expiration, and that made the awesomebar slow. We have some projects that could help here, but in general due to the way we search history, the biggest is the data, the slower will be searching through it.

I don't remember tampering with these exactly settings (but may be I was), but right now I'm also having them unset from defaults: places.history.expiration.transient_current_max_pages;104858 places.history.expiration.transient_optimal_database_size;127445728 and I do have history older than 6 months (took a brief look at it).

The only thing that matters is places.history.expiration.max_pages, the others are uninteresting. The transient ones in particular are set by firefox itself, and those are default values. Btw, we need to investigate if we are doing something wrong when postponing the action.

(In reply to Marco Bonardo [::mak] from comment #10) > > I wonder why Enter reaction is postponed in the first place. That's probably > > a very dirty hack to fix some other issue. > > Because if you know typing "moz" will autofill "mozilla.org", you may just > type "moz" and press enter so fast that we can't have the time to complete > to mozilla.org. if we'd not postpone Enter, then you would actually execute > a search for "moz" instead of visiting mozilla.org. This makes sense. Autofill is very fast, so this should work well when it's made to only wait for autofill to execute and not population of whole suggestions list.

that's what it is already supposed to do.

May be it's another bug, but I want to report that I've also noticed (several times) that awesome bar sometimes starts to open an URL on keypress. Mostly in a situaltion when you need to modify it (for example I was testing a site that I'm working on, and sometimes I need to change URI that is already in an addressbar) - when first letter is typed (for example I started to type 'candidate' to test a new script, and I've only typed 'c', no Enter was pressed or -> with a mouse - no), FF opens new URL (and gets error, because it didn't wait for the whole line).

(In reply to Marco Bonardo [::mak] from comment #12) > Btw, we need to investigate if we are doing something wrong when postponing > the action. Taking this off the QX team tracking for right now -- unclear how to reliably reproduce this or how widespread this is (and sounds like it's more of a Places problem than a URL bar issue anyway?)

nope, the code is all in autocomplete (ulrbarbindings iirc), Places is merely providing results. Look for handleEnterWhenGotResult, I think we need to unset it more often than we do today, and when we handle it we must ensure it makes sense. We could change it from a bool to the string being searched when we set it, and then compare with the current string... Or something like that

Based on comment 17 I feel we should put this back in the QX cluster. I can reproduce this reliably. STR, same as comment #0: Copy https://bugzilla.mozilla.org/show_bug.cgi?id=1258478 Open a new tab Immediately paste in https://bugzilla.mozilla.org/show_bug.cgi?id=1258478 and hit Enter ER: https://bugzilla.mozilla.org/show_bug.cgi?id=1258478 begins loading once Enter is hit AR: There is a delay of about .5 seconds before the page begins loading.

I think there's a little bit of misunderstanding here, so let me try to clarify. postponing is part of the feature and we can't avoid that. when you type "a" and press enter, we MUST wait for the first result to come, to check if it's an autoFill result. This makes things predictable, otherwise we could autoFill or not based on your luck. The problems are: 1. this delay should not be bigger than we need, I fear now we wait for having completely consumed the result, instead of bailing out after the first one. 2. Sometimes we execute Enter on the wrong entry, by the time we execute it the user has changed the value and we end up visiting the previous autoFill that is no more valid. 3. in general, we should never ignore Enter.

needs dependency first -> P3

once bug 1258478 will be fixed (by its dependencies), it should also fix this one. Duping there.

ehr, in comment 21 I clearly meant bug 1279864.

In FF50 the URL bar is still completely broken: ignores Enter and then opens partially-written URL when I press the Go button (I wrote "clevland" in URL bar and it opened search for "clev"). Worst of all, the browser.urlbar.unifiedcomplete setting is ignored!

(In reply to Sergey Rozhenko from comment #23) > In FF50 the URL bar is still completely broken: ignores Enter and then opens > partially-written URL when I press the Go button (I wrote "clevland" in URL > bar and it opened search for "clev"). Worst of all, the > browser.urlbar.unifiedcomplete setting is ignored! Is this reproducible in Safe mode? most cases I've seen were caused by add-ons. So this is the first thing to check. If it still fails even in safe mode, then we need good steps to reproduce the problem. Also note Firefox 51 will be released in a few days, and it has some additional fixes. re: unifiedcomplete pref, that was never intended as a user-side preference, it is our way to develop features, we provide prefs to quickly disable new code before a release until it reaches a shippable status. Once the feature has been shipped, the pref is removed, along with the old code.