STR

1. Reduce the width of your Firefox window (or add icons to your toolbar) so that your URLbar is less than 650px wide -- i.e. skinny enough so that urls get displayed below the page title in autocomplete suggestions (instead of being displayed to the side of the page title)
2. Open one tab at https://example.org
3. In another tab, type "exam" into the URL bar, and pay attention the "Switch to tab" entry in the dropdown.
4. Press your Ctrl key (or Cmd on mac)

ACTUAL RESULTS:

• The switch-to-tab entries change lose the "Switch to tab" badge and gain the URL (i.e. they becomed regular same-tab suggestions).
• When the URL shows up, that makes the entry taller.
• So your whole autocomplete popup changes layout.
• So e.g. if you're about to click some other entry, you might suddenly click the wrong thing because everything just moved out from under you.

EXPECTED RESULTS:
No such sudden relayout when I press Ctrl (or Cmd). Maybe we should make these entries tall enough to have space for their URL up-front, so that they don't get taller and force a relayout?

Note: This is worse if you have the about:preferences Show search suggestions ahead of browsing history in address bar results option un-checked. In that configuration, the tab-switch suggestion is grouped at the very top of the autocomplete popup, so that entry's height-change causes essentially the entire contents of the popup to move.

Here's a screencast showing the issue, with me just following the STR (and hitting Ctrl a bunch of times, with each press causing the Switch-to-Tab suggestion to change height). First I use the default configuration, and then I use the alternate configuration mentioned in my "Note" above.

(Both configurations are problematic; some amount of content unexpectedly has to jump to a new position in both cases, when I press Ctrl; but the latter configuration is more-problematic since more content has to jump out of the way.)

I suspect the behavior here might sort-of be intended-behavior -- i.e. we do seem to intentionally make the autocomplete popup-entries not-as-tall if they're not showing a second line (with the URL), which is nice from a space-saving perspective.

The problem is just that a Ctrl keypress happens to convert switch-to-tab results (no URL) into history results (with URL), which instantaneously force them to start needing a second line, which makes them taller & unfortunately causes a layout shift for all of the following content, which is not great from a UX perspective.

Regression range:
Last good revision: 3c08edf74d039af79f9daad8ff5b57ffb64fdab6 (2019-12-03)
First bad revision: 32f84899fc000d95337a25c14a27470d0c52e3ee (2019-12-04)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c08edf74d039af79f9daad8ff5b57ffb64fdab6&tochange=32f84899fc000d95337a25c14a27470d0c52e3ee

Before this^ range, the autocomplete popup just always displays the URL to the right of the page-title (even when there's hardly any space), which is obviously-not-great.
After this range, we use the url-on-second-line layout when your address bar is sufficiently skinny, which makes us susceptible to this layout-shift issue.

Here's a screencast showing how this looks in a Nightly from a few days after the regression range quoted above. (essentially the same issue, though with an earlier theme)

(In reply to Daniel Holbert [:dholbert] from comment #4)

I suspect the behavior here might sort-of be intended-behavior -- i.e. we do seem to intentionally make the autocomplete popup-entries not-as-tall if they're not showing a second line (with the URL), which is nice from a space-saving perspective.

The expected behavior is changing a switch to tab to a normal url, SHIFT and CTRL can indeed be used as override modifiers on the urlbar results, for example if you want to reopen a tab that is already opened.
This problem is known, and we usually considered it a low priority. Maybe the original bug was closed as incomplete. The move from two lines to single line is related to the different UX of those entries, so the fix would be to change the design so that switch to tab takes 2 lines instead of one. This probably also affects Remote tabs.

Another alternative would be to remove this undiscoverable override, and rather provide a button... We are introducing a per-result menu that could be used for that scope, for Tab results it may provide a Open in new Tab option. Other browsers are indeed providing buttons rather than undiscoverable modifiers.