input overflows right margin in flex box, margin ignored, regression
Categories
(Core :: Layout: Flexbox, defect)
Tracking
()
People
(Reporter: vtwintiger, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
13.61 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.4
Firefox for Android
Steps to reproduce:
The volume slider input tag (id="plyr-volume-*") in the audio player on page https://berean-biblechurch.org/live-stream/ now overflows the parent flex box on the right end, where it has a margin of 5px. In 82.0.3 it looked correct, on 83.0 it is broken.
This is seen on the desktop application, and it is seen in the mobile (Android) application but it is not at bad on mobile.
Actual results:
The volume slider input tag (id="plyr-volume-*") in the audio player on page https://berean-biblechurch.org/live-stream/ now overflows the parent flex box on the right end, where it has a margin of 5px. In 82.0.3 it looked correct, on 83.0 it is broken.
Expected results:
The input tag contents should not overflow the parent. It should honor the right margin.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•4 years ago
|
||
This doesn't seem to reproduce for me on macOS, but it does on Linux, where mozregression blames bug 1672462.
(Looks a lot like bug 1679547, which was dup'd to bug 1585485. Ting-Yu, maybe you can check if this is the same issue?)
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Yes, this is also bug 1585485. The volume slider <input>
has width:100%
and cannot shrink below its min-content size.
We calculate <input>
's min-content size in nsTextControlFrame::CalcIntrinsicSize(). The size depends on the default number of characters in the <input>
and the character's width, so it's not surprised that this bug can only reproduce on certain platform.
Comment 4•4 years ago
|
||
So I think Justin should try a min-width: 0px or min-width: 5px or something on the <input>
?
Comment 5•4 years ago
|
||
(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #3)
Yes, this is also bug 1585485. The volume slider
<input>
haswidth:100%
and cannot shrink below its min-content size.We calculate
<input>
's min-content size in nsTextControlFrame::CalcIntrinsicSize(). The size depends on the default number of characters in the<input>
and the character's width, so it's not surprised that this bug can only reproduce on certain platform.
This isn't an nsTextControlFrame, it's nsRangeFrame. From a look at the source, I think what we're actually seeing here is the intrinsic main-axis size of 12em, which (in the absence of CSS that says otherwise) gets used as the basis of both GetPrefISize() and GetMinISize().
Setting an explicit smaller min-width on the <input>
will indeed avoid the problem, anyhow.
(In reply to dgrogan(chrome) from comment #4)
So I think Justin should try a min-width: 0px or min-width: 5px or something on the
<input>
?
Thanks for the work-around info. I see that I can also set the width property to less than 100% and get the desired result.
I don't see how this can be a duplicate of a year old bug when this problem was seen just recently.
Comment 8•4 years ago
|
||
I don't see how this can be a duplicate of a year old bug when this problem was seen just recently.
Sometimes fixing a bug can uncover the wallpaper of another old bug. This is indeed a duplicate of bug 1585485, and the correct fix to it just landed there. On the latest Firefox Nightly 86.0a1 (2020-12-18), the volume slider <input>
should shrink even if it has width:100%
Description
•