1044979 - Awesomebar top result has changed between 33 and 34. And it's annoying.

Status: RESOLVED DUPLICATE of bug 1045985

(Firefox :: Address Bar, defect)

Description

[Paul Rouget [:paul]]

33:
- type "h"
- autocomplete to "hacks.mozilla.org" (because starts with 'h')
- first suggestion: "news.ycombinator.com" (because title includes 'h')

34:
- type "h"
- autocomplete to "hacks.mozilla.org" (because starts with 'h')
- first suggestion: "hacks.mozilla.org"
- second suggestion: "news.ycombinator.com" (because title includes 'h')

The behavior in 34 is annoying as it breaks my habits (one extra keystroke to reach the link I want to open). And I don't see the benefit of duplicating the autocomplete result.

Comment 1

[Paul Rouget [:paul]]

Marco, could this be a consequence of bug 995091?

Comment 2

[Marco Bonardo [:mak]]

yes, it's one of the expected changes. It might indeed break habits, but it's what we should have done from the beginning, poor choice at the time. It confused a lot of users having the autoFill not cope with the first popup entry.

Fwiw, the idea is that soon the first entry will always show the action that Return is going to execute (bug 951624) and then this first entry should be pre-selected, that means going down will effectively go to the second entry.

Comment 3

[Marco Bonardo [:mak]]

I filed bug 1045105 that I think it's a good solution to fix the behavior.

Comment 4

[Paul Rouget [:paul]]

(In reply to Marco Bonardo [:mak] from comment #2)
> yes, it's one of the expected changes. It might indeed break habits, but
> it's what we should have done from the beginning, poor choice at the time.
> It confused a lot of users having the autoFill not cope with the first popup
> entry.
> 
> Fwiw, the idea is that soon the first entry will always show the action that
> Return is going to execute (bug 951624) and then this first entry should be
> pre-selected, that means going down will effectively go to the second entry.

Works for me.

Comment 5

[Paul Rouget [:paul]]

Bug 951624 won't be fixed in time. That means this bug is valid for Firefox 34.

I think this is particularly bad. We will break habits twice. First with the 34 release, and again when bug 951624 will get fixed.

Can we find a simple work-around in the meantime, or backout the code responsible of this change?

Comment 6

[Marco Bonardo [:mak]]

That's the plan indeed, as for any other feature, it should be disabled in Aurora until it's ready for prime time. bug 1045985 is tracked already.