Rare behaviour of the custom file input in some specific browsers

[dec]

Hello to all,

First of all, thanks very, very much for Bootstrap CSS. I find a very rare behaviour with the custom file input. Basically I place a custom file input and next to this a "simple" text input (a CodePen is provided below).

The expected behaviour when we click on the File input is to see the File picker dialog, and, when we click on the text input, we expect that that control take the user focus and allows to write on it.

In browsers like Mozilla Firefox and Microsoft Edge all works as expected, that is, the controls are separated and have their expected behaviours when clicked, however, in browsers like Google Chrome and Opera we can see a rare behaviour.

It's like if the custom file input overlap the text input (even when the console developer inspector don't show that), so, if we click at the left of the text input, what we get is the File picker dialog of the custom file input opened, instead of get the focus in the text input.

Here is a code pen in which you can see what I try to explain

If you try the above CodePen in Firefox or Microsoft Edge everything is working as expected. If you try it, on the other hand, in Google Chrome or Opera, you can see the rare behaviour which I try to describe here.

In few words, the custom file input File picker dialog is opened even if we click outside the control, for example, in another text input control placed next to the custom file input.

Here is a GIF image with the expected behaviour in Mozilla Firefox:

And here is a GIF image with the unexpected behaviour in Google Chrome:

Somethings to maybe take in consideration:

1. Maybe the issue is related with the "z-index" CSS rule of the ".custom-file-input"? If I remove that CSS rule, then the wrong behaviour is reduced (note, did not dissapear, but it's reduced), however, we can't then click over the custom file as expected.

2. Apparently we can have the same wrong behaviour if we place another kind of element next to the custom file input: the point is that in this case may we can't see the same that if the control placed next is a text input: because in this case we expect that the text input get the focus, and, this never occur, due to the launch of the custom file input File picker dialog.

I hope that someone can help me with this issue. Please, if you need more information, just ask me and I will try to provide it as quickly as possible. Thanks very, very much in advance for your help!

[mdo]

Confirming this is the latest version of Chrome? What version of Windows? And what version of Bootstrap?

[patrickhlauke]

seems to be boostrap 4.5. but i can't replicate in Chrome 86.0.4240.198 / Windows 10

[dec]

Hello to all,

Sorry, @mdo and @patrickhlauke, I did not mention my OS nor browsers nor Bootstrap CSS versions... sorry, it's my fault.

I will do it below:

My OS is Windows 10 64 bits version 20H2

I use Bootstrap CSS version 4.5.3

About the browsers in which I test it they are:

Google Chrome version 86.0.4240.198 (Build oficial) (64 bits) (apparently updated) -> Here the unexpected behaviour occur

Opera version 72.0.3815.320 (apparently updated) -> Here the unexpected behaviour occur

Mozilla Firefox version 82.0.3 (64-bit) (apparently updated) -> Here we can see the expected behaviour

Microsoft Edge version 86.0.622.68 (Official build) (64-bit) (apparently updated) -> Here we can see the expected behaviour

Please, if I can offer some any other kind of information, just ask me and I will try to reply as quickly as possible.

Thanks very, very much for your replies!

[dec]

Hello to all,

@patrickhlauke, you said: "seems to be boostrap 4.5. but i can't replicate in Chrome 86.0.4240.198 / Windows 10..."

That is quite rare... because apparently we are using exactly the same Chrome version... so what happen here?

I mean, how it's possible that you can't reproduce the unexpected behaviour and I can do it... using the same browser version...

Maybe the proceesor? That is... I am try with Windows 10 and Chrome 64 bits... maybe you try with Windows 10 and / or Chrome 32 bits?

[patrickhlauke]

ok, out of interest: what does the <input type="file"> look like on your system in Chrome, without any BS styling? I'm suspecting that the spanish language (I'm assuming it's spanish, right?) label for "Browse" is perhaps pushing the default width of the input to be quite wide, making the actual input spill out (but it's invisible/see through).

could you also, for testing purposes, add overflow:hidden to the styles for .custom-file and see if that helps? (it will likely clash a bit with your height redefinition on #view1 #file1, so you'll have to tweak that)

[patrickhlauke]

also, can you also check with devtools how wide the actual <input type="file"> is? I have a feeling that in your case, it'll show that the actual input is exactly where you're seeing that odd behavior.

[patrickhlauke]

if my suspicion is confirmed (and hoping the overflow:hidden addition fixes the weird behavior), we can probably add this to BS's CSS as a fix

[dec]

Hello to all,

Thanks very much for your reply, @patrickhlauke. I think you got the possible point! Anyway, here are my comments to your replies:

ok, out of interest: what does the look like on your system in Chrome, without any BS styling? I'm suspecting that the spanish language (I'm assuming it's spanish, right?) label for "Browse" is perhaps pushing the default width of the input to be quite wide, making the actual input spill out (but it's invisible/see through).

I am not sure that the spanish language causes the problem, because a customer of mine also experiment the same problem (in fact he report to me) and he uses, if I am not wrong, a german language.

On the other hand, by my mistake, I did not use the custom HTML strings in the Codepen that I prepares... it's a mistake, because, in fact I use that custom HTML strings in "the real code". However, even if I try with custom HTML strings, I get the same unexpected behaviour in Chrome and Opera.

also, can you also check with devtools how wide the actual is? I have a feeling that in your case, it'll show that the actual input is exactly where you're seeing that odd behavior.

Nope. That is, what I can see in the inspector is the same than you, @patrickhlauke, that is, I can't see something "overlapping" the text input... apparently the custom file input has the correct size... but the File picker appear when we click "near" to the custom file input...

could you also, for testing purposes, add overflow:hidden to the styles for .custom-file and see if that helps? (it will likely clash a bit with your height redefinition on #view1 #file1, so you'll have to tweak that)

Certainly yes! I mean, applying the "overflow: hidden" to the ".custom-file" we solve the problem, that is, the expected behaviour is what happen in all the browsers in which I test it.

if my suspicion is confirmed (and hoping the overflow:hidden addition fixes the weird behavior), we can probably add this to BS's CSS as a fix

I am not sure what to say... I am developing certain App Builder, and, to me it's not a problem to place the "overflow: hidden" to the ".custom-file"... or may better place it for the file input ID, in my case "#file1", but maybe, if all of these is certainly some possible "bug", then maybe that can or must be applied into Bootstrap CSS... honestly I don't know...

Anyway, thanks very much for your help, @patrickhlauke, because, certainly the "overflow: hidden" in ".custom-file" or the ID of my input apparently do the job and solve the unexpected behaviour.

Thanks very much for your time, sir.

[patrickhlauke]

I'm guessing that the German file input is also wider than the English "Browse" one. (the real / non-bootstrap-styled one I mean - the pure one without any classes or anything).

(and for others that want to see this sort of bug in action in the English version of Chrome, where the https://codepen.io/decsoft/pen/pobqeZx above doesn't immediately show the problem: use devtools to change the forced width of #view1 #file1 to something smaller like 15%. then you can see that clicking in the space right of the now quite small input still triggers the file dialog in Chrome)

[dec]

Hello to all,

Thanks for your work, @patrickhlauke!

Here is a CodePen which directly shows what you mention in your previous post:

https://codepen.io/decsoft/pen/zYByQyK

And here is another one, which shows how your suggested "overflow: hidden" apparently fix the weird behaviour:

https://codepen.io/decsoft/pen/yLJGWwy

[patrickhlauke]

Perfect, thanks @dec - tiny correction, the fix from my PR adds the property to the file input itself, so

#view1 #file1 input { overflow: hidden; }

(which avoids the slight cut-off at the bottom of the custom file input, and still works because file inputs are replaced elements, and that seems to fix the weird Chrome overflowing)

[dec]

Hello to all,

Thanks for your reply, @patrickhlauke. If I am right, what you mean is that we must apply the "overflow" for both the ".custom-file" and also to the ".custom-file-input"? Or just to the first one?

P.S. Note that apparently adding the "overflow" to ".custom-file" only apparently do the job... but I can be wrong..

[patrickhlauke]

just the .custom-file-input ... at least that worked for me (and didn't lead to the bottom of the custom file input widget being cut off by a few pixels at the bottom)

[dec]

Hello to all,

Thanks very much for your reply, @patrickhlauke. You are completly right: we must talk about ".custom-file-input" and not ".custom-file"...

I update the CodePen right now:

https://codepen.io/decsoft/pen/yLJGWwy

[XhmikosR]

Fixed in #32145

[dec]

Hello to all,

Just to say that your work is completely amazing. Just 24 hours later (or less) you provide the right solution!

Thanks very much to all, specially to @patrickhlauke, for your time and work at the outstanding Bootstrap CSS framework.