Unfortunately Nightly had a startup crash yesterday which prevents a full bisection:
3:00.33 INFO: Last good revision: 03626342f6e659ac6699a21e30423e2267c1971f
3:00.33 INFO: First bad revision: ff7eec7be698cd21d92755d709e08897100fa9c8

The Megabar now puts URLs and titles on two lines, despite there being plenty of room to fit. This results in the popup being a mostly empty white square, with a tiny bit of text on the left.

Expanding it very slightly returns to the previous behavior, but also makes it clear there was still plenty of headroom to fit everything on one line (see second screenshot). Looks like some size calculation is off?

I only found bug 1630506 in that range but that seems like a weird thing to cause this regression.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=47426d145e246fa1924fbda83a8ecb0d25a6f606&tochange=8854e1368b2088e6b4abb9db1054ae45cb22e5bf

I mean, it seems experiences here are going to vary depending on how long your URLs tend to be. Mine are longer than yours...

We can't really make the result depend on the url length, because otherwise we end up with some results on one line and some on two lines.
What's your screen resolution? It looks really tiny, even at half of my screen with your same amount of icons and the search bar, results are on one line.
This is one of those cases where whatever we pick someone will be unhappy. We could find an half way shaving off 50px from the threshold, I'm sure at that point there will still be users that complain about too much white space and users that complain they don't see enough of their urls.

Maybe what you really want is bug 1627858?

I have the same issue (even with bug 1632073 fixed this will seem excessive).
This is on Windows 10, 1920x1080, DPI set to 150%, full screened Nightly.

(In reply to Marco Bonardo [:mak] from comment #4)

I'm sure at that point there will still be users that complain about too much white space and users that complain they don't see enough of their urls.

If that's not too expensive, maybe it'd be possible to automatically display the 2-line layout if only one of the urls is overflowing (when displayed in 1-line layout)
That way you could satisfy all users needs, I think.
The downside is that it may cause flicker/slowdown when opening the view, because it needs to calculate all that before painting...

(In reply to Itiel from comment #6)

If that's not too expensive, maybe it'd be possible to automatically display the 2-line layout if only one of the urls is overflowing (when displayed in 1-line layout)

It's not impossible technically, but I've seen a few screenshot where urls are overflowing without a reason, so there may be risk of misbehavior, and flickering may also happen (we should first show the entries, then detect overflow, then modify the layout) that would open other issues, as you pointed out.
In the end you'd introduce at least 2 complications and more complex (thus bug-prone) code for every user, for a small benefit to a small subset of users. Let's not forget the UI is functional in both layouts anyway, it doesn't broke any workflow, it's mostly about not liking unused empty space. We also used to have a 2 lines layout for years, without big troubles for users, so it's not like we are doing something new that was never done, and that may have effects unknown to us.

After discussing with UX, we think the large unused space is not a big deal, and we're ok with the status-quo for now.

Of course short urls like top sites are more likely to show a huge empty space, but there's no easy and performant way to react on a case-by-case scenario atm, without causing flicker (if you have ideas please bring them on!).
We don't have data about average url/title length, so I'll mutate this bug to be about that. We'd need some telemetry about those values to be able to make a better call.

We don't have data about average url/title length, so I'll mutate this bug to be about that.

Given that what shows in top sites is sorted by frencency, the telemetry should probably check the average of the URLs that are showing up, rather than the average in the entire db. I think this is relevant because entry URLs are more likely to be shorter.