2050821 - Text input is not centered in the address bar and search bar

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Adrian Florinescu [:aflorinescu]]

Attachment: nova_search_string.jpg

Notes

• Please see the attached screenshot for more details.

Found in

• Nightly 154.0a1;

Affected versions

• Nightly 154.0a1;

Tested platforms

• Ubuntu 22;
• Windows 10;
• macOS 15;

Affected platforms

• Ubuntu 22;
• Windows 10;
• macOS 15;

Steps to reproduce

1. Launch Firefox.
2. Input gggggg as a search string in both urlbar and search bar
3. Observe the string placement and visibility

Expected result

• The search string is properly positioned in the address bar / search bar and fully visible

Actual result

• The search string is not properly position in the address bar / search bar and fully visible and it is truncated

Regression range

• Not a regression.

Comment 1

[Drew Willcoxon :adw (Away July 17–July 24)]

Thanks, let's separate the two potential problems:

1. The input text is cut off on its bottom edge
2. The input text isn't vertically centered in the input

Problem 1: I can't reproduce that on Windows or Mac but can imagine how it might happen. Are there any other STR like unusual scaling or anything? Are you using a high-DPI display (i.e. 2x) or a low 1x display?

Does it happen when Nova is disabled on the latest build? If so, does it happen in older Firefox versions?

Problem 2: There's actually the same number of pixels above and below the text in Nova as there is in Proton [1]. In Nova the input has an internal outline, which can make the text look slightly closer to the edge of the input than in Proton, but it's symmetrical.

I tested on Windows and Mac using the latest build for Nova and older Firefox versions for Proton, before we started making Nova changes.

[1] Actually on Windows, I measured a half-pixel difference between Nova and Proton above the text. I'm using a high-DPI Mac display and running Windows in a VM.

Comment 2

[Adrian Florinescu [:aflorinescu]]

Attachment: addressbar ok, searchbar broken

No unusual scaling. I'm using a standard 1920×1080 monitor with Windows 11 display scaling set to 100% (1× DPI). From what I know, the other test machines involved into the testing were also regular machines, with no unusual scaling.

Tested on win 11 and mac 13 with several versions of Nightly 154 and I think that we are looking at a highly intermittent issue. I think the two problems are actualy the same problem for both addressbar and search bar - I could reproduce in some manner with nova pref'd off and pref'd on -> maybe side effect from 1998985?

Unfortunately, this is a highly intermittent issue and I couldn't figure out a specific set of reduced STR to reproduce consistently. I noticed that my personal profile which has alot of bookmark structures (with always show bookmarks), vertical tabs and a bunch of addons icons clobbering the Toolbar does seem to reproduce more often than a brand new clean profile.

Note:
In the attached screenshot, the address bar is fine but the search bar reproduces the issue.

Comment 3

[Drew Willcoxon :adw (Away July 17–July 24)]

(In reply to Adrian Florinescu [:aflorinescu] from comment #2)

I could reproduce in some manner with nova pref'd off and pref'd on

That's very interesting, thanks. It suggests that this might be an old bug unrelated to our Nova work. When it happened while Nova was disabled, do you remember if you started Firefox with Nova disabled? Or did you have Nova enabled at some point while Firefox was running, and then you turned it off, and then it started happening?

maybe side effect from 1998985?

At a quick glance, I don't think so, but I could be wrong.

This is a very visible bug, so if you're able to spend some time trying to nail down STR, I'd appreciate it! Some ideas for things to try (in combination with each other):

• Toggle off/on browser.nova.enabled
• Start Firefox with different values for browser.nova.enabled
• Add/remove the search bar to the toolbar
• Open new windows
• Toggle on/off the bookmarks toolbar
• Trigger an infobar/infobox (see comment 6)

Comment 4

[Mark Banner (:standard8)]

NI to Adrian for the previous comment.

Comment 5

[Adrian Florinescu [:aflorinescu]]

(In reply to Drew Willcoxon :adw from comment #3)

This is a very visible bug, so if you're able to spend some time trying to nail down STR ...

I've gave it a bit more time, with the unfortunate outcome that I wasn't able to advance anywhere. The reproducibility % seems to go higher as you start customizing the profile - e.g switching themes, adding search bar, toolbar elements, etc. Idle time, full screens, resizing seem to also count to entering the state in which it can reproduce, although the method is extremely intermittent and unreliable. Switching nova on/off doesn't really seem to trigger it, although in some cases it did make the difference.

Looking back at when we logged the bug, the bug was reproduced on several machines and all these machines were runing the address bar/search bar Nova suite, which was basically putting the above listed stress on the addressbar and searchbar.

Since I'm going to be out next week on PTO, let's have some new ideas poke at it. @cbaica, @oardelean, if time allows it, can you give it a try?

Comment 6

[Drew Willcoxon :adw (Away July 17–July 24)]

Attachment: infobar screenshot (no bug)

Thanks Adrian!

I was testing something unrelated on Windows and noticed the entire urlbar was misplaced somehow, it was just below the toolbar. I wasn't able to trigger it again but wonder if it's related. I think the infobar was visible at the time. That shouldn't matter at all, but since it's part of the toolbar, maybe it's triggering a bug. It was probably the infobar that's shown after you restart once with a new profile, the one that says "Open previous tabs?", but the particular contents don't matter.

In your first screenshot the infobar is not visible, but it might have been closed before you took it? Anyway, I'm only guessing it might be related.

I'll attach a screenshot of the infobar just so it's clear what I'm talking about. (It does not show the bug and Nova is disabled, but that doesn't matter)

Comment 7

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Attachment: croppedinputnovaoff.png

Hi!

We tested and investigated a combination of scenarios in which we tried to isolate concise STR for the cropped input issue. On my end, I managed to reproduce using a fresh Nightly profile.
I managed to isolate a regression range using mozregression on the machine I could reproduce reliably.
The regression range is far newer than the date this bug was logged, and it might be a different issue altogether that the one reported here, albeit very similar.

• last good: 2026-07-07;
• first bad: 2026-07-08;
• pushlog: https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=26c8191dfbef7a6ca4570a847a2924d45309951e&tochange=79a3125a8baae1d42cc2b98eedb448472eb3bc42
• potential regressor: bug 2050692

We can log a new bug for this particular regression range if it's preferable, as it seems to only affect Windows 11 at the moment.

Also, please note that we only managed to reproduce this particular scenario on a single Windows 11 machine. We were unsuccessful in reproducing on macOS 13 or a different Windows 11 desktop.

• Interestingly, toggling browser.nova.enabled on true will reproduce the issue only on maximised windows. Narrower browser windows do not crop the input. This is only with Nova enabled, however. With Nova disabled the browser window size seems inconsequential. This might only be applicable for the affected Win 11.

Windows 11 affected specs:

• Scale: 125%(recommended)
• Display resolution: 1920x1080(recommended)
• Display orientation: Landscape

Later edit: We also managed to reproduce with a fresh Firefox Nightly profile on Ubuntu 24.

Please let us know if you would prefer us to file a new bug for the scenario mentioned in this comment particularly, or track the issue here further.

Thank you!

Comment 8

[Drew Willcoxon :adw (Away July 17–July 24)]

Thanks, unfortunately I still can't reproduce it on Windows or Ubuntu. Are you able to reproduce it reliably on Windows with the info in your previous comment? Are there any other specific STR? Could you make a screen recording showing all the steps?

(In reply to Ardelean Oana, Desktop Test Engineering [:oardelean] from comment #7)

We can log a new bug for this particular regression range if it's preferable, as it seems to only affect Windows 11 at the moment.

Yes, could you please? Since this bug happened before bug 2050692 yet mozregression pointed to that bug, it would be best to have two separate bugs on file. And it might help to have graphics engineers take a look.

Your screenshot shows Proton. It's hard to say if that's due to bug 2050692 or urlbar-specific changes we've been making for Nova or it's just always been a bug that we didn't find before.

Comment 9

[Drew Willcoxon :adw (Away July 17–July 24)]

Attachment: Bug 2050821 - Make the urlbar input stretch its full visual height.

There's some discussion in the bug about a graphics issue, but the likeliest
explanation is that this is a front-end problem. This patch makes a couple of
changes that might fix it, but I can't say for sure since I can't reproduce it.

Everything in the urlbar has a height that stretches the entire visual height of
the input except for .urlbar-input-box. It's noticeably smaller. Setting
height: 100% fixes that.

Also, .urlbar-input-container has block padding that isn't necessary. The
height of all the non-input children is set with --urlbar-basic-component-size
[1]. The block padding prevents .urlbar-input-box from taking up the full
visual height of the input, so I removed it.

I tested this on all three platforms and didn't see any regressions.

[1] https://searchfox.org/firefox-main/search?q=--urlbar-basic-component-size&case=false&regexp=false&path=

Comment 12

[Drew Willcoxon :adw (Away July 17–July 24)]

Removing "[Nova]" from the summary since it looks like this can happen in Proton too, possibly due to recent Nova work that affected Proton too.

Comment 13

[Drew Willcoxon :adw (Away July 17–July 24)]

(In reply to Drew Willcoxon :adw from comment #8)

Could you make a screen recording showing all the steps?

There's a video in bug 2055145 so never mind! :-) It really does happen immediately on startup, no further STR required.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d1ad3aceadb0
https://hg.mozilla.org/integration/autoland/rev/e036f18154dd
Make the urlbar input stretch its full visual height. r=dao,desktop-theme-reviewers,urlbar-reviewers

Comment 15

[amarc]

https://hg.mozilla.org/mozilla-central/rev/e036f18154dd

Comment 16

[Drew Willcoxon :adw (Away July 17–July 24)]

Hopefully this is fixed now! The graphics patch in bug 2055145 probably isn't required to fix this, it's more like extra insurance.