Hi folks... This test fails in all browsers, as shown here:
https://wpt.fyi/results/css/css-flexbox/flex-flow-auto-margins-no-available-space-assert.html

It has extremely-cursed-looking styling & expectations:

* {
    display: flex;
    padding-bottom: 20pt;
    min-height: 0.7%;
    margin-top: 6000%;
    flex-shrink: 0;
    flex-basis: 7000%;
}

<abbr data-expected-height=30210272>
    <input></input>
</abbr>

This element is expected to be exactly thirty million, two hundred and ten thousand, two hundred and seventy two pixels tall. (no obvious reason why the test would be expecting precisely that height)

And it's not actually that height, even in Chrome.

Can we back this test out, and/or fix it to have valid expectations? @Gyuyoung @davidsgrogan

(CC @cbiesinger as well since it looks like he was involved with the gerrit code review)

I'm a bit surprised this testcase made the jump into WPT in its current state, honestly, given:
a) the weird/cursed magic-number in the expected value
b) the lack of any comments explaining (or self-evident reason for) where that magic number comes from
c) the fact that not even Chromium passes the test right now

In the future it would be great if reviewers & patch-authors could keep these sorts of things in mind, as part of the checklist of things to look at & check for when auditing tests that are going to be added to WPT.

(Right now I'm digging out from a pile of new WPT tests that were recently added to WPT & which fail in Firefox, and cases like this one are kinda frustrating to have to spend time investigating.)

Yeah, this has to go.

Sorry @Gyuyoung I didn't realize it was this test. It only passes in chrome's local test runner. It (+ one other test) caught a regression for me last year so I'm a little hesitant to delete it, but I sure didn't find the bug by figuring out what the test was doing.

@Gyuyoung maybe for now, move it, for whatever the latest name it has, back to css3/flexbox and mark it unmoveable?

@cbiesinger do you know what this test was supposed to be testing?

(CC @cbiesinger as well since it looks like he was involved with the gerrit code review)

In the future it would be great if reviewers & patch-authors could keep these sorts of things in mind, as part of the checklist of things to look at & check for when auditing tests that are going to be added to WPT.

(Right now I'm digging out from a pile of new WPT tests that were recently added to WPT & which fail in Firefox, and cases like this one are kinda frustrating.)

Totally agree, apologies.

My apologies, @dholbert . I had assumed that this wouldn't be a problem because I knew that on Mac, we have overlay scrollbars, and so I thought tests would fail there if they don't handle that. But today I learned that our test runner disables them on Mac, and clearly we have tests relying on that.

I will make sure to watch out for that in future patches.

@davidsgrogan , the test was added to catch a case where we would compute a negative content size for a box (a size less than border+padding). https://codereview.chromium.org/1017673002

To be clear, the presence/absence of overlay scrollbars wasn't really the problem in this particular case.

My gripe here is the unexplained & almost-certainly-bogus data-expected-height=30210272 (which presumably is the humongous height that Chrome computes under some configurations, but likely isn't based on much besides that).

But in any case, I appreciate the sentiment & appreciate you all taking a look. :)

@Gyuyoung maybe for now, move it, for whatever the latest name it has, back to css3/flexbox and mark it unmoveable?

Sorry for the late reply. yes, I will mark the test unmoveable. Then, I'm going to revert it.

I moved it to the css3/flexbox again. Then, I marked the test unmoveable in the sheet. My apologies, @dholbert.