1641602 - Strange input behavior. "min-width" based on font-size

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Vladimir Porotnikov]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.132 Safari/537.36

Steps to reproduce:

Reproduced case:
https://codepen.io/zerdox-x/pen/VwvJbBN

Actual results:

On 500px screen width I can't see span content.

Expected results:

In all the rest browsers (safari, chrome, etc) I can still see this span.
Expected to see span as in other browsers.
How do I solve this 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

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case from reporter.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

You can set min-width: 0 on the input. Not sure whether this is a bug though. It seems that if you remove width: 100% on the input in Chrome, it becomes bigger, wat.

Comment 4

[Vladimir Porotnikov]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

You can set min-width: 0 on the input. Not sure whether this is a bug though. It seems that if you remove width: 100% on the input in Chrome, it becomes bigger, wat.

min-width: 0 really helps me!
I tried to set min-width: 0 inline in devtools and then went to code, changed font-size to check if min-width: 0 works but when I saved file, HMR resets all unsaved inline styles so I thought that min: width: 0 can't help me. That's dumb.. my fault.

And now both Firefox and Chrome look the same. Thank you very much! I'm going to add this line of code to my reset.css

Comment 5

[Cameron McCormack (:heycam)]

I'm not sure if I can find any spec text that justifies the automatic minimum size being the same as the size that we're meant to use for a generated presentational hint for the 'width' property: https://html.spec.whatwg.org/#the-input-element-as-a-text-entry-widget

So I'm wondering if nsTextControlFrame::GetMinISize should be returning just the border/padding values of the widget?

Comment 6

[Daniel Holbert [:dholbert]]

This is https://bugs.chromium.org/p/chromium/issues/detail?id=581545 and is a Chrome bug, not a Firefox bug.

Chrome is basically behaving as if the input element had min-width:0 here, specifically when it has a percent-valued size. And this is just a Chrome quirk/bug.

(If that's the behavior you want, though -- and it sounds like it is -- then indeed, you want to add min-width:0.)

A bit more detail for background/understandability: this is all about the "automatic minimum size" of flex items. (Note that the input is a flex item in this example.) The text on that is here: https://drafts.csswg.org/css-flexbox-1/#min-size-auto

Some facts that inform the behavior here:

• The default min-width value is auto, and for a flex item, it typically resolves to the element's min-content size (which is, roughly, the size that the element would take on if you placed it in a 0-width block, like in this example (where Chrome and Firefox agree, with minor differences probably due to e.g. font selection & platform-specific widget-behavior quirks):

data:text/html,<div style="width:0;border:1px solid red"><input style="font-size: 40px">

• If the flex item has an explicit width[1] or max-width[2] value (for a horizontal flexbox), then that sets an upper-limit for what the min-width:auto value will resolve to.

• So in your testcase, the input element wants to refuse to be any smaller than the size that it has in my data:text/html snippet above. But it'll let itself be clamped at the width of the flex container (in Firefox), due to the explicit width:100% on the input element (which resolves against the container and gives it an upper-bound for how large the input's automatic minimum size will resolve to). Note that if you use a smaller percent, e.g. 50%, then it'll get clamped at that smaller size. You probably don't want that, but it's useful to understand what's going on.

• And in Chrome, they clamp it more severely due to a known Chrome bug, linked above.

[1] The specified-width clamping happens via the specified size suggestion in the spec
[2] The specified-max-width clamping happens via the "...further clamped by the max main size property if that is definite" snippet in the spec, at the end of the "content size suggestion" section.