1638107 - Input elements bleed over into surrounding elements on pages

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[David Rankin]

Attachment: inputs_bleed_over_into_other_elements.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Visiting virtually any page with form input dialog, the input dialog is twice the normal size causing it to bleed over into other elements on the page. I am using the default Gtk+3 Adwaita theme.

Take for example the National Weather Service Southern Plains RADAR page: https://radar.weather.gov/Conus/southplains.php

Actual results:

If you look at the input for "City, St" and the associated "Go" button, the input is twice the size of the "Go" button (both were the same size in all Gtk+2 versions of FF) and both bleed over into the element below.

Expected results:

The input height should be the same size as the "Go" button and both should fit in the blue element above the RADAR image. I have used this page for many years, and these always fit perfectly until ? FF 52? 60? -- whatever version coincided with the Gtk+2/3 change. I am using the default Gtk+3 theme Adwaita. After a year plus, this issue should be fixed. It doesn't just effect the NWS site, that is just an example that I went to today that triggered the filing of this bug. It happens to virtually ever input (and tooltip generated from the title= property). They are oversized. This appears to be the result of improper border, padding and margin property defaults with the CSS model that the newer Firefox builds rely on.

I have used Firefox since it was introduced and there were never problems with element rendering to the extent there are now. There need to be proper defaults, especially in the default Adwaita and/or Firefox CSS model so that normal HTML elements are sized properly and do not bleed over into surrounding elements.

The attached screenshot for the URL shows the problem.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Screenshot from Firefox 76.png

Thanks for the report.

I believe the extra height of the <input> comes from gtk theme. I see the same result on Firefox 76 installed from my linux distribution (Linux mint 19.3). But if I go to url bar -> type "about:config" -> search for widget.content.gtk-theme-override, and change the value from # to empty. The extra height is gone. (Attached a screenshot for reference.)

The stock Firefox downloaded from https://www.mozilla.org/en-US/firefox/new/ doesn't have this issue, fwiw.

Comment 3

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Emilio, do you know what is the correct approach to fix layout different on widget themed form controls? Do we have plan to enable widget.disable-native-theme-for-content globally?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

You're right this is a GTK bug... Non-native theme is not going to happen very soon I fear. But I think we can fix this without too much trouble. I have a patch that seems to behave nicely here.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1638107 - Scale gtk entry min height by the font-size for smaller-than-default font-sizes. r=stransky,karlt

This makes inputs not remain very big at small font sizes, while keeping
the right native appearance at normal / large font sizes, which is
needed for compat both with other themes and other browsers.

Comment 6

[Karl Tomlinson (:karlt)]

It's actually the button that is less consistent with native rendering here, which can be seen by adjusting GTK's default font size at gtk3-widget-factory -> Menu -> Inspector -> Visual -> Font.

However, I think there may be a case to argue that the web has a greater variety of sizes than typical GTK apps and so we should ignore some of the minimum sizes.

Comment 7

[Karl Tomlinson (:karlt)]

Attachment: Rendering data:text/html,<input%20type=text%20value="entry"><button>button when ignoring min-height with gtk-font-name=DejaVu Sans 10

data:text/html,<input%20type=text%20value="entry"><button>button

At typical system font sizes, this is tighter than the native box.

Comment 8

[Karl Tomlinson (:karlt)]

The min-height was included here due to lack of top/bottom padding in the Adwaita theme. That is still the case, but I see there is a top/bottom border at least. The use of min-height in Adwaita is odd because it is ignored at larger system font sizes.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/68778a6a157b
Scale gtk entry min height by the font-size for smaller-than-default font-sizes. r=karlt

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9b9ee1004f3
Relax a fuzzy annotation a bit more.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e71fbfcb8d96
css-simple-styling.html is two pixels more wrong in WR.

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/68778a6a157b
https://hg.mozilla.org/mozilla-central/rev/b9b9ee1004f3
https://hg.mozilla.org/mozilla-central/rev/e71fbfcb8d96