Closed Bug 1262843 Opened 8 years ago Closed 5 years ago

Evaluate allowing users/addons to define a custom awesomebar results layout


(Firefox :: Address Bar, defect, P3)






(Reporter: quicksaver, Unassigned)



Continuing the discussion from bug 1262777 in a more appropriate place.

(In reply to Marco Bonardo [::mak] from bug 1262777 comment #6)
> I don't think it's a new problem.
> Before we had all information packed to the left, while now it flows on a
> single line, taking on avg double the space. By enlarging the panel to the
> whole window on avg we enlarged it less than double. So potentially, we may
> now have less empty space.
> If I take into account a modern 21:9 screen, I'd say the empty space
> situation was not really better before.

Even though aspect ratio seems to trend to increase, it's the overall size pizel-wise that worries me. Even though screens are larger, they don't necessarily hold up more information if they don't have the pixels for it. As far as I know, 1366x766 is still one of the most common resolutions for laptops; and larger resolution screens typically have a zoom factor enabled, so the difference there is minimized as well.

From my personal experience with almost everyone I've seen using chrome (which let's face it is almost everyone), they don't really use its location bar other than to type an address directly or to search for exactly what they type, because the information in its suggestions is not easy to follow. Firefox's has been the exact opposite, because all the info in an item (title and url) was just there in almost the same place.

I see the new suggestions as (possibly!) going in an unfavorable trajectory. I personally dislike a one-line style and preferred the previous two-line style because now I have to physically move my eyes and look for the url (it never starts in the same place, since it depends on the title), and it's easy to lose track of where you are like that: "that's not it, go back to title. Wait, what line was I on?".; <-- huge break in workflow!

Even though I can understand the intention of "cramming up" more information in there, it's just not as easily accessible and will thus IMO be less useful.

Although I can't argue with Marco's words in bug 1262777 comment 4, it's a big change and a small test run to see how it does "out there" can't hurt.

(That's the only detail I disagree with, the rest of the style revamp seems to fall in line with the objectives IMHO.)
Stephen, I assume this has been considered when coming up with the new design (it's probably too big of a point not to have been considered before). Can I ask you for the cliffnotes on it?
Flags: needinfo?(shorlander)
FWIW, this should have been posted to firefox-dev since bugzilla is not a discussion forum. Don't get me wrong, I'm not trying to stop the discussion and I have a great respect for you. Just I don't think it's the right place.
Good point. ;)
+1 while it's still around.
Having the URLs not aligned anymore is highly irritating for any front end dev work where I have to check the same page on different environments. Same title -> different URLs, therefore I am only scanning the URLs
An option to configure this like it was before would be very useful. including more information isn't useful if it's less accessible
See Also: → 1280700
I think in general it would be great if the results layout would be customizable, somehow (either add-ons or a pref, or such).

Fwiw, for now it may be possible to do through css, that I guess may be what Classic Theme Restorer does.
Ever confirmed: true
Summary: Rethink one-line suggestions in awesome bar (discussion only for now) → Evaluate allowing users/addons to define a custom awesomebar results layout
How about an about:config entry (browser.urlbar.resultsFormat), defaulting to:
{star}|{icon}|@{title}( — {action})

This is just an example syntax; explanation:
 - bracketed items (e.g. "{title}") are references
 - pipe character ("|") is a column separator
 - "at" character ("@") indicates the start of what's supposed to align with the location bar
 - parenthesis ("()") indicate that what's contained within should be conditionally displayed (based upon whether the bracketed reference within has a value (because search suggestions do not have an action))
 - newline ("\n") indicates the start of a new line / row for the result
 - everything else (e.g. " — ") is a literal string
 - to specify e.g. literal parenthesis ("()"), user would escape as "\(\)"

Using this syntax, a user would be able to reproduce the "classic" format as follows:
Alternatively, instead of treating "\n" as a marker for a new row, it could be treated as a line break within a column. The "classic" format would then be set as follows:
Priority: -- → P3
Closed: 5 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(shorlander)
You need to log in before you can comment on or make changes to this bug.