1569436 - Butterick’s Practical Typography doesn't print to PDF correctly (abspos hypothetical position on non-first page not working properly)

Status: NEW

(Core :: Printing: Output, defect, P3)

Description

[kten50]

Attachment: Butterick Practical Typography Hypens and Dashes PDF combo screen captures.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I went to print to PDF a page from from Butterick’s Practical Typography on "Hyphens and Dashes" (https://practicaltypography.com/hyphens-and-dashes.html) so that I could transfer that PDF to an older notebook that isn't always Internet connected and look at page off line.

Actual results:

The em illustration and corresponding caption, which was at the bottom of the page when rendered in the Firefox browser tab, was printed sitting on top of the title at the top of the page. Also there are other pages that don't look correct in subtle ways in Firefox's "Print Preview" window, but this page is the most dramatic, so I selected it to file a bug report on.

Expected results:

Both Microsoft Edge 18 and Google Chrome 76 have the web page looking correct in their respective "Print Preview" windows and print to PDF the web page exactly as it looks in all three web browsers.

By the way, thank you for looking into this. Hopefully I've put down enough information to explain the problem I'm having.

Comment 1

[jscher2000]

It's a floated element (aside within li) from the third page that is sliding up to the first page. I don't know why that is happening, it definitely should stay within its parent element.

I compared Firefox 52esr and it had the same behavior, so unless it was fixed at some point in Fx53-67, it doesn't appear to be a recent regression.

Comment 2

[kten50]

(In reply to jscher2000 from comment #1)

It's a floated element (aside within li) from the third page that is sliding up to the first page. I don't know why that is happening, it definitely should stay within its parent element.

I compared Firefox 52esr and it had the same behavior, so unless it was fixed at some point in Fx53-67, it doesn't appear to be a recent regression.

The copy of 52 ESR I have access to also shows the same broken behavior. I also doubt it was fixed between 53 and 67 because, if I remember correctly, I tried to print this same page a few weeks back when I still had 68 Beta installed and it gave the same result as the 69 Beta I have installed.

What I find strange is that everything looks correct in the browser window and that it is only when Firefox goes to the "Print Preview" screen that things get messed up.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[kten50]

Just filing a comment to let Mozilla developer staff know that this bug still exists as of Firefox 84.

Comment 5

[jscher2000]

I wonder whether this needs to be added to the backlog here --

https://wiki.mozilla.org/Platform/Layout/Printing_and_fragmentation#BACKLOG

-- by changing/augmenting the whiteboard on this bug to have either

• [print2020]
• [frag2020]

Comment 6

[Daniel Holbert [:dholbert]]

Yeah, I'll tag this as [frag2020] to get it tracked under that umbrella.

The best next-step here would be for someone to come up with a standalone reduced testcase (with extraneous content/markup removed) that still reproduces the issue - that would help with honing in on what the real underlying problem is.

Comment 7

[kten50]

Attachment: possible test case

I've never created a test case before. I did spend time looking at the original page's code and tried to create what I thought would be a workable test case. It does show the bug in Firefox while working in other browsers just fine. I hope this is what Daniel Holbert [:dholbert] was talking about in the prior comment.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: More reduced test-case.

Yeah, that is great, thank you!

So, it seems like the <aside> is position: absolute, and it has top: auto, so we should be using its hypothetical position. Instead, it seems we're using top: 0 and positioning it relative to the first page.

I'm not sure how we handle hypothetical positions when fragmenting, but yeah, this looks clearly like a bug. Here's a more reduced test-case based on your example which also shows the issue.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

(duplicate comment, sorry)

Comment 10

[Daniel Holbert [:dholbert]]

Possibly related to bug 546559 or bug 267029...