1674431 - Spin button appearance makes text entry unreadable, <input type="number"> covered by wide buttons

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Attachment: Non-native theme

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Attachment: Native theme

This is an example of a webcompat problem from non-native theming: the new theme makes the text unreadable.

The site is runalyze.com, though there's probably no simple STR to get this particular dialog without an account with data etc.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

data:text/html,<input type="number" style="width: 4em" value="1234"> might be a reasonable enough test-case.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

The original HTML looks roughly like:
<td class="zone-cell-from"><span class="input-with-unit"> <input type="number" id="sport_zones_settings_5_from" name="sport_zones[settings][5][from]" class="small-size" value="354" readonly=""> <label for="sport_zones_settings_5_from" class="input-unit">W</label></span></td>

Comment 4

[Stephen A Pohl [:spohl]]

Emilio, do you have a recommended way of addressing this? Should we widen the control by the extra space required by the spinner buttons? I also couldn't quite figure out how to recreate a control with the "W" on the right of the spinner buttons, although I'm not sure that it will be relevant here.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

You can't really do that if the author specifies the width of the control. I think for cases like comment 2 we need to shrink the buttons, at least conditionally. Gian-Carlo, can you inspect the number input and see if they're explicitly specifying width / max-width?

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Attachment: CSS from Devtools

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Attachment: devtoolscss.txt

CSS in attachment.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Yeah, so they're hardcoding width: 44px, so it's basically comment 2, and we can't really grow the input.

Comment 9

[Stephen A Pohl [:spohl]]

I believe that due to the changes to the sizes of many of our form controls we are bound to run into these kinds of compatibility issues. Is there a good rule of thumb that we can follow to determine when we need revert to the old sizing, and when to simply live with the breakage and expect web authors to address it on their end? As unfortunate as this is, it seems to me that as soon as we were willing to change the sizing of our default form controls, we implicitly agreed to live with some level of breakage.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

I guess we can track these off a metabug or something, and see how often we find these. We should also judge the severity of the issue, for example this one seems somewhat serious because it can prevent the text in the input from being readable...

Comment 11

[Chris Peterson [:cpeterson]]

Tracking non-native theming bugs for Fission Beta milestone (M7).

Comment 12

[Markus Stange [:mstange]]

I would suggest picking a smaller width for the buttons and sticking with it, for consistency. I would take this bug as evidence that the larger width is not web compatible.

Comment 13

[Markus Stange [:mstange]]

Attachment: screenshot on gutekueche.at

Here's another instance of this problem: https://www.gutekueche.at/spekulatius-rezept-24305

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Agreed.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Attachment: Screenshot with patch.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1674431 - Size the non-native theme number spinner buttons more sensibly. r=mstange,spohl

Use the same width as the select arrow button makes sense to me and
fixes all the reported problems so far.

Also tweak the sizing / painting to take less height since these have a
background, so stuff like:

<input type=number style="height: 100px">

Looks super ugly otherwise.

The new polygon coordinates are the result of scaling by 1.5 and
centering vertically the arrow, which gives the same visual effect for
the regular input without margin / padding, but prevents the issue
described above with too-tall inputs or inputs with lots of padding.

We might want to shrink them a bit more if needed, but I think this is
alright. For reference, Chrome uses 15px, but we remove the inline-end
padding by default so we compensate a bit that way.

If we don't like how this looks when the author specifies padding on the
input (see comment 13 for example), we might want to reconsider the
design so that the spinners look good with padding, but that's a
different task completely.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a95d10a2de4d
Size the non-native theme number spinner buttons more sensibly. r=spohl

Comment 18

[Andreea Pavel [:apavel]]

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