2059578 - Find in Page textbox border and focus-outline is thicker on the rounded sides, as compared to top/bottom, with Nova enabled

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot when textbox has focus (note thicker focus-online on sides vs. top/bottom)

STR:

1. Ctrl+F
2. Look at the textbox where you'd type your search term.
3. Press "Tab" so the textbox loses focus. Look at it again.

ACTUAL RESULTS:
In step 2 (when the textbox has focus), its focus-outline is noticeably thicker on the sides vs. on the top/bottom.
In step 3 (when the textbox lacks focus), it's got a thick border on the sides vs. no border on the top/bottom.

EXPECTED RESULTS:
Consistent thickness for focus outline and border.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot when textbox lacks focus (note border is present sides, vs. absent on top/bottom)

Comment 2

[Daniel Holbert [:dholbert]]

I'm using Nightly 155.0a1 (2026-07-28) (64-bit) on Ubuntu 26.04, on a system with 100% display scaling factor (i.e. no HiDPI) in case that matters.

Comment 3

[Stephen Thompson [:sthompson]]

Looks like some kind of clipping. Thanks for reporting. I'll mark this as Linux-only for now since I can't reproduce on macOS.

Comment 4

[Daniel Holbert [:dholbert]]

Thanks. I can't repro on Windows either; so it does seem Linux-only, indeed.

Comment 5

[Daniel Holbert [:dholbert]]

Indeed, it looks like this is overflow + clipping, inside of a fixed-size container.

If I use Browser Toolbox to inspect the findbar here, and I increase the height of the input element, then it overflows even more (and the findbar does not grow to contain its taller height).

The issue seems to be that we have a hardcoded 32px height on <div class="findbar-container":
https://searchfox.org/firefox-main/rev/7d438b99e58d16388e4327f2460d14ad4c8be075/toolkit/themes/shared/findbar.css#8,10,67,69,71

xul|findbar {
...
  --findbar-container-height: 32px;
...
.findbar-container {
...
  overflow-inline: hidden; /* Ensures the close button stays visible. */
...
  height: var(--findbar-container-height);

That 32px height is not quite tall enough to hold the textfield (the input element), which devtools tells me is 33.2667px tall on my system.
So: that overflow gets clipped, due to the overflow-y: auto that gets implicitly added by virtue of us setting overflow-inline: hidden here.

Comment 6

[Daniel Holbert [:dholbert]]

In contrast: if I disable nova, then we've got the same tree structure, but the heights are smaller and the container is taller than the textfield.

Specifically, with Nova disabled:

• var(--findbar-container-height) is 28px
• The textfield is 24px tall (that's its border-box height)
• So the textfield fits in the container without overflowing.

Comment 7

[Daniel Holbert [:dholbert]]

And it looks like the key difference between traditional vs. nova is the padding on the input element.

• Without nova, this textfield has 2px of padding-top and padding-bottom, for a total of 4px vertical padding on this input element. (source reference)
• With nova, this textfield instead has padding: var(--space-small); which is 0.5rem, for a total of 1rem of vertical padding on this input element. (source reference)
• On Ubuntu, 1rem is 14.6719px, in our UI. (This comes from font: message-box specified on the root element, which has a platform-dependent font-size -- 11px on macOS, 12px on Windows, 14.6719px on Ubuntu, as I observed in bug 2052316.)

So: on Ubuntu, Nova is adding +10.67px to the vertical padding on this textfield, which (combined with some other small tweaks) is why this element gets roughly 10px taller (going from 24px to 33.3px tall)

But nova is only adding +4px to the container size here (28px vs 32px). So that's why there's overflow.

We should either increase the container size by a few pixels, or (recognizing the dependence on rem sizes here), perhaps we should make it a calc expression that's some pixel value plus 1rem to precisely account for the padding that we know that we're sizing to fit (regardless of platform).

Comment 8

[Daniel Holbert [:dholbert]]

Or maybe better, we could specify a hardcoded smaller padding value for .findbar-textbox in findbar.css, to match the hardcoded smaller padding we've got there for the nova-disabled case.

e.g. this works for me:

padding-block: 0.4rem;

Or this:

padding-block: var(--space-xsmall);

(which is 0.25rem)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: Bug 2059578: Use smaller-than-default block-axis padding for findbar textfield, to avoid overflow. r?#desktop-theme-reviewers

In frontend code, our default vertical padding on a textfield is 0.5rem, which
is between 5-8px depending on platform.

With nova disabled, we instead use 2px of vertical padding on this findbar
textfield (from the padding decl in the pref-guarded CSS below the spot that
this patch is touching).

Let's use a smaller amount of padding, with the --space-xsmall design token
(0.25rem). This is still larger than the 2px that we were using pre-nova, but
it's small enough to avoid overflow on Ubuntu.

Comment 10

[Daniel Holbert [:dholbert]]

I posted screenshots before/after the patch on Ubuntu in phabricator.

For other platforms, this try run should have patched artifact builds for testing soon:
https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=74091

Comment 11

[Daniel Holbert [:dholbert]]

Good news -- I just tested this patch on macOS and it doesn't change the behavior at all there (which is good, because things were already fine there, per comment 3). There's literally no visual change.

On macOS, the textfield is 28px tall, regardless of the padding -- that comes from the min-height decl, here:
https://searchfox.org/firefox-main/rev/7d438b99e58d16388e4327f2460d14ad4c8be075/toolkit/themes/shared/findbar.css#82,86,99

.findbar-textbox {
...
  min-height: 28px;
...
  box-sizing: border-box;

That min-height, combined with the box-sizing: border-box and the fact that content gets vertically centered in a textfield, means that the exact choice of padding doesn't impact the sizing or layout at all here, for sufficiently small padding values (as long as the padding is the same on the top and bottom so that it doesn't throw off the vertical centering). The padding only starts making a difference when it gets big enough that it makes the textfield larger than that min-height, as happened (to too-great of an extent) on Linux.

Comment 12

[Daniel Holbert [:dholbert]]

On Windows 11, there's a very slight visual change, but it's not really user-perceptible. (I've attached screenshots in phabricator.)

Without this patch, the findbar's textbox is 30px tall.
With this patch, the findbar's textbox is 28px tall (2px smaller)

(This patch's reduction in padding makes the textbox intrinsically smaller; but then, the min-height: 28px that I quoted in comment 11 kicks in and just clamps us to that size, matching the size on macOS.)

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

For other platforms, this try run should have patched artifact builds for testing soon:
[...]

Sorry, I flubbed my Try run there - that try run did not have the patch applied. Here's a try run that does have the patch applied:
https://treeherder.mozilla.org/jobs?repo=try&revision=ef7d67b159944a0203b69ae7e7494a4fcc68cfea

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/28dd3e115426
https://hg.mozilla.org/integration/autoland/rev/c47a67c8b3b7
Use smaller-than-default block-axis padding for findbar textfield, to avoid overflow. r=desktop-theme-reviewers,hjones

Comment 14

[Sandor Molnar[:smolnar]]

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

Comment 15

[Sarah Clements [:sclements] | PTO until Sept 8th]

Thanks a lot for the help with this!