Is this reproducible with the latest Google Chrome stable?
The current stable version is 53.0.2785.*.  51.0.2704.* is an ancient version.

Appears reproducible in 53.0.2785.92

I upgraded chrome (along with the rest of my system), and it is still reproducible. 

(I also ran into some unrelated issues, with the browser chrome -- tabs, navbar -- being replaced with yellow squares, but I'm going to tentatively blame the nvidia driver and freebsd port.)

Able to reproduce the issue on Windows 10, Ubuntu 14.04, Mac OS 10.11.6 using chrome stable #53.0.2785.101 and canary #55.0.2853.0.

Bisect Information:
=====================
Good build: 46.0.2474.0
Bad Build : 46.0.2475.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/81d49526d67b9a8c8de98abd44540d917333de36..73d89890e2f6e7bf36c0bfe7294c2d1c1f867e89

Blink changelog:
https://chromium.googlesource.com/chromium/blink/+log/5c812a3..0d24a56

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/1258693005

cbiesinger@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

After messing around with the site's CSS to fix an issue on mobile, it stopped breaking on desktop for me.

Do you still need a repro for this? I can put up a page with the old CSS.

Yes please! I briefly looked at this last week but did not have time to
fully investigate.

Ok. I did a bit more investigation, and have a bit more info.

Broken version:
http://eigenstate.org/busted

Working one:
http://eigenstate.org/contbuild/reports/mc/a4250ceb2489b320e220dbbd9a71a3523001bd50.html

This isn't 100% same CSS as the initial report, I tried to minimize the diff and still get a repro. Also, keep in mind that I'm shit at CSS, and it's entirely possible that it's a layer 8 bug.

It seems to go away when I switch

    #main {
       flex: 1;
    }

to

    #main {
       flex-grow: 1;
    }

Even though https://developer.mozilla.org/en-US/docs/Web/CSS/flex implies that the former should be a shorthand for the latter.

Thanks, I'll look as soon as I can.

Those two are not equivalent though; the format sets flex-basis to 0%, the latter keeps it at the default auto. The MDN documentation is pretty confusing on this point, I agree.

Alright, the reason this works in other browsers is because of  bug 596743  -- we don't currently apply min-width: auto to nested flexboxes for complicated reasons. Of course, the workaround mentioned above works just fine as well. Another option (with different visual outcome) would be to add overflow:auto to #main.

Page structure is:

  body (display: flex; flex-direction: column; min-height: 100%)
    header
    main (display: flex; flex: 1)
    footer

So we size body to be the height of the viewport, header and footer get their intrinsic sizes, and main expands from 0 to fill the remaining height. The rest of the content overflows. Switching to flex-grow: 1 fixes this because we will have auto as flex basis, so we size it to its contents.

A contributing factor is that this is a quirks mode page. In standards mode, we would resolve 0% to auto instead of 0, which would also fix this. So arguably this is also a duplicate of bug 531783