I'm not quite sure how to describe the previous behavior, but text used to appear directly in the address bar, allowing you to then manipulate it with left/right arrow keys. Now the suggestions only appear in the dropdown, requiring you to press tab or down or some such.

We tweaked the algorithm for autofill in bug 1239708, so autofilled things may differ slightly. I also suppose this could just be a symptom of bug 1461753.

Hmm, this is working as expected now. But it was broken earlier, in the same build. I wasn't getting any inline autocomplete at all, I had to press the down arrow to select a result from the autocomplete popup. Is there a migration period during which inline autocomplete is disabled?

Frecency is recalculated asynchronously, it may take some time to rebuild all of it.

FWIW, I suspect that might be it. After restarting a couple domains started working again. (Why do you need to restart?)

There should be no need to restart, it could be a coincidence, but we'll verify.

Yes, this is probably largely bug 1461753. Immediately after updating to the latest Nightly, you may see that autofill doesn't work very well, and then as you start to visit more and more pages, autofill may start working again as the frecency stats start to stabilize. At that point, the frecency mean will probably be larger than it should be and the standard deviation will be lower than it should be since they reflect only recently visited pages (and not your entire history), all of which will have similar, large frecencies. It's possible or even likely too that even if bug 1461753 didn't happen -- if the new autofill were working perfectly as intended -- you'd still see different URLs autofilled than what you're used to seeing, which may or may not seem like a regression. But we need to fix bug 1461753 first to get a better sense of that.

(In reply to Drew Willcoxon :adw (Away May 21–25) from comment #6) > It's possible or even likely too that even if bug 1461753 didn't happen -- > if the new autofill were working perfectly as intended -- you'd still see > different URLs autofilled than what you're used to seeing, which may or may > not seem like a regression. Or a URL may not get autofilled when it previously did because now it doesn't meet the required frecency threshold.

Steps to reproduce the issue: Nightly 62.0a1 (2018-05-16) (64-Bit) macOS 10.13.4 (But maybe OS=All) 1.) Open a new Window 2.) Clear all Browsing Data 3.) Visit macrumors.com 4.) Open a new tab and visit apple.com 5.) Close the whole window 6.) Open a new window 7.) Type ap into the Address Bar Actual: Autocomplete of "apple.com" doesn't work in the Address Bar. Expected: "apple.com" should be autocompleted in the Address Bar.

Tracking for 62 to make sure we follow up here and test it in 62 once bug 1461753 is fixed.

I hope this gets fixed soon, it seriously messes with my muscle memory (type 2 or 3 initial letters of the domain, hit enter to load the site). No matter how often I go to a site now, at best it comes up as the 2nd best match (first being "Search with Google"), at worst the 2nd result is a stray tab somewhere ("Switch to Tab") that happens to match the substring, and so far I haven't gotten the URL filled in at all. A little more concrete: say I want to go to sluggy.com. I used to be able to type "slu" followed by enter. The "ggy.com" bit was prefilled, so sluggy.com loads. Now it suggests I go search "slu" with Google, and "sluggy.com" is the 2nd in the suggested list. If a Google search tab for "slugs" is open, then that will be the third entry with "Switch to Tab". If I already happen to have "sluggy.com" loaded in a tab somewhere, well, it doesn't even make the list as a "Switch to Tab" suggestion, so I end up with a few open "sluggy.com" tabs. Note though that that was already happening before bug 1239708, it's just something I had hoped would've been fixed by it.

This should now be fixed, please let us know if you notice misbehaviors yet.

I suggest filing separata bugs for new misbehaviors at this point, those may be easier to track.

Fixed in bug 1461753, looks like verification is in progress there too.