User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180719140244 Steps to reproduce: Type the first letters of a URL that has been visited before. Actual results: Inline autocomplete does not trigger for some URLs for which it did trigger in previous versions. Unfortunately I cannot detect a pattern as to which URLs are affected. Additionally, the behavior differs across different instances. Two heavily used instances exhibit this issue, whereas another instance that is less frequently used and mostly has its history entries populated via Firefox Sync seems to have no issue. Expected results: Same behavior as in previous versions (before Firefox 62). Consistent inline autocomplete for URLs that have been visited before.

A patch was recently landed in Firefox 62 Beta 11, fixing bug 1474755 that should bring the situation in line with how we expect things to work. Since it's a different algorithm it's still possible a few origins won't be filled the same as before, but it should be rare. Please check Beta 11, that has just been released, if then there is still a specific origin that you visit often and it's not being autofilled, please let me know how you use to visit that page and I could ask you for more debugging information then.

It's indeed much better and mostly usable now, almost as good as before. However I personally prefer more autofill rather than less, so any change in the other direction is a negative for me. I believe the previous algorithm required you to visit a site by typing its URL before inline autofill would start working, which I already found annoying. I would've preferred to have any URL (or at least domain) that's been visited to autofill, as it's often more convenient to just keep typing until the desired URL is autofilled rather than scanning and going down the list of suggestions. From reading the other bug reports (which I unfortunately did not find as I was searching for "autocomplete" rather than "autofill") it seems like the new algorithm is based on a frecency calculation. I think this is absolutely a step in the wrong direction as it makes the autofill non-deterministic from a user's point-of-view, i.e. how many times do I have to visit a URL for it to start autofilling? In fact in one of my two profiles bugzilla.mozilla.org does not get autofilled even in beta 11, whereas in another it does. I simply do not see the point to restrict it in such a manner as the only practical advantage is in saving a backspace/delete keypress when you want to perform a search. Even if the autofill is "wrong" there is no disadvantage at all! In other words, referring to your comment here https://bugzilla.mozilla.org/show_bug.cgi?id=1474755#c6, a meaningful A/B test should be: a. autofill used or ignored b. autofill deleted with backspace/delete In which case even the previous algorithm probably did not fill enough. Also I heavily disagree with your characterization here https://bugzilla.mozilla.org/show_bug.cgi?id=1474755#c11: > I'm sorry, I don't know about your specific case, I was commenting about the wordreference case, where Marco used to pick a url from history, edit the word and submit. In that case something like tab-to-search or keyword makes far more sense. It's not even clear what autofill would provide for that use-case, probably nothing useful. Just because you want to use a site to e.g. perform a search doesn't mean that you want to configure a search provider or keyword bookmark. The fact that autofill could be used for that to save some time is a feature, not a bug, and simply good UX as no user configuration was required. Another example: if you keep a site open in a tab without typing its URL very often, which from what I understand would make it harder for it reach autofill status, and accidentally close it at some point, it becomes harder to reopen it by typing the URL if there's no autofill for it. Also I *think* that most other browsers will start autofilling a domain as soon as it has been visited (or directly typed) just once, like the old algorithm, so I do not see why Firefox should deviate from that norm and also established behavior from previous versions, at least without a large amount of A/B testing (which would have to be performed as explained above, in my opinion). To summarize, the improved frecency calculation could be very useful for ranking autofill items, but should not be used for cutoff, as it: 1. makes autofill non-deterministic (from a user's POV) 2. has no practical advantage except when performing a search 3. goes against established behavior from previous versions and other browsers Please reconsider your decision here, or at least provide a toggle in about:config to restore the previous (or at least a reasonable deterministic) behavior.

(In reply to Liwen Guo from comment #2) > It's indeed much better and mostly usable now, almost as good as before. > However I personally prefer more autofill rather than less, so any change in > the other direction is a negative for me. I understand your preference, but it may not be the best for everyone. The previous behavior already had its downsides, since it was sometimes suggesting origins that the user had typed only once. And we got a bunch of bugs filed about that. Some users find very confusing when a site they visited once or a lot of time ago is suggested, even if, as you said, ignoring the suggestion would be easy. But it's still very prominent and visible so it can be annoying. It's hard to find a solution that works for everyone, so we tried to pick one that should work for most and adapts to most. > how many times do I have to visit a URL > for it to start autofilling? I think that's something you should not care about, just browse normally and the algorithm will adapt to your habits and start helping you. Trying to trick the system is not particularly useful. > Just because you want to use a site to e.g. perform a search doesn't mean > that you want to configure a search provider or keyword bookmark. The fact > that autofill could be used for that to save some time is a feature, not a > bug, and simply good UX as no user configuration was required. That case was not even related to autofill, he was picking a normal history entry from the popup and modifying it, and he found surprising that a so often visited page didn't autofill. > Another example: if you keep a site open in a tab without typing its URL > very often, which from what I understand would make it harder for it reach > autofill status, and accidentally close it at some point, it becomes harder > to reopen it by typing the URL if there's no autofill for it. That's a frecency bug, unrelated to autofill. From this point on we should concentrate on actually "improving" frecency calculation, rather than trying to trick it, as we often did in the past. > Also I *think* that most other browsers will start autofilling a domain as > soon as it has been visited (or directly typed) just once No idea, but it would be useful to collect behavior of other browsers, so if you wish to do that, please do! > Please reconsider your decision here, or at least provide a toggle in > about:config to restore the previous (or at least a reasonable > deterministic) behavior. It's not possible, the previous behavior had a lot of technical downsides too (additionally to not being adaptive at all), for which we don't want it. At a maximum we could add a pref to have a zero threshold, provided there's sufficient feedback requiring that. In general we're not very prone to add thousands of prefs for everything.

Thanks for your reply, appreciate it. > The previous behavior already had its downsides, since it was sometimes > suggesting origins that the user had typed only once. And we got a bunch of > bugs filed about that. Some users find very confusing when a site they > visited once or a lot of time ago is suggested, even if, as you said, > ignoring the suggestion would be easy. But it's still very prominent and > visible so it can be annoying. Agree, but that's still less annoying than having it not work at all. Plus that behavior has existed for years in the public release; the new behavior has only been out a few weeks/months on the nightly and beta channels and there have already been a few bug reports as well. > I think that's something you should not care about, just browse normally and > the algorithm will adapt to your habits and start helping you. Trying to > trick the system is not particularly useful. Indeed I would not care if it "just worked", which it doesn't. Since it (i.e. autofilling a specific domain) doesn't always work, at least there should be a predictable way to make it work, which is not the case either. Of course, if it just worked in the first place it wouldn't matter. > That's a frecency bug, unrelated to autofill. Isn't that (not bumping the frecency of sites that are just kept open in a tab instead of visited by typing the URL) by design? > No idea, but it would be useful to collect behavior of other browsers, so if > you wish to do that, please do! Well my test originally consisted of visiting a site by typing its URL and then checking whether it would autofill, but I just tried that on a new Firefox profile (62 beta 12) and it works there as well, even though it does not on my actual profile. Now that part, while annoying since it means that autofill basically gets worse as time goes on, is not surprising since the frecency threshold for my actual profile is going to be a lot higher, however even as I visited additional sites previous ones continued to autofill. So now I have around 10 different sites in my history, and they all autofill, which contradicts my understanding of the new behavior having a relative instead of absolute frecency cutoff. Edge and from what I remember Chrome work the same with fresh profiles, i.e. visit a site once and it becomes eligible for autofill, but since it seems that any differences are only visible after longer use I won't be able to test that. > It's not possible, the previous behavior had a lot of technical downsides > too (additionally to not being adaptive at all), for which we don't want it. > At a maximum we could add a pref to have a zero threshold, provided there's > sufficient feedback requiring that. In general we're not very prone to add > thousands of prefs for everything. Fundamentally, the new behavior treats autofilling low frecency (i.e. old and rarely visited) sites as a *bug*, while for me and I'm sure many others it is in fact a *feature*. I don't think there's a way to satisfy both without a preference toggle.

Too late to fix in 63. We could still take a patch for 65 and potentially for 64.