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

NEW
Unassigned

Status

()

Core
Layout
2 years ago
a year ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox48 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8742506 [details]
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.
(Reporter)

Comment 1

2 years ago
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.)
You need to log in before you can comment on or make changes to this bug.