Bootstrap: "Large select" example vertically overflows in Forms component documentation

[Chealer]

The second example in the Sizing section of the documentation of the Forms component starts with a dropdown which shows by default a "Large select" option. The bottom of this text is not visible in my Google Chrome 60, at default zoom level.

There is no problem with the 2 following selects.

[andresgalante]

Hi @Chealer, Can you send a screen capture please? I can't reproduce it

[houfio]

[andresgalante]

That's on windows, right?

[houfio]

Nope, I'm running Debian 9.

[Chealer]

Hi @andresgalante, here is a screenshot showing a worst case (each character is affected).

This is taken from Firefox 55.0 on Windows 8 at default zoom level.

[andresgalante]

@Chealer @houfio I see! that really sucks! I'll start a virtual machine and try to fix it.

Thanks a lot for reporting it and sending the screenshots

@Johann-S I think this should be labled as "bug" and "css"

[Johann-S]

Yep my bad thanks @andresgalante 👍

[andresgalante]

@Chealer Are you sure you are running beta?
This is where the height is set: https://github.com/twbs/bootstrap/blob/v4-dev/scss/_forms.scss#L172-L176

And on reboot the line-height is set to inherit

I can't reproduce the issue on browserstack with any browser, sorry 😞

IF you can guide me I can try send a PR, or you can actually send it yourself!

[Chealer]

@andresgalante, I am "running" whatever the page I linked to uses, which appears to be a beta indeed, though it is the default documentation the homepage links to.

I do not master CSS, it is hard for me to say why the display is wrong.

I even get overflow if I try with MSIE, though it is less important in this case (only some letters, as shown by houfio).

[andresgalante]

Sorry @Chealer if since I can't reproduce it I can't fix it. But this is a bug.

[Chealer]

No problem @andresgalante, thanks anyway for your diligent effort.

It should not be hard to reproduce though. I also see the issue with Chromium 60 on Debian 9.0. Only some letters are affected there (like houfio again).

[githubjeka]

Windows 10, Chrome v60.0.3112.113 (64bit)
Display 1680x1050

Edge Browser and Internet Explorer
Large is same as Default

---

To fix for me need recalucalculate height:

instead of

height: calc(2.3125rem + 2px);

[andresgalante]

@githubjeka Yeap, the bug is definitely on the height.

If I can help you to create a PR and look for the root of this variable please let me know.

[Julieng50]

The bug is not only on select element, I get the same result with input text :/
The only solution I have found for the moment is to do a :

// FIX BOOTSTRAP
input[type=text], select{
  padding-top: .4rem !important;
  padding-bottom: .45rem !important;
  line-height: 1.4 !important;
}
select {
  padding-top: .3rem !important;
  padding-left: .5rem !important;
}

Using: Windows 10 + Firefox 55.0.3 + Bootstrap 4.0.0-beta

[Borkason]

@andresgalante : Sorry @Chealer if since I can't reproduce it I can't fix it. But this is a bug.

I can reproduce this with a fresh install of Windows 10 1703 and Egde. Do you have a 4K display or something? Maybe a DPI other than 100% makes this a non-reproducible error on your side? ... just an idea ...

[andresgalante]

I have a mac :)

[Borkason]

I suspected it. You said earlier that you created a VM. Could it be possible that the VM was running with a different DPI setting than 100% on that Mac? We have an iMac 5K at work and when you spin up new VMs in Parallels, the DPI setting is adjusted so everything is not only readable by ants. Could be that this is the issue why you can't reproduce this.

Sorry that I can't be of any other help, but debugging CSS stuff is really no my thing. I am glad that I can put Bootstrap to user without any modifications to CSS where I need it :)

[jrysig]

There is definitely problem with input and select controls. You can reproduce this problem with free virtual machines from Microsoft: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Download Windows 7 with IE11 and Windows 10 with MS Edge images. Run it in VirtualBox, install latest Chrome and Firefox. Open Bootstrap 4 beta documentation https://getbootstrap.com/docs/4.0/components/forms/ and use Dev tools to change page content. Note that both images are running with 100% DPI (default) settings. You will receive:

Win 7, IE 11

Win 7, FF 55

Win 7, Chrome 61

Win 7, Chrome 61

Win10, MS Edge

[kjdion84]

This is still a big problem. Browserstack is not a reliable method for testing these things, especially when everyone who is using the most common browser on the most common OS is experiencing these issues even though you say you can't reproduce it.

[andresgalante]

Of course it is. it would be great if anyone sends a PR to fix it. I just can't reproduce it.

[kjdion84]

You can reproduce it on a Windows or Ubuntu VM.

[andresgalante]

I could, just not have the time to create a VM and make it run to fix this.

[wojtask9]

1. inputs
   Issue occurs because line-height is smaller than input "carret".
   Someone can tell that line-height is 1.25 and font size is 1rem. But not for all fonts space needed to render those fonts is the same.

2. select
   The main issue is height on "select" (select.font-control:not() ... selector)
   It is almost correct for "Arial" but not necessary for others fonts.

How to fix this?
This is really tricky and for general purpose I don't know how. Using height for "inputs" causes vertical align issues. For "selects" the same situation.

@andresgalante
Try different font-family and I believe that you can reproduce this issue

[wojtask9]

Found this https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
Maybe this help to understand issue more precisely and someone can make PR :)

[dracos]

I believe this bug was actually fixed in #23150 back in July, merged just after the beta was made. If you use bleeding edge v4-dev, the issue is not present, I think. This might be the cause of some confusion of the above comments.

[Johann-S]

your're right @dracos already fixed with our last dist files from v4-dev see : https://codepen.io/Johann-S/pen/MEpBdR

[wojtask9]

select is fixed but this bug also mention about inputs

[dracos]

You could easily create a codepen and see that the height fix of #23150 applied to all .form-control-lg including inputs. Sorry, I misread. If there is a different issue, then that should be a new issue, not attached to this one.

[wojtask9]

@dracos
You are right. Sorry for noise.

[kjdion84]

Please stop closing issues that aren't fixed properly. The issue still exists for even normal selects in Chrome on Windows. Characters are still being cut off as the text is still not centered vertically properly.

Proof fiddle: https://codepen.io/anon/pen/WZpPPp
Proof image:

[dracos]

The large select in your screenshot has nothing cut off, which is what this issue is about?
Nothing before in this issue has talked about the default select being cut off.

P.S. I recommend in CodePen you use the Settings -> CSS -> add https://cdn.rawgit.com/twbs/bootstrap/27a015ba15fa63d5c311c644c5c0efc2a2868fe7/dist/css/bootstrap.min.css as a CSS rather than copy+paste all of Bootstrap CSS into the CSS box :)

[Johann-S]

See my Codepen @dracos which use our last dist file : https://codepen.io/Johann-S/pen/MEpBdR

[dracos]

Yes I agree the text is cut off the bottom of the normal select, I can see that myself in IE. But this ticket and the screenshots above was about the -lg overhang, which was fixed by the PR I gave. It took me long enough to track that down that fix, and having git issues contain many overlapping different bugs does not help matters, witness the many confused tickets in this area.

[dracos]

At least #23347 is a generic ticket for Windows form issue, and so might as well be used for that issue, rather than this one which is definitely fixed!

[Johann-S]

yep that's right :+1: so close and I won't reopen that issue, track #23347 please

[kjdion84]

The -lg and normal selects should not be treated as separate issues. They conform to the same element, the only thing different is the sizing. Creating a solution that requires individual changes to each sub-style is not efficient in any way, ESPECIALLY considering we are now using rem. There should be a solution which, when applied to select.form-control, will scale efficiently no matter what sizing changes are made in regards to font/padding.

[dracos]

I agree. The issue of this issue, as it was described and followed up, was that -lg was using 2.3125rem rather than 2.875rem for its height, which was a plain bug due to it using the wrong variable, and that was fixed in https://github.com/twbs/bootstrap/pull/23150. #23347 seems like a more appropriate issue to track the general issue to do with sizing, given that the obvious issue with -lg has been fixed. I hope that explains thing properly, as nothing I've said is contradicting what you are saying.

[Chealer]

Regarding issue tracking, it is poor practice to use a report of several issues to track an important issue. Someone looking for a report of this bug will unlikely look at a report with a title as vague as "v4 form input issues".

On the other hand, I did not know the bug I reported here was caused by a bug in Bootstrap itself, so this ticket's title is not optimal to track the Bootstrap bug exposed.

I would recommend to either:

1. open a new ticket tracking the underlying bug
2. reopen this ticket and possibly retitle it
3. retitle #23347 with a more specific name