1104439 - wrong behavior on overflow:hidden only on windows 8.1

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[gp]

Attachment: before.jpg

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. Open www.propelorm.org on Windows 8.1
2. Open www.propelorm.org on Windows 7 or any other OS

3. Please see conversation on https://github.com/propelorm/propelorm.github.com/pull/338



Actual results:

1. Main banner is on left side and has a lot of space on the right side
2. Main banner looks good as expected


Expected results:

1. Main banner should be central and background color (blue) should be spanned until the end of page (right side). Main banner should look like opened in Firefox with Windows 7 or Linux for examle
2. Looks good.

Comment 1

[:Gijs (he/him)]

Attachment: Minimal-ish testcase

This wins a prize for most bizarre bug I've seen this week (and it's only Tuesday!).

This has something to do with the open sans font-face declarations (removing those makes the issue go away), and various aspects of the layout of the page, which is why the testcase is still pretty big. Trying to manipulate the testcase on either windows 8 or windows 7 kept "breaking" the reproducibility on the other OS. I've also seen this 'break' on windows 7 only to reflow back to the 'correct' (full-width blue blob) state if I resized the window (after which it would remain correct until I touched the code again).

jfkthame/bz, normally I go further in trying to ascertain what's going on myself, but I'm really unsure what's going on... could either/both of you have a look? Thanks!


If I had to guess... it'd be to do with the floating nav bar being too high depending on the font in use (does win8 ship with open sans while win7 doesn't, or something?), and because of that the section below gets its width reduced to accommodate the float. Arguments in favour: on win8, the right edge of the blue bit matches up with the left edge of the float; messing with the font size / height / line height / border of the nav bar at the top changes whether the issue shows up not at all / everywhere / only on win8. Argument against: why is overflow: hidden affecting this? Why doesn't this happen consistently considering the line-height is fixed in px on all OSes?

Conclusion: I'm out of my depth, can smarter people please have a look? :-)

Comment 2

[:Gijs (he/him)]

Attachment: Minimal-ish testcase

Now with https font-face URLs so they're not mixed-content-blocked on bugzilla...

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #1)
> Created attachment 8528335 [details]
> Minimal-ish testcase
> 
> This wins a prize for most bizarre bug I've seen this week (and it's only
> Tuesday!).
> 
> This has something to do with the open sans font-face declarations (removing
> those makes the issue go away), and various aspects of the layout of the
> page, which is why the testcase is still pretty big. Trying to manipulate
> the testcase on either windows 8 or windows 7 kept "breaking" the
> reproducibility on the other OS. I've also seen this 'break' on windows 7
> only to reflow back to the 'correct' (full-width blue blob) state if I
> resized the window (after which it would remain correct until I touched the
> code again).
> 
> jfkthame/bz, normally I go further in trying to ascertain what's going on
> myself, but I'm really unsure what's going on... could either/both of you
> have a look? Thanks!
> 
> 
> If I had to guess... it'd be to do with the floating nav bar being too high
> depending on the font in use (does win8 ship with open sans while win7
> doesn't, or something?),

One of the comments at https://github.com/propelorm/propelorm.github.com/pull/338 indicated that someone saw this on Win7 as well. Though it could depend on locally-installed fonts, I guess. (I highly doubt that any version of Windows *ships with* any Open Sans fonts.)

Does disabling h/w acceleration fix it? (Perhaps due to using fractional metrics under DirectWrite, but integer ones with GDI.) That could also explain why some people see it, and some don't: it depend whether their hardware/drivers are supported or blocked from acceleration.

Interestingly, from playing with your testcase, it seems to be the overflow-y setting, rather than overflow-x, that is important to reproducing this.

Comment 4

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Does disabling h/w acceleration fix it? (Perhaps due to using fractional
> metrics under DirectWrite, but integer ones with GDI.) That could also
> explain why some people see it, and some don't: it depend whether their
> hardware/drivers are supported or blocked from acceleration.

Yes, disabling HWA fixes this on my win8.1 machine.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Looking at the minimal-ish testcase, we have the following:

1)  A <header> with a fixed height of 100px and a line-height of 100px and a 1px bottom
    border.  
2)  The <header> is followed by a block containing an overflow:hidden block.
3)  The <header> contains a vanilla (well, auto-margin and with max width, but otherwise
    vanilla) block which contains a floating <nav>.  This itself contains some floats (the
    <li> elements).

What I see on Mac is that the <li> elements have a 101px height.  Why?  Well, they have a font-size of 14px and a line-height of 100px.  They they contain an <a> that has a 16px font-size.  http://www.w3.org/TR/CSS21/visudet.html#leading what you get here is a strut using the 14px font.  If we assume that ascent + descent = 14px for this font (which is not obvious to me for this font, by the way), that gives us a leading of 86px, and that means the strut has a descent of 43px + (descent of font), and an ascent of 43px + (ascent of font).  Similarly, for the <a> with a 16px font we get a descent of 42px + descent of font and an ascent of 42px + ascent of font.

I'm willing to bet that in my case the two fonts have the same descent (I'm guessing 2px, but the numbers work out the same way as long as the descent is the same) and ascents that differ by 2px (say 12px and 14px).  So the strut has a descent of 45px and an ascent of 55px, and the <a> has a descent of 44px and an ascent of 56px.  The baselines align, so you get a line box with a 45px descent and a 56px ascent, for a total of 101px.

So first question: For the people seeing the bug, what does document.querySelector("li").getBoundingClientRect().height return?  What does document.querySelector("li").getBoundingClientRect().bottom return?  For me those are 101 and 109 respectively.

Anyway, since the <nav> is floated itself, it's a block formatting context and hence also ends up with a 101px height for me.  Again, document.querySelector("nav").getBoundingClientRect().height is 101 and document.querySelector("nav").getBoundingClientRect().bottom is 109.

Now we look at the overflow:hidden thing.  Its document.querySelector(".home-banner").getBoundingClientRect().top is 109, because the only in-flow thing above it is the <header>, which as I said has a 100px height and a 1px bottom border.

So in my case the floats don't overlap the overflow:hidden thing vertically.  But note that this is crucially dependent on the exact font metrics (ascent and descent) of the fonts involved!  If it happened that the descent of the 16px font were smaller than the descent of the 14px font for some reason, for example, or if my assumption that A+D == font-size happens not to hold, then the line height would end up greater than 101px.

The observed behavior this bug is being reported _does_ correspond to what would happen if the total line height of the <li>s ended up greater than 101px: in that case the overflow:hidden thing, which is not clearing the floats, would be made narrower to accommodate them.

So what are the exact ascents and descents of the font involved at the two different font sizes?  I'm not sure how to easily get that information...

Oh, and to answer the questions from comment 1:

> why is overflow: hidden affecting this?

Because in CSS layout overflow:hidden things are not allowed to overlap earlier floats.  Quoting <http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float>:

   The border box of a table, a block-level replaced element, or an element in the normal 
   flow that establishes a new block formatting context (such as an element with
   'overflow' other than 'visible') must not overlap the margin box of any floats in the
   same block formatting context as the element itself. If necessary, implementations
   should clear the said element by placing it below any preceding floats, but may place
   it adjacent to such floats if there is sufficient space. They may even make the border
   box of said element narrower than defined by section 10.3.3. CSS2 does not define when
   a UA may put said element next to the float or by how much said element may become
   narrower. 

> Why doesn't this happen consistently

Because it depends on the exact font metrics involved, per above.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Oh, and the point is that the layout used here is very fragile, since it _does_ depend so much on the exact font metrics.  It would be better to either have the block following the <header> clear it or to not use a fixed height on the header (using a clearfix instead to make sure the header is tall enough for its floats) or at least use a line-height slightly smaller than height to give a bit of wiggle room when things are getting baseline-aligned (though this could still break with some font metrics).  Or even just make sure everything in the header is at the same font-size so you don't get struts from a font with one descent and text from a font with a different descent.

Comment 7

[:Gijs (he/him)]

(In reply to Please do not ask for reviews for a bit [:bz] from comment #6)
> Oh, and the point is that the layout used here is very fragile, since it
> _does_ depend so much on the exact font metrics.  It would be better to
> either have the block following the <header> clear it or to not use a fixed
> height on the header (using a clearfix instead to make sure the header is
> tall enough for its floats)

In fairness, I removed the CSS styling for the div.break which had clear:both, as it didn't seem to matter in terms of reproducing the bug. AIUI you're saying the clearfix should follow the <header>, not be inside it?


(In reply to Please do not ask for reviews for a bit [:bz] from comment #5)
> So first question: For the people seeing the bug, what does
> document.querySelector("li").getBoundingClientRect().height return?  What
> does document.querySelector("li").getBoundingClientRect().bottom return? 
> For me those are 101 and 109 respectively.

101.5 and 109.5, respectively.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> AIUI you're saying the clearfix should follow the <header>, not be inside it?

If the header is fixed-height yes, because the clearfix div is moving down but not moving down the bottom edge of the header.  The clearfix inside would work fine on an auto-height header.

> 101.5 and 109.5, respectively.

Well, there we are.  And since 109.5 > 109, the floats would intersect the oveflow:hidden thing...

Comment 9

[:Gijs (he/him)]

Ultimately, is there much of anything we can/should do here? (I think "no", but I'm checking to be sure!)

Comment 10

[Jonathan Kew [:jfkthame]]

I don't think so. As bz points out in comments 5 and 6 etc, the layout involved is extremely fragile and dependent on exact details of font metrics -- which can NOT be relied on across browsers/platforms/user configurations.

Comment 11

[:Gijs (he/him)]

OK, so then this is essentially a website issue, not a Firefox one, so "invalid" seems most appropriate.

Comment 12

[Boris Zbarsky [:bzbarsky]]

We could evangelize the site to fix their broken CSS....

Comment 13

[:Gijs (he/him)]

(In reply to On vacation August 4-25.  Please mail manually if really needed. from comment #12)
> We could evangelize the site to fix their broken CSS....

Per https://github.com/propelorm/propelorm.github.com/pull/338, I think that's happened, and you did most of the work... ;-)