Output pane is too high in Chromium 43

[crumblingstatue]

In Chromium 43, the output pane is too high, covering almost the entire text field.

This doesn't occur with Chromium 42 or Firefox, so this might be a regression in Chromium 43.

[tomjakubowski]

It shouldn't be covering the text field at all, really. The text editing widget can be resized so that the lower half of it or whatever isn't covering it. It makes it very hard to deal with compiler errors when the errors themselves sometimes obscure the very code they're reporting!

[lastorset]

There are a few Chromium bugs reported on 43 about flexbox, but I can't easily see whether they are the same issue. I started minimizing a test case to submit to the Chromium project, here's a work in progress:

https://gist.github.com/lastorset/b2dd56310745cd1d10f6

I have to pause now, but the remaining steps would be to make it deterministic, that is independent of window size, and easy to decide whether it passes. (It should use Ahem, a font with predictable size, and it should use non-relative, non-viewport dependent sizes. It should come with instructions like "There should be no red" or "There should be green".) We can submit a bug report even without this, of course, but we risk the project not seeing the problem.

[lastorset]

Finished minimizing it now. I think this is either

https://code.google.com/p/chromium/issues/detail?id=464210 or
https://code.google.com/p/chromium/issues/detail?id=476840

because it sort of looks like Chromium doesn't consider the flexboxes to have definite size. If it's the latter it was fixed on 5 August, but I don't believe I have a Chromium to test it on now. If someone runs Windows they can try Chrome Canary. Otherwise I might try building Chromium from source tomorrow.

If it's not fixed on master, we should submit a bug report with a note that it may be a dupe of 464210. EDIT: …and that this is a regression in Chromium 43…which actually makes it likely that this is not 464210, since that's been present since Chromium 21.

[lastorset]

I now think this is actually a bug in Firefox instead. The spec changed, so that now flex items only have a definite size if they have a definite flex basis.

In our case, <main> doesn't have a height that can be calculated without measuring its contents, and thus no definite flex basis and no definite size. So when we're telling the layout engine to resolve the 60 % #editor height and the 40 % #result height against <main>, it balks because can only use those lengths if they're resolved against a definite size.

It might seem that Firefox is doing the right thing, or at least the most lenient thing, but it's against the spec and will change in the future.

The simple fix is to give <main> a definite height, like

main { height: 100%; }

I've modified the pass condition of the test case and attached it in Bugzilla.

[lastorset]

(By the way, if anybody should be wondering: this does fail on Wednesday's Chromium.)