Part of the line is missing in the page https://dl.dropboxusercontent.com/u/95157096/85f61cf7/om6bkv1fux.html. Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/3dikegr8sl.png Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=31edd1840c5f651b5dbf182fdb7f04fe98c88d86&tochange=9fbf850dc78d7197132a298f9ec0270c7de16a13 Regressed by: bug 1213126

Hi blinky, Can you provide steps to find that text that is cut off? For example, click on this link or button, then scroll, etc. Or a link to that specific section? In Nightly I don't currently see anything wrong, but I'm probably looking at the wrong part of the page...

Steps to reproduce: 1. Go to https://dl.dropboxusercontent.com/u/95157096/85f61cf7/om6bkv1fux.html. 2. Go to the middle of the page "yellow part". See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/0dl6pl7y60.mp4

A small example of the style from the page, with max-width changed to 200px to force more than 3 lines.

Sorry, my analysis in comment 4 is not correct. Tagging it as obsolete. The *real* culrprit here is some "margin" styling, combined with "overflow:hidden" and some duplicated nested max-height values. Specifically, we have <a class="home-ellipsis"> <p class="ellipsis ng-binding"> Text text text </p> </a> The <a> and the <p> each have: display:block; display: -webkit-box; margin: 0 0 10px; max-height: 48.2px; overflow:hidden; In Firefox release (without -webkit-box emulation), the bottom-margins collapse (between nested blocks), and each nested div ends up 48.2px tall, which happens to be just the right height. In Firefox Nightly (with -webkit-box emulation), the bottom-margins *do not* collapse (because modern flexbox doesn't collapse adjacent margins). So the inner flexbox (the <p>) has a 10px margin taking up 10px of the 48.2px that the parent made available, which leaves only 38.2px for this inner flexbox. (Normally it would force itself to be at least as tall as its intrinsic size, by virtue of it being a flex item; but its "overflow:hidden" styling disables that behavior.) In Chrome, as in Nightly, the bottom-margins *do not* collapse, BUT the flex item also does not shrink by default -- so its margin just (imperceptibly) overflows its parent. This is because flex items are not shrinkable by default in old-school flexbox. (They have a default "-webkit-box-flex: 0", which controls both growing and shrinking. In contrast, modern-flexbox has a default "flex-shrink: 1", which allows items to shrink if there's not enough space.)

Pushlog with enabled layout.css.prefixes.webkit = true; https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6f4da397ac3cdaa90d7b05a279a5fd76adc3e667&tochange=a1d32f3194a412d78c762766f88696d224c6fed0 Regressed by: bug 1208344

Right, that's just where we added support for "-webkit-box-orient: vertical". That's what lets us have a vertical main-axis here, and the (default-in-modern-flexbox) "flex-shrink: 1" mentioned in comment 7 only takes effect in the main axis. In any case, I think it makes sense to consider this a regression from bug 1213126 (enabling webkit prefix support), and a dependency of bug 1238668 (cases where modern flexbox & old-style -webkit-box disagree).

One more webcompat issue with this same underlying cause (modern flex items being shrinkable by default, which makes display:flex imperfect for emulating -webkit-box): https://github.com/webcompat/web-bugs/issues/2267

I've verified that this became fixed in today's Nightly (broken yesterday, working today). I checked the original sabq.org site and scrolled down to the "yellow part" mentioned above & shown in comment 0's screenshot.

(Here's a screenshot of the site with the bug fixed -- text no longer clipped.)

This is awesome progress, thanks Daniel!