Closed Bug 1015482 Opened 7 years ago Closed 7 years ago
Fix reftests that can't handle "min-width:auto" or "min-height:auto" default values
part 1: add "min-width:0" style to some intentionally-overflowing flex items in w3c-css/submitted/flexbox
2.93 KB, patch
|Details | Diff | Splinter Review|
8.59 KB, patch
|Details | Diff | Splinter Review|
Filing this as a helper-bug for bug 984711. During the time since we removed min-width:auto/min-height:auto support, we've added some flexbox reftests whose behavior will change when we add this support back (in bug 984711). In most cases, this is just something like: <flexbox> <flex item with fixed size> <child element that happens to overflow its flex item> When we add back min-width:auto/min-height:auto support, the flex item will grow to accomodate its contents' min-content size, which breaks the rendering of such tests to no longer match their reference case. I'm filing this bug on fixing these tests (by e.g. adding an explicit "min-width:0" to the flex item, in the pseudocode above) so that they keep passing after bug 984711 is fixed.
This patch adds "min-width: 0;" to three different reftest files that *intentionally* have flex items that are smaller than their contents. The tests are: flexbox-collapsed-item-baseline-1-ref.html flexbox-items-as-stacking-contexts-2.html flexbox-items-as-stacking-contexts-3.html The first one is a reference case. It has a flexbox with a "width:0" baseline-aligned flex item (with text in it), which emulates (from a sizing perspective) the corresponding testcase's baseline-aligned "visibility:collapse" flex item. This reference case will now needs "min-width:0", or else its new auto min-width will give it a nonzero computed width and make it influence the layout in a way that we don't want. The other two tweaked files are tests for stacking-order between adjacent flex items with overlapping content. To get some overlap, these files use content that overflows from each of the adjacent flex items. (Then we can see which content ends up in front). For this overflow to work, we'll now need to have "min-width: 0" on the flex items, or else they'd grow to the size of the overflowing content.
Attachment #8431165 - Flags: review?(matspal)
Comment on attachment 8431165 [details] [diff] [review] part 1: add "min-width:0" style to some intentionally-overflowing flex items in w3c-css/submitted/flexbox r=mats
Attachment #8431165 - Flags: review?(matspal) → review+
Unlike the first patch where the overflow is intentional (and desirable), this second patch fixes some testcases where the overflow is accidental. This patch fixes it by tweaking sizes, to prevent the overflow. (We also could fix it using min-width:0, like in part 1, but that'd be more of a hackaround than a fix.) In the "flexbox-unbreakable-child-1*" files, there's overflow (with min-width:auto) because the <img src=""> elements have an auto-width of 24px, which is larger than the ~20px of width that they have available. The "min-width:auto" patches keep the <img> elements from getting smaller than 24px, so they end up overflowing. I'm bumping their available width up to 30px (with a bit extra for borders around intermediate elements), which fixes the problem. (Their available width comes from -moz-column-width, since this is a flexbox inside of a multicol.) In the flexbox-unbreakable-child-2* files, there's overflow because we have some default-sized text (font-size:16px) inside of a 15px-high element. There's a "font: 10px" decl that tries to make the text smaller, but fails, because that's invalid syntax for "font". This patch fixes it by specifying a font-family as well.
Attachment #8431250 - Flags: review?(matspal)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.