1238580 - Part of the line is missing at sabq.org, due to nonzero "margin-bottom" and modern flex items being shrinkable by default (unlike flex items in "-webkit-box")

Status: RESOLVED DUPLICATE of bug 1257688

(Core :: CSS Parsing and Computation, defect)

Description

[blinky]

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

Comment 1

[Mike Taylor [:miketaylr]]

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

Comment 2

[blinky]

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

Comment 3

[Mike Taylor [:miketaylr]]

(note those dropbox links are just redirecting to https://sabq.org)

So I guess the issue here is -webkit-line-clamp.

.darkSection-ellipsis,.ellipsis,.home-ellipsis,.xportal-ellipsis {
  display:block;
  display:-webkit-box;
  max-width:500px;
  max-height:74px;
  -webkit-line-clamp:3;
  -webkit-box-orient:vertical;
  overflow:hidden;
  text-overflow:ellipsis;
  line-height:23px
}

I guess Edge implements this as well, but oddly their devtools don't let you toggle the rule (see screenshot).

Comment 4

[Daniel Holbert [:dholbert]]

I don't think this has anything to do with "-webkit-line-clamp" -- nothing happens in Chrome if I disable that rule, at least. I think this is modern CSS flexbox not being perfect at emulating old-school -webkit-box. :-/

Notes:
 - I can work around the bug in devtools by disabling the "display: -webkit-box" declaration on the <p> container for this text.  (In other words: the element is fine if it's 'display:block'.)
 - Alternately, I can work around it by disabling the "-webkit-box-orient: vertical" declaration.

This indicates that this is modern-flexbox's automagic "min-[width|height]:auto" behavior, causing trouble in our emulation of -webkit-box. :-/  We ran into this in bug 1107378 comment 29, too, FWIW.

Per the modern flexbox spec, we're preventing the flex item (the single, anonymous flex item that wraps the text inside of this <p>) from having a main-size (height) that's less than its min-content size. So the text ends up being taller than the space that the document provides for it, and it overflows and is clipped.

https://drafts.csswg.org/css-flexbox-1/#min-size-auto

For this to work, we'd need to add some (maybe-considerable) hackarounds to disable the "min-width|height:auto" behavior, when we're emulating "display: -webkit-box".

Comment 5

[Mike Taylor [:miketaylr]]

Attachment: Edge devtools.png

Comment 6

[Mike Taylor [:miketaylr]]

Attachment: 1238580.html

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

Comment 7

[Daniel Holbert [:dholbert]]

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

Comment 8

[blinky]

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

Regressed by: bug 1208344

Comment 9

[Daniel Holbert [:dholbert]]

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

Comment 10

[Daniel Holbert [:dholbert]]

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

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screenshot of working site in Nightly 2016-04-06

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

Comment 13

[Mike Taylor [:miketaylr]]

This is awesome progress, thanks Daniel!