Provide option to make Unified Complete appear at bottom as opposed to top

RESOLVED WONTFIX

Status

()

Firefox
Location Bar
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: Paul [pwd], Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141004131347

Steps to reproduce:

The Unified Complete approach is something that's been tried and tested on mobile for a while. It's a success. People use it and enjoy it but it's not intrusive or in the way on mobile, the same can't be said for desktop. Quite simply, it needs to get out of the way of the users. We need to at the very least provide the option to users to have it appear at the bottom of the AwesomeBar list/results as opposed to the top.
(Reporter)

Updated

3 years ago
Component: Untriaged → Location Bar
OS: Linux → All
Hardware: x86 → All
Correct me if I'm wrong, but I believe this assumes that the top result behaves as expected as-is, such that you need to press the Down Arrow key twice to get to what was previously the first "real" result. At the moment, having no item selected and having the first item selected is basically the same berhaviour.

However, bug 1067903 is the missing piece here - which makes that first item auto-selected. We'd no longer have the possibility of not having an item selected, and we'll get back the old behaviour of only needing to press the Down Arrow key once to get to the first history/bookmark item
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

3 years ago
(In reply to Blair McBride [:Unfocused] from comment #1)
> Correct me if I'm wrong, but I believe this assumes that the top result
> behaves as expected as-is, such that you need to press the Down Arrow key
> twice to get to what was previously the first "real" result. At the moment,
> having no item selected and having the first item selected is basically the
> same berhaviour.
I think irrespective of where the first real result is, the option to search should be below all other results. I was trying to get a screenshot but apparently Ubuntu won't allow me to take one with the Location bar open. That said, if we number the results from 1-10, so whether you search or simply open the awesomebar, the "search with..." should be at number ten unless the user is on about:newtab


> 
> However, bug 1067903 is the missing piece here - which makes that first item
> auto-selected. We'd no longer have the possibility of not having an item
> selected, and we'll get back the old behaviour of only needing to press the
> Down Arrow key once to get to the first history/bookmark item
I'm sorry, but unless I'm reading that wrong, bug 1067903 attempts to push suggestions above the sites that Firefox has garnered about users via Places. If so, that'd be a different result to this bug and would still be a huge usability to issue.
this is not an option to search, it's just a visual indication of what happens when you confirm what you are typing in the locationbar.
(Reporter)

Comment 4

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #3)
> this is not an option to search, it's just a visual indication of what
> happens when you confirm what you are typing in the locationbar.
Yup and I'm petitioning for that row of visual identification to be moved to the bottom of the drop down from the location bar.
that wouldn't make any sense. you are typing and we show the action your are about to achieve far from your eyes? sorry, no.
(Reporter)

Comment 6

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #5)
> that wouldn't make any sense. you are typing and we show the action your are
> about to achieve far from your eyes? sorry, no.
Perhaps I'm missing something here. But what we essentially have is a row which is the actual location bar, then we have the visual identification row directly below that, which for all intents and purposes just shows users that they can search from the location bar or click that row instead of the go button. Given that logically speaking, the second row is a tad redundant, I'm unsure as why you feel it doesn't make any sense? To place it at the bottom is saying "hey, if Places doesn't know where you're trying to get to, try this" which is exactly the method which mobile chose. I can honestly say that it makes less sense to me to suggest a search over history/bookmarks. Unless of course Telemetry data says that the majority of users aren't using the awesomebar results. Which, based on the assumption this was a decision made on user data, I initially asked for a preference.
I repeat, it's not an additional option to choose from.
Once it will be autoselected you will see what I mean.

(In reply to Paul [pwd] from comment #6)
> To place it at the
> bottom is saying "hey, if Places doesn't know where you're trying to get to,
> try this" 

yes, that is exactly what this option is NOT about, not a further choice. It's just a fake entry to clarify what happens when you type in the locationbar and press enter (that is currently not discoverable at all)
(Reporter)

Comment 8

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #7)
> I repeat, it's not an additional option to choose from.
> Once it will be autoselected you will see what I mean.
Are there some mockups of the intended behaviour available?

Updated

2 years ago
See Also: → bug 1235891
You need to log in before you can comment on or make changes to this bug.