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.

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?

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

I presume you mean bug 538194; I don't see others. I'll have a look on Monday (台北 time).

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

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.

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).

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

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

(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.