1503427 - Firefox 63 pushing Bootstrap 3 date input text down

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[scottmcconkey7]

Attachment: Snap 2018-10-30 at 17.16.20.png

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Today I suddenly realized that date inputs on a website I'm developing had their text portion almost flush to the bottom of the input box. I am using Firefox 63 on a Windows 7 computer. I tested this on other browsers, which displayed the text properly. I also tested this on multiple browsers on a Windows 10 computer, and only Firefox has the issue.


Actual results:

The text and cancel button portion of date input fields styled using Bootstrap 3.3.6 do not appear vertically centered, but appear to be very close to the bottom of the input box.

I would be inclined to believe this is a Bootstrap issue, except that I have not upgraded my bootstrap installation beyond 3.3.6 for the duration of my development of this project over the past year. This issue has never appeared until today, and the issue does not appear in other browsers. I believe this is merely a symptom of browser changes.


Expected results:

The text and cancel button portion of input fields styled using Bootstrap 3.3.6 should appear centered.

Comment 1

[scottmcconkey7]

I should also add that I tested date input fields independently of my website to guarantee I had not mis-configured my css. The attached image is from one such independent tests.

Comment 2

[gotsky]

I encountered the same bug, except it was on bootstrap 3.3.7, firefox & ubuntu

It seems to be related with  the line-height declaration in the "@media screen and (-webkit-min-device-pixel-ratio: 0)" block,
for date, time, (...) inputs

You can visualize it on this theme:
http://html-templates.multipurposethemes.com/bootstrap-4/admin/minimo-admin/minimoadmin-bootstrap-3/pages/forms/general.html

Comment 3

[Adrian Florinescu [:aflorinescu]]

Reproduced this issue on 65.0a1 20181105100136 / 63.0.1 20181030165643 on Ubuntu 16.04, Osx 10.13 and Win 10.

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5f50dd0905ec23b0d1fa1747905d5a1ef5f73dc2&tochange=7d3fe27beec58d201a98d6bfcbe43d6e493348c6

Regressed by: 
7d3fe27beec5	Daniel Holbert — Bug 1444139: Re-enable support for webkit-prefixed pixel-density media queries (e.g. -webkit-min-device-pixel-ratio) r=xidorn

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to gotsky from comment #2)
> I encountered the same bug, except it was on bootstrap 3.3.7, firefox &
> ubuntu
> 
> It seems to be related with  the line-height declaration in the "@media
> screen and (-webkit-min-device-pixel-ratio: 0)" block,
> for date, time, (...) inputs

Yeah -- that selector used to be an "if (Chrome/Safari)" selector, basically.  Now it matches Firefox as well, so we're getting some styles that we didn't previously, which reveals an incompatibility with how those styles are handled.

So, this is actually a long-standing layout bug, but the CSS that triggers it in Bootstrap seems to have been hidden behind a selector that we skipped until now.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1 (without any -webkit-min-device-pixel-ratio selector)

Here's a reduced testcase for the layout issue here, comparing <input type="date|time|number"> against plain <input>, with the same overconstraining styles on each.  ("overconstraining" = the padding-box of the internals, taken from the line-height + the vertical padding, is much taller than the border-box height of the widget itself.  Specifically, it's taller by the amount of the padding.)

For input type="date" and "time", we'd probably like to center the internals (so that there's invisible overflow on the top & bottom), but instead we seem to align the internals to the top and we overflow on the bottom (clipping the text).

For input type="number", we seem to center the internals, but we also squish it vertically so the number is mostly visually clipped.

Comment 7

[Daniel Holbert [:dholbert]]

I can't look at this too much today, but I'll see if I can circle back & find a way to improve things here in the next few days...

Comment 8

[scottmcconkey7]

Thank you all for looking into this :)

Comment 9

[Pascal Chevrel:pascalc (PTO until April 26)]

Updating tracking flags as we get closer to the 64 release.

Comment 10

[buminda]

I have the same issue, is there a recommended workaround until 64 release. My client is using Firefox as the default browser. When is 64 release scheduled ?

Comment 11

[Adrian Florinescu [:aflorinescu]]

(In reply to buminda from comment #10)
> I have the same issue, is there a recommended workaround until 64 release.
> My client is using Firefox as the default browser. When is 64 release
> scheduled ?
Not sure about the workaround, but the Firefox 64 release is scheduled on 2018-12-11 (see https://wiki.mozilla.org/Release_Management/Calendar)

Comment 12

[Daniel Holbert [:dholbert]]

If you're hitting the issue with bootstrap (presumably using CSS like the CSS that's in play in comment 4), you can probably work around it by resetting the overconstrained "line-height" value. In that case, the problematic rule looks like this:
> input[type="date"].form-control, input[type="time"].form-control,
> input[type="datetime-local"].form-control, input[type="month"].form-control {
>    line-height: 34px;
> }

You can reset that by using the same selector list, and specifying "line-height: initial". (specifying later so that it "wins", or adding !important to make it win even if it comes before the 34px rule).

That fixes Firefox's rendering at 
http://html-templates.multipurposethemes.com/bootstrap-4/admin/minimo-admin/minimoadmin-bootstrap-3/pages/forms/general.html
for me, and it doesn't have any effect that I can see in Chrome.

RE Firefox 64 release date: note that we don't have a fix for this yet on the Firefox side, so the 64 release date may not be relevant here.  (And even if we get a fix before release-day Dec 11, there's a severe risk/benefit calculation for late-breaking changes, since they may introduce unforseen breakage. So I would bet this'll be fixed in 65 at the earliest.)

Comment 13

[Daniel Holbert [:dholbert]]

[tentatively assigning to myself to keep it on my radar, though it'll likely still be a few days before I get to looking into this]

Comment 14

[gotsky]

tested and approved! Thank you Daniel
So the workaround is to add this on your custom css:
input[type="date"].form-control, input[type="time"].form-control,
input[type="datetime-local"].form-control, input[type="month"].form-control {
    line-height: initial;
}


(In reply to Daniel Holbert [:dholbert] from comment #12)
> If you're hitting the issue with bootstrap (presumably using CSS like the
> CSS that's in play in comment 4), you can probably work around it by
> resetting the overconstrained "line-height" value. In that case, the
> problematic rule looks like this:
> > input[type="date"].form-control, input[type="time"].form-control,
> > input[type="datetime-local"].form-control, input[type="month"].form-control {
> >    line-height: 34px;
> > }
> 
> You can reset that by using the same selector list, and specifying
> "line-height: initial". (specifying later so that it "wins", or adding
> !important to make it win even if it comes before the 34px rule).
> 
> That fixes Firefox's rendering at 
> http://html-templates.multipurposethemes.com/bootstrap-4/admin/minimo-admin/
> minimoadmin-bootstrap-3/pages/forms/general.html
> for me, and it doesn't have any effect that I can see in Chrome.
> 
> RE Firefox 64 release date: note that we don't have a fix for this yet on
> the Firefox side, so the 64 release date may not be relevant here.  (And
> even if we get a fix before release-day Dec 11, there's a severe
> risk/benefit calculation for late-breaking changes, since they may introduce
> unforseen breakage. So I would bet this'll be fixed in 65 at the earliest.)

Comment 15

[Daniel Holbert [:dholbert]]

Glad to hear it - thanks for letting us know.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional for 65 and 66 so that these already triaged issues don't show up repeatedly in weekly regression triage. Happy to take a patch in nightly.

Comment 17

[u634457]

Any news about this bug?

Comment 18

[Piotr Dobrogost]

(In reply to Daniel Holbert [:dholbert] from comment #5)

So, this is actually a long-standing layout bug, but the CSS that triggers
it in Bootstrap seems to have been hidden behind a selector that we skipped
until now.

Could you please reference this "long-standing layout bug" by its number?

(In reply to Daniel Holbert [:dholbert] from comment #12)

If you're hitting the issue with bootstrap (presumably using CSS like the
CSS that's in play in comment 4), you can probably work around it by
resetting the overconstrained "line-height" value. In that case, the
problematic rule looks like this:

input[type="date"].form-control, input[type="time"].form-control,
input[type="datetime-local"].form-control, input[type="month"].form-control {
line-height: 34px;
}

You can reset that by using the same selector list, and specifying
"line-height: initial". (specifying later so that it "wins", or adding
!important to make it win even if it comes before the 34px rule).

Well, the bootstrap css supports also small and large variants this way:

@media screen and (-webkit-min-device-pixel-ratio: 0) {
input[type="date"].form-control,
input[type="time"].form-control,
input[type="datetime-local"].form-control,
input[type="month"].form-control {
line-height: 45px;
}
input[type="date"].input-sm,
input[type="time"].input-sm,
input[type="datetime-local"].input-sm,
input[type="month"].input-sm,
.input-group-sm input[type="date"],
.input-group-sm input[type="time"],
.input-group-sm input[type="datetime-local"],
.input-group-sm input[type="month"] {
line-height: 35px;
}
input[type="date"].input-lg,
input[type="time"].input-lg,
input[type="datetime-local"].input-lg,
input[type="month"].input-lg,
.input-group-lg input[type="date"],
.input-group-lg input[type="time"],
.input-group-lg input[type="datetime-local"],
.input-group-lg input[type="month"] {
line-height: 66px;
}
}

Adding suggested declarations to custom css (thus placing them later than the original bootstrap's declarations) even without !important makes them win over -sm and -lg variants.
I guess it's not intentional and from what I observe it doesn't fix these other variants.
What would be the fix for -sm and -lg variants, then?

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Piotr Dobrogost from comment #18)

(In reply to Daniel Holbert [:dholbert] from comment #5)

So, this is actually a long-standing layout bug, but the CSS that triggers
it in Bootstrap seems to have been hidden behind a selector that we skipped
until now.

Could you please reference this "long-standing layout bug" by its number?

Sorry if that wasn't clear -- there's no other bug number. I wasn't saying it was a different long-standing layout bug. I was simply saying that this bug here (the core layout issue) has existed for quite a while, but it wasn't triggered on bootstrap until relatively recently because the problematic CSS (that would've triggered the bug) is hidden behind a selector that we only recently started parsing.

(In reply to Daniel Holbert [:dholbert] from comment #12)
What would be the fix for -sm and -lg variants, then?

Can you post a link or a testcase that shows the -sm and -lg variants, where they're not fixed by putting line-height:initial on the form control?

Comment 20

[Piotr Dobrogost]

(In reply to Daniel Holbert [:dholbert] from comment #19)

Sorry if that wasn't clear -- there's no other bug number. I wasn't saying it was a different long-standing layout bug. I was simply saying that this bug here (the core layout issue) has existed for quite a while, but it wasn't triggered on bootstrap until relatively recently because the problematic CSS (that would've triggered the bug) is hidden behind a selector that we only recently started parsing.

Ok, was going to ask you to describe what's the core issue here is then but I think your description in comment 6 makes it pretty clear already.

(In reply to Daniel Holbert [:dholbert] from comment #12)
What would be the fix for -sm and -lg variants, then?

Can you post a link or a testcase that shows the -sm and -lg variants, where they're not fixed by putting line-height:initial on the form control?

Will attach 3 screen shots for the following cases:
– bootstrap 3.3.7, chrome 71
– bootstrap 3.3.7, firefox 65
– bootstrap 3.3.7, line-height:initial, firefox 65

To better show lack of vertical alignment I used

background-clip: content-box;
background-color: aqua;

to highlight content specifically.

html used:

<div>
  <label for="normal">normal: <label>
  <input name="normal" type="time" class="form-control">
</div>
<div>
  <label for"small">small (-sm): <label>
  <input name="small" type="time" class="form-control input-sm">
</div>
<div>
  <label for="large">large (-lg): <label>
  <input name="large" type="time" class="form-control input-lg">
</div>

css used:

input[type="time"].form-control {
  line-height: initial; /* only in case no 3 */
  background-clip: content-box;
  background-color: aqua;    
}

Looking at these screen shots it seems that line-height: initial does not fix any variant. Without it text is too low in all 3 variants, and when it's used text is too high in all 3 variants (normal, small, large).
This leads to the question; why do you think that setting line-height: initial should fix the issue you described in comment 6?

I was testing above at https://www.bootply.com

Comment 21

[Piotr Dobrogost]

Attachment: bug1503427, bootstrap 3.3.7, chrome 71.png

Comment 22

[Piotr Dobrogost]

Attachment: bug1503427, bootstrap 3.3.7, firefox 65.png

Comment 23

[Piotr Dobrogost]

Attachment: bug1503427, bootstrap 3.3.7, line-height:initial, firefox 65.png

Comment 24

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 25

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 26

[Daniel Holbert [:dholbert]]

[unassigning, to reflect reality; I'm focused on other projects at the moment, but I would like to see this fixed & don't want my 'assigned' status to prevent others from picking this up.]