1829588 - Google's search bar is taller than expected in Firefox with "always show scrollbars" (the default on Windows), due to dependence on height of <textarea rows=1> where Firefox reserves space for scrollbar

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Carl]

Attachment: A screenshot of the issue where the search bar is too wide.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

I do not know. I have not installed many extensions and the issue only work with Firefox.

Actual results:

Firefox displays the Google search bar way too wide compared to other browsers like Chrome and Edge.

Expected results:

The Google search bar should display normally.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Search' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alin Ilea, Desktop Test Engineering]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Hi,
Thanks for opening this ticket, I will set it as NEW and wait for the developer's opinion about it. Indeed, this is not reproducible in Chrome and I can reproduce it in Fx67 as well.
If this is not the correct component, feel free to change it to a more appropriate one.

Thanks for the report.

Comment 3

[Daniel Holbert [:dholbert]]

This is reproducible on Linux as well if you enable the "always show scrollbars" preference.

Google seems to be using <textarea rows=1> here (in the initial rendering at least), and we're rendering that component a bit taller than they expect. With traditional (non-overlay) scrollbars, Firefox makes a <textarea> roughly one line taller than its rows attribute, to reserve some space for its horizontal scrollbar (if we end up needing to show it, per the overflow:auto use-scrollbars-if-you-need-them styling on textarea elements).

In contrast, Chrome seems to reserve no space at all for a horizontal scrollbar, unless you specify word-wrap:normal (to prevent automatic linebreaking) in which case they match us.

In any case: they seem to be depending on the former behavior (where a textarea only renders ~1em tall) for proper sizing in this case, which is unfortunate.... One workaround would be to add overflow-x: hidden here to explicitly suppress that scrollbar, since I think they're not intending for this searchbox to be able to overflow horizontally? (They do have explicit white-space: pre-line which should prevent horizontal overflow, I think.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (comparing some textarea rows=1 scenarios)

Here's a reduced testcase to demonstrate the behavior differences here a bit. When viewing this in Firefox, ensure you have "Always show scrollbars" checked in the Firefox preferences.

The first textarea is essentially what the Google search page uses in its initial rendering right now -- a textarea with rows=1. Firefox with always-show-scrollbars renders it tall enough to show 2 lines of text -- or rather 1 line and 1 possible-scrollbar -- as noted above.

The second textarea is a slight variant where I've added word-wrap:normal to make it more-possible for there to be horizontal overflow (though in this case there isn't any such overflow). This makes Chrome agree with us and render it as tall enough to show 2 lines of text (reserving some space for a hoirzontal scrollbar), which is an interesting inconsistency on their part when comparing these first two textareas.

The third and fourth textareas are the same as the first and second but with overflow-x: hidden added (which suppresses the horizontal scrollbar and makes it reliably render as only 1 line tall); that's my strawman suggested-fix that we might ask Google to consider adding here for now. This should be fine as long as they ensure there's no actual horizontal overflow, which I think they do.

Comment 5

[Daniel Holbert [:dholbert]]

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

The second textarea is a slight variant where I've added word-wrap:normal to make it more-possible for there to be horizontal overflow (though in this case there isn't any such overflow). This makes Chrome agree with us and render it as tall enough to show 2 lines of text (reserving some space for a hoirzontal scrollbar), which is an interesting inconsistency on their part when comparing these first two textareas.

Safari matches Chrome on this, for what it's worth. I'll spin off a bug [EDIT: spun off as bug 1830576] to consider changing our sizing behavior on this (might require a bit more investigation to nail down the precisely correct conditions; ideally we should get this webcompat issue addressed on Google's end in the meantime, since a hypothetical textarea sizing change would be fiddly & take some time to make it through the release channels).

Comment 6

[Daniel Holbert [:dholbert]]

I sent a message to some Google folks about this. Given that we've received two bug reports about this same issue (this bug here and also bug 1829994 "Search box is a bit too thick") within a week, I'm guessing their design may have changed recently, and users are noticing.

Comment 7

[Daniel Holbert [:dholbert]]

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

I sent a message to some Google folks about this.

Heard back from them; they're investigating a fix on their end.

Comment 8

[Daniel Holbert [:dholbert]]

Actually it looks like they fixed it already! I can't reproduce anymore.

Comment 9

[Daniel Holbert [:dholbert]]

Hmm, actually I can still reproduce if I click the very bottom of the search box (granting focus to some component, I think).

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug still reproducing on 5/3 depending on focus state (e.g. when you click near bottom of search field)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the remaining issue (with red border added around textarea)

Here's a screencast with devtools open to show the remaining issue. I've added a red border to the textarea to make it easier to see when its height changes.

Google has now added overflow-x: hidden to this textarea by default, which does avoid the problem per comment 5; but if the user e.g. clicks the bottom of the search area, then an ancestor-div gains class="... sbfc" for some reason, which makes a more-specific rule take effect:

.sbfc textarea.gLFyf {
  white-space: pre-line;
  overflow: auto;
}

...and the overflow:auto there stomps on their workaround & makes us reserve space for the scrollbar again.

Comment 12

[Daniel Holbert [:dholbert]]

Google folks have fixed this on their side, as far as I can tell! This textarea now reliably has overflow-x: hidden regardless of how I interact with it, which is sufficient to avoid the issue.

Calling this "fixed", though please reopen if anyone can still reproduce. (in which case any repro details would be helpful)