Bugzilla

> the footer is printed on the 4th page at the top, while visually it would have fit on the 3rd page, - as if there was a hard page break.

I followed your steps to reproduce, and I do see this issue, but it's not actually a hard page break -- if I adjust the print-preview scale up or down a little bit, then some of the footer ends up on the 3rd page.

So it's not a hard page break - rather, there's a spacer-element that fills up the bottom of the 3rd page. This is something that AA.com is explicitly inserting, only in the print stylesheet, for some reason. (I can trigger it in the actual browser -- no printing/print-previewing required -- by enabling the print stylesheet in our developer tools.)

 The element in question is:
```
<section class="section row-buttons no-separator" id="paymentBttnContainer">
</section>
```
and it has this styling, when we're printing:
```css
#paymentBttnContainer {
  height: 200px;
```

When we're *not* printing, it instead has:
```
#paymentBttnContainer {
  height: inherit;
```
...which makes it much smaller. (This rule is in a "screen"-specific media query, which is why it gets skipped when we're printing.)

This element is essentially empty;  it has a bunch of buttons inside of it which are `display:none` i.e. intentionally non-rendering; presumably they show up after you actually provide credit card details, etc.

So the problem here is that aa.com is providing an explicit fairly-tall height to this empty element, which unsurprisingly creates some blank space on the page and pushes content downwards.

> the footer is printed on the 4th page at the top, while visually it would have fit on the 3rd page, - as if there was a hard page break.

I followed your steps to reproduce, and I do see this issue, but it's not actually a hard page break -- if I adjust the print-preview scale up or down a little bit, then some of the footer ends up on the 3rd page.  That demonstrates that it's not a hard page break - rather, there's a spacer-element that fills up the bottom of the 3rd page. This is something that AA.com is explicitly giving a large height, only when printing, for some reason (probably just a bug/oversight on their end). I can trigger it in the actual browser, too -- no printing/print-previewing required -- by enabling the print stylesheet in our developer tools.

The element in question is:
```html
<section class="section row-buttons no-separator" id="paymentBttnContainer">
</section>
```
and it has this styling, when we're printing:
```css
#paymentBttnContainer {
  height: 200px;
```

When we're *not* printing (i.e. when we're rendering normally to the screen), they instead give this element `height:inherit`:
```
#paymentBttnContainer {
  height: inherit;
```
...which makes it much smaller. (This rule is in a "screen"-specific media query, which is why it gets skipped when we're printing.)

This element is essentially empty;  it has a bunch of buttons inside of it which are `display:none` i.e. intentionally non-rendering; presumably they show up after you actually provide credit card details, etc.

So the problem here is that aa.com is providing an explicit fairly-tall height to this empty element, which unsurprisingly creates some blank space on the page and pushes content downwards.