1265543 - flex items in a -webkit-box may overflow their container, due to emulation with modern flexbox & its "min-width:auto" behavior

Status: NEW

(Core :: Layout: Flexbox, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:
 1. Load attached testcase.

EXPECTED RESULTS:
Nothing should escape from the black bordered area.

ACTUAL RESULTS:
The "aaaa...." and its pink background runs off the right side of the black bordered area.

This happens as a result of honoring modern flexbox's "min-width:auto" behavior. (Note that the spec's special case for "overflow: [non-visible]" doesn't apply here, because that special case is about "overflow" being set on a *flex item* -- and in this testcase, "overflow" is set on the *child* of a flex item.)

We may need to consider suppressing "min-width:auto" behavior for flex items in a -webkit-box container.

Comment 1

[Daniel Holbert [:dholbert]]

Once webkit prefix support is enabled, this bug is responsible for the header toolbar at http://m.hupu.com/bbs/1048 overflowing, as pointed out in https://github.com/webcompat/web-bugs/issues/2450#issuecomment-211212980 and my response to that comment.

The element with class "board-con" there ends up too wide in Firefox Nightly, because the default "min-width:auto" behavior makes it refuse to be smaller than its kids' min-content width (which happens to be huge).

(On the plus side, though, we behave similarly when webkit prefix support is disabled -- at least for that site. So this is not a regression for us -- so at this point, this doesn't need to block bug 1259345.)

Comment 2

[Dennis Schubert [:denschub]]

Setting WebCompat Priority P3 for now: we don't know about still occurring site breakage, but the issue is still valid in theory.

Comment 3

[Thomas Wisniewski [:twisniewski]]

Hupu's site fixed the issue on their end, so there is no known webcompat breakage at the moment (in fact the specific URL is a 404 now). Unsetting the webcompat priority for now.