Bugzilla

The "part 1" patch here is needed in order to avoid failing this test:
https://searchfox.org/mozilla-central/source/browser/components/sessionstore/test/browser_590563.js

(johannh, I hope you don't mind reviewing that change, as someone who's worked on the file in question, `info-pages.inc.css`.)

Without part 1's tweak to `info-pages.inc.css`, the "main" patch (part 2) makes us fail some sizing checks in `browser_590563.js`, because `about:sessionrestore` ends up rendering with a 0-height "list of tabs to restore" area.  That area is actually a `height:100%` element inside of a flex item in a vertical flex container, and the flex item has the default `flex-basis:auto` and the flex container is also auto-sized, which means the flex item's height is now considered indefinite (as of this bug), which means the `height:100%` ends up behaving as `height:auto` and collapsing away to nothing because it's got no content.  (This is the new way that this markup is **supposed to** render.)

My patch in part 1 changes to give that flex item a definite flex basis (0px), which makes its final size be considered definite as well.  It won't actually end up being 0px in height, because (a) it's got a `min-height:12em`, and (b) it's still got a flex-grow of 1 so it'll absorb any excess space that its flex container has.

The "part 1" patch here is needed in order to avoid failing this test:
https://searchfox.org/mozilla-central/source/browser/components/sessionstore/test/browser_590563.js

(johannh, I hope you don't mind reviewing that change, as someone who's worked on the file in question, `info-pages.inc.css`.)

Without part 1's tweak to `info-pages.inc.css`, the "main" patch (part 2) makes us fail some sizing checks in `browser_590563.js`, because `about:sessionrestore` ends up rendering with a 0-height "list of tabs to restore" area.  That area is actually a `height:100%` element inside of a flex item in a vertical flex container, and the flex item has the default `flex-basis:auto` and the flex container is also auto-sized, which means the flex item's height is now considered indefinite (as of this bug), which means the `height:100%` ends up behaving as `height:auto` and collapsing away to nothing because it's got no content.  (This is the new way that this markup is **supposed to** render.)

My patch in part 1 changes to give that flex item a definite flex basis (0px), which makes its final size be considered definite as well, which means the `height:100%` can resolve against the final size.  It won't actually end up being 0px in height, because (a) it's got a `min-height:12em`, and (b) it's still got a flex-grow of 1 so it'll absorb any excess space that its flex container has.