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-empty is not something I can test without booking a trip, it looks like (that's 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.
Bug 1737427 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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.