1620231 - Crop urls in the middle in the results panel

Status: NEW

(Firefox :: Address Bar, defect, P5)

Description

[Simon]

Attachment: feeling lucky?

Being able to quickly and efficiently search one's history for specific pages was one of the strongest features of the urlbar.
For this, one needs to be able to see the relevant parts of the URL and/or title directly in the results.
Comically short truncation of URLs and titles in the design update means this will, in many cases become a super tedious task of tooltipping or cycling through many results instead of a single look, zero effort operation.

It is especially troubling, that this functionality now directly depends on the amount of UI elements competing for space against the urlbar (breaking web-search out into its own bar for more/better history-search results in the urlbar dropdown makes those same results less useful!).

It's clear that no amount of stripping www or http(s), shifting weights between titles and URLs will alleviate this considerably in the available amount of space.

From other bugs it is clear you are unwilling to change the default horizontal size of the dropdown for the sake of it becoming a single but rather useless widget in this configuration and that there is an automatically triggered 2-line mode for ultra-slim window sizes beyond use which thus ends up giving equally short results.

Two reasonable solutions which should remove everyone's gripes about the changes jump to mind:

1. Resizable urlbar dropdown
   Optionally a drag handle for discoverability, it would give users a choice, when they feel the extra space for useful results would outweigh the developers wish for this widget to be visually one consistent thing in width.
   Default configuration users who don't care one way or the other will see no difference to your current implementation.

2. Give a pref to force enable 2-line mode manually.
   IIRC back then this was default, the need for a super wide dropown only came about the then equally controversial decision to put URLs and titles on one line. It's already implemented, let users have the choice.
   Again, no impact on default configuration users.

Would these still collide with your design goals?

Comment 1

[Marco Bonardo [:mak]]

(In reply to Simon from comment #0)

2. Give a pref to force enable 2-line mode manually.
   IIRC back then this was default, the need for a super wide dropown only came about the then equally controversial decision to put URLs and titles on one line. It's already implemented, let users have the choice.
   Again, no impact on default configuration users.

This is already feasible with some userChrome.css rules, so there is already a workaround for the more technical users.

Comment 2

[Dão Gottwald [:dao]]

The page in question is https://forum.manjaro.org/t/linux-firmware-201907-breaks-iwlwifi/96529. Apparently it updates the URL using history.pushState as you scroll through the page. This seems like pretty bad practice, it's basically spamming the browser's history with entries that have the same title and almost the same URL except for the very last part. I think the best fix here would be to trim URLs in the middle rather than at the end, but that's easier said than done.

Comment 3

[BelFox]

I have a similar configuration as Simon (megabar + search bar + quite a few buttons), and the discoverability of the URLs is problematic for me too. I use Firefox's address bar regularly to do some quick REST API testing. Not seeing the URL parameters at the end makes it troublesome to select the right history entry.

Resizable urlbar dropdown
Optionally a drag handle for discoverability, it would give users a choice, when they feel the extra space for useful results would outweigh the developers wish for this widget to be visually one consistent thing in width.
Default configuration users who don't care one way or the other will see no difference to your current implementation.

A drag handle or button to expand the megabar horizontally seems like an elegant solution to me. Especially since the megabar already has a responsive horizontal design ...

The megabar is one of the most used interface elements in FF. Many people will encounter the same issue as Simon and I did.
This deserves better than P5, no?

Comment 4

[Marco Bonardo [:mak]]

As an initial improvement we'll increase the threshold for the 2-lines layout in bug 1629928.

Of course the best solution would be what Dao suggested in comment 2, but it's a technical challenge because there's no crop-in-the-middle css solution available (bug 740910)
As such, this bug is not currently actionable