When printing a webpage, Firefox leaves the 1st page mostly empty
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: bug-str, Unassigned)
Details
Attachments
(3 files)
Firefox-aa-page-100percent-priv.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
Firefox 93.0 on Windows 10
When printing certain pages (often purchase/confirmation/payment pages), the first page is left mostly empty, except the page header, and the rest of the "main" content is pushed to the 2nd page.
Playing with the scale (100% -> e.g. 90%) can feel up the 1st page.
"Fit to page width" - sometimes helps, sometimes doesn't.
Actual results:
Almost empty 1st page, all the content is shifted to the 2nd page.
Expected results:
The main page content should start on the first. It is not an unbreakable image; it is text.
|
||
Comment 2•4 years ago
|
||
Igor, thanks for reporting. Would you mind uploading a simplified test case to reproduce this issue? Thanks!
How do you imagine I can provide a simplified case? Building a new website for creating a test environment? I am not a web-UI designer and do not have tools and resources for that.
I understand, that it is harder to reproduce this behavior without a specific example where no purchase is required.
I can offer the following scenario that shows a very similar (the same?) problem - also on aa.com but doesn't require the actual purchase/login:
Go to aa.com -> Plan Travel -> flights. Choose an origin and a destination for a round trip, choose the dates. Click on continue. Choose one of the flights for each portion.
Once you select both flights, choose "continue as a guest". Enter some name, phone # and e-mail address (user@domain.com 888-555-1212 etc.).
When you reach "Review and Pay" page, look at the print preview. With both 100% scale and "fit-to-width", I see that the 3rd page stays mostly empty, except for a few elements at the top. and then 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 will try to attached the PDF showing that.
|
||
Comment 5•4 years ago
|
||
The severity field is not set for this bug.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 6•4 years ago
•
|
||
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:
<section class="section row-buttons no-separator" id="paymentBttnContainer">
</section>
and it has this styling, when we're printing:
#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.
Thank you for your investigation!
If I understood your explanation correctly, it covers only why the 3rd page was empty in the 3rd attachment (PDF).
However, it does not cover the reason why the first page is left with the empty space at 100% scale, as shown in the first attached JPEG, Firefox-aa-page-100percent-priv.jpg , but there is no empty space at 90%.
That was the main reported issue. The empty 3rd page issues was an "auxiliary" issue. I apologize if I did not make it clear.
|
|
||
Comment 8•4 years ago
•
|
||
You're right, sorry - my comment 6 was in response to comment 3, which was about the issue that can be reproduced without actually booking a flight. :)
The first-page-left-mostly-empty is not something I can test without booking a trip, it looks like (comment 0 shows a "Your trip is booked" page), so I can't give detailed insight/analysis there.
Most-likely, though: in your screenshot from comment 0, the content that gets pushed off of page 1 and onto page 2 is probably inside of a container-element that Firefox considers "un-fragmentable" like an inline-block; and if that element crosses a page boundary, it puts us at risk of slicing text or images since we can't properly split it (for complicated reasons). See bug 1759926 for a bit more on this "slicing".
If we can tell that this un-fragmentable element will not entirely fit in the remaining space on the page, then we push it to the next page to reduce the likelihood of that happening. Chrome does not, and as a result they are sometimes more-at-risk of "slicing text" (or other content) at a pagebreak than we are. Our current implementation is aiming to avoid data-loss / slicing, at the cost of sometimes using an extra page.
Description
•