With unified autocomplete disabled, if I start typing "enter" in the location bar, the first result has been "https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox" for ages. It's a site I visit frequently, and it got pushed up there by awesomebar adaptive learning. Since unified autocomplete was enabled, the top result is now "http://enterprise.com/" a site I very infrequently visit. It seems to be favored because it's a top-level URL with no path. This same change in behavior is affecting other "frequently used" location bar shortcuts for me, and they all seem to be cases of an infrequently used top-level address overriding a very frequently used non-top-level address.

will this be solved by bug 1045105?

I'm hitting the same issue and the bug you mentioned would solve it for me. The biggest problem I'm currently having is that my muscle memory wants to hit <tab> once and then <enter>.

Likely bug 1045105 should be a blocker to keep the feature in beta/release. Luckily we can fallback to the old autocomplete with a pref flip on the branches.

(In reply to Marco Bonardo [:mak] from comment #1) > will this be solved by bug 1045105? Looks like it. Though I question whether it's useful to duplicate the autofilled entry in the dropdown - where did we decide to do that? Was that to support bug 951624?

(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #4) > Looks like it. Though I question whether it's useful to duplicate the > autofilled entry in the dropdown - where did we decide to do that? Was that > to support bug 951624? It is to support the idea behind bug 951624, that is to make very clear to the user what is going to happen. From when we enabled the previous "hidden" autoFill behavior we have seen quite a lot of bug reports (and personal irc pings) pointing out it as a bug: "why is it suggesting something that is not even in the results?" "where does it come from?", "it is slowing me down cause I'm checking everytime both the autoFilled value and the first popup entry". I think there has not been an official "decision" about it (and we are still in time to revert it), though seeing the direction we are taking with the locationbar and the many doubts the previous behavior has caused to users, it feels like the right direction to go. I really like the idea of a declarative awesomebar helping the users figuring where they are going. That said, I don't think we should ship it like it is now, for this exact bug.

OK, let's assume for now that this will be addressed by bug 1045105 then.

One tricky aspect is that the original behavior described in comment 0 I believe is "enter<down><return>" where now one needs to do "enter<down><DOWN><return>". Except if there is no first entry from unified autocomplete, it's still just "enter<down><return>" For example, if the unified autocomplete didn't know about enterprise.com but instead engadget.com, "en<down><return>" would go to engadget "en<down><down><return>" would go to enter_bug.cgi "ent<down><return>" would go to enter_bug.cgi The tricky aspect is that it's not consistently <down><return> vs <down><down><return>. So if enterprise.com did become a unified autocomplete result, all of a sudden "ent<down><return>" would go somewhere else. Although arguably, if the first result is supposed to be what the location bar would have done if one hits enter, the first entry should "search for <text>" where <text> isn't link-ish? And this would make it so "ent<down><down><return>" always goes to the adaptive result. Personally, I've been working around this issue by adding a <space>, so "enter<space><down><return>" should take gavin to his expected enter_bugs url.

It's looking like we won't be able to get bug 951624 fixed for Firefox 34. Do we have alternate strategies for addressing this that don't involve disabling unified autocomplete completely?

What's the problem with disabling unified? It was the plan fwiw.

(In reply to Marco Bonardo [:mak] (Away 15-31 Aug) from comment #10) > What's the problem with disabling unified? It was the plan fwiw. Gavin, the two new features linked to UnifiedComplete are the "search provider top suggestion" and the "past search results styling". The first seems in good shape except for general UnifiedComplete bugs like this one, but I believe the second needs more work. With all the other uplifts already planned for 34, I wonder whether we should just follow Marco's suggestion of deferring these to 35. This bug can definitely be dealt with independently, but if we're going to disable UnifiedComplete anyways, it might more efficient to deal with this issue in the other bug.

and even if we moved to a new process, we should not lose the good things about the old one (being able to disable not-yet-ready features and avoid rushing not-yet-satisfying ux)

(In reply to Marco Bonardo [:mak] (needinfo? me) from comment #10) > What's the problem with disabling unified? It was the plan fwiw. The problem, in general, is that it slips some search features to 35 that we were expecting to get in 34. We don't have a choice now, but it would have been ideal for the plan to be clearer to everyone up front rather than only noticed later.

Well, when I said "it was the plan" I just meant that disabling incomplete features has been the plan for any feature from when the rapid release process started. I didn't know we were trying to have those search features in 34 at any cost, otherwise I'd have requested to put more team resources into the autocomplete effort. It looked like a lower priority feature from the backlog noise. To be clear, we _might_ workaround this by removing autoFill from unified and re-enabling the old inline query, but that would be an expensive change, both from a coding point of view (lots of tests to skip and adapt) and from a regressions point of view (we'd basically have a third autocomplete mode totally untested without a nightly cycle). If we only care about the reverse parsing of search urls we could port the code to the old autocomplete, but again we'd be porting a promise based api into an almost synchronous one, and without a Nightly cycle. It might have unexpected consequences and regressions. All options look scary to me.

It seems clear that we must just disable unified autocomplete for 34, and live with the consequences. I filed bug 1064776.

Can we disable this unified feature on Nightly until this issue is fixed? This catches me literally every time I use the location bar. :(

just set browser.urlbar.unifiedcomplete = false Btw, the issue should be fixed in a few days.

I'm duping this to bug 1067903 cause it's the solution we'll implement for this issue.

I'd like to track this separately.

I might be missing some other proposed changes, but I don't think bug 1067903 will completely fix this or potential future fixes will break this behavior again. But the remaining issue might be a corner case. The case that I believe will still be broken is for http:// non-www root pages. For example, http://amazon.com/ will be the first result that de-dupes the old "most frequently autocompleted item" when typing "a" (assuming amazon.com was the adaptive result). This will still break the old behavior. Bug 1067903 happens to fix the "most frequently autocompleted item" behavior for https and www. pages because, at least currently, the first result will be "Visit bugzilla.mozilla.org/" while the second result will be "https://bugzilla.mozilla.org" or similarly "Visit engadget.com/" when the second result is "www.engadget.com". So down-enter will happen to go to the old place, but I could see potential fixes to make unified complete smarter to insert https or www.

autoFill already inserts https or www, just not in a visible way. And we can improve de-duping regarding https and www if the autoFill entry will bring to those (Bug 1046074) even if the downside is that the user won't see the final destination unless we rewrite autocomplete binding to cope with our use-cases. that said, I don't think we can improve autocomplete results without changing autocomplete results at all, some edge cases will definitely change.

now that bug 1067903 is in Nightly, would be good to have your feedback about whether this is still something that should block shipping the feature. It might take some hours/days to test it more thoroughly. If you disabled Unified Complete, please try to enable it again, and help us testing it.

Gavin - we've got one beta left in 35, should we be looking at disabling again as with bug 1064776?

(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #27) > Gavin - we've got one beta left in 35, should we be looking at disabling > again as with bug 1064776? Unified complete is disabled everywhere atm. Nothing to do here.

(In reply to Marco Bonardo [::mak] from comment #26) > now that bug 1067903 is in Nightly, would be good to have your feedback I can't reproduce this, and it seems the bug has grown to conflate some (now fixed) issues: * I can't reproduce the original report - in my limited testing and ignoring that "first special" item, autocomplete now shows the exact same suggestions for me (ie, I can't make any other site be the suggested match for "enter", even with enterprise.com in my history. Ditto for a few other tests I did with my full history) * The "first special" item for enter is "Search for enter", which IIUC is expected, and is what "enter<return>" would do with and without unified autocomplete. * Typing "enter<tab>" (or "enter<down>") now skips past that first entry and selects the "https://bugzilla.mozilla.org/enter_bug.cgi" entry. Pressing <return> visits it. This is the same as without unified enabled. I think it would be useful to have this bug focus on the described issue (which I can't reproduce) and have separate bugs for additional issues when autocomplete is enabled. Gavin, do you agree, and are you still able to reproduce this bug? (In reply to Ed Lee :Mardak from comment #23) > I might be missing some other proposed changes, but I don't think bug > 1067903 will completely fix this or potential future fixes will break this > behavior again. But the remaining issue might be a corner case. I don't fully understand this comment, but Ed, are you able to test how the current behaviour matches your expectations?

(In reply to Mark Hammond [:markh] from comment #29) > (In reply to Ed Lee :Mardak from comment #23) > > I might be missing some other proposed changes, but I don't think bug > > 1067903 will completely fix this or potential future fixes will break this > > behavior again. But the remaining issue might be a corner case. > I don't fully understand this comment, but Ed, are you able to test how the > current behaviour matches your expectations? Do you mean test in nightly 2015-05-10 with browser.urlbar.unifiedcomplete;true? If so, I run into the bug for "http://arstechnica.com/" (note it's a http:// non-www root page). With unified on, the first result is autoselected for "ars" is "Visit arstechnica.com/" so the down-enter behavior takes me to some page that happened to match "ars". With unified off, the first unselected result is "arstechnica.com" and down-enter takes me to the correct page. This doesn't happen for https or www root pages like "https://bugzilla.mozilla.org/" or "http://www.engadget.com/" because in those cases, unified autoselects "Visit bugzilla.mozilla.org/" with the second result being "https://bugzilla.mozilla.org/" or similarly "Visit engadget.com" with the second result being "www.engadget.com" and both these have down-enter go to the expected page. This avoids the bug because the "Visit" entry does not exactly match + dedupes the history result.

Mardak and I chatted on IRC where he clarified the problem and created the screen-shot (thanks!). So IIUC, the issue is when arctechnica.com is itself is in your history (and I can reproduce it when it is) As per the screen-shot: * Without unified enabled "enter" and "down+enter" take you to the exact same place. * With unified enabled, that redundancy is removed; so "enter" and "down+enter" are 2 different URLs. The way I see it (and ignoring muscle-memory), the unified behaviour is actually preferred - "enter" vs "down+enter" take you to 2 different places (ie, no redundancy). And in this scenario, the learned muscle-memory is inefficient - people using "down+enter" should have trained themselves to just press "enter" :) I'm interested to know if there is a similar scenario but one where "enter" vs "down+enter" are not performing the same action with unified disabled?

(In reply to Mark Hammond [:markh] from comment #32) > The way I see it (and ignoring muscle-memory), the unified behaviour is > actually preferred - "enter" vs "down+enter" take you to 2 different places > (ie, no redundancy). The tricky thing here is that there's consistency in being able to go to the top result now even though there's redundancy. With unified, you can go to the top result with the same consistent keystrokes except when the top result happens to be a http site. This may be a corner case that we don't need to fix, and having unified work fine with https. But if we "fix" the redundancy of "Visit bugzilla.mozilla.org" + duplicate "https://bugzilla.mozilla.org/" we end up with the same problem. (And if bugzilla wasn't https, we also run into the problem with subdomains: "Visit bugzilla.mozilla.org" dedupes "http://bugzilla.mozilla.org") > I'm interested to know if there is a similar scenario but one where "enter" > vs "down+enter" are not performing the same action with unified disabled? I don't think so because this only happens because of the redundancy being removed. Otherwise, the unified first result is what is being autofilled and second result is the first-result-when-unified-off.

(In reply to Mark Hammond [:markh] from comment #32) > The way I see it (and ignoring muscle-memory), the unified behaviour is > actually preferred - "enter" vs "down+enter" take you to 2 different places > (ie, no redundancy). And in this scenario, the learned muscle-memory is > inefficient - people using "down+enter" should have trained themselves to > just press "enter" :) I agree - but I don't think we can ignore muscle memory. I'm not sure what to suggest.

I think we should not stop de-duplication improvements just to save "broken" muscle memory. This is nulikely to affect most common use-cases.

Hi Steve, based on the conversation below - we're not sure what the desired behavior should be. can you weigh in?

(In reply to Marco Bonardo [::mak] from comment #35) > I think we should not stop de-duplication improvements just to save "broken" > muscle memory. This is nulikely to affect most common use-cases. I agree. While it is usually undesirable to break muscle memory I think in this case it is better to have some short-term pain (in some cases) to get the correct behavior long-term.

would anyone object to calling this fixed? We should still evaluate improvements, but the global behavior looks good now.

Yeah let's do that.