1222150 - Image slider (elements) on homepage collapsed to narrow column as soon as I updated to Firefox 42, due to overflow:hidden element reducing its width for floats that start below it

Status: NEW

(Core :: Layout: Block and Inline, defect, P4)

Description

[Sean Smith]

Attachment: ScreenShot-www.1800packrat.com-homepage-imageSlider-collapse-Firefox42-.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

I didn't do anything.  Came into work on Nov 4, 2015 logged into our website and the homepage slider was collapsed.  The homepage of our website looked perfectly fine until Firefox updated to 42.  This is the case on both Mac and PCs.  


Actual results:

We have a rotating hero image slider at the top of our homepage.  All of it's elements were displaying and functioning as expected through the evening of Nov 3, 2015.  Then on Nov 4 when I opened the site in Firefox, the slider was condensed into a 30px wide column that falls in the middle of where the images should be.  I checked Firefox and saw that it had updated.  In fact, the same day I noticed this issue on my iMac, I also opened my Macbook for the first time after having it's hard drive replaced (and thus an older version of Firefox on it), logged into our website and the slider images still looked and functioned as expected.  This indicated it is a bug within Firefox.  I've attached screen grabs of how the page is expected appear and how it appears now after an update. 


Expected results:

Nothing should have happened after this update.  The slider should look and function as it did before the update.  I've never experienced such a profound affect on the layout of website after a Firefox update, as I have now.  It really shouldn't happen.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Sean, thank you for the bug report.

The problem first appears in this checkin range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=32712cd01159&tochange=5b54831761b1

David, you seem to have some block reflow changes in that range; could one of them be causing the problem here?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Zip file from "save page, complete" that reproduces the problem even offline

Just in case the site changes to work around the issue.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I presume you mean bug 538194; I don't see others.

I'll have a look on Monday (台北 time).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: mostly simplified testcase

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: variant testcase without negative margin

It's interesting to observe the width-resizing behavior of this testcase (and the first) in Firefox before regression, Firefox after regression, and Chromium.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Note also that the site has a lot of media queries, and I simplified from the 600px-800px window width case.  I think the wider-than-800px case didn't have the negative margin, but still showed the regression.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So bug 538194 did improve our behavior here, but both Blink and Gecko still have bugs in this area.


Part of the problem is that CSS doesn't really define the behavior here.  https://drafts.csswg.org/css2/visuren.html#floats says:

  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.

Blink's behavior is odd; its decision on how much it's willing to narrow the overflow:hidden element varies between the two testcases, even though it clears it past the floats in both cases.  I believe it is this difference that allows this site to work in Blink.

Gecko mostly matches Blink's without-negative-margin narrowing behavior, except that Gecko allows the block to go to zero width, whereas Blink does not.  I don't think this difference affects this particular site, although it's probably an easier and lower-risk fix.

Changing this behavior further is somewhat risky, although maybe better analysis of what the behavior differences are will show something that is a low-risk and sensible change.  However, so far, Blink's behavior doesn't appear sensible to me (as I don't understand why the two testcases are treated so differently, nor why they should be), so I'm not inclined to switch to it based on a single regression report (coming from the author of the regressing page).

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(It's also probably worth looking at Edge's behavior; I haven't done so.)

Comment 9

[Boris Zbarsky [:bzbarsky]]

David, what can the page change to get back to the original layout?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Boris Zbarsky [:bz] from comment #9)
> David, what can the page change to get back to the original layout?

Put 'width: 100%' in the .hero-slider {} rule.