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

Steps to reproduce:

Since some weeks, my pdf is getting with margins bigger than before, mostly the right and bottom margins.
I don't have this problem if I'm printing with other browsers.

Same problem in incognito mode.

For example, try to print any page here :
http://ks.petruccimusiclibrary.org/files/imglnks/usimg/4/4b/IMSLP173660-PMLP05899-2.pdf

I have prints from this pdf that I printed previously with firefox, and the right and bottom margins are more normal, less bigger.
Today, those 2 margins are about 1/3 bigger.

read "my pdf is getting PRINTED with margins"

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Oh, I had to choose a A4 paper size, even though I'm printing on letter size.
So it depends on the pdf I want to print.

I can repro with that PDF quite easily.

Mozregression says: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b46517fe6e6b0381c55b5670d2244d4e2c22e082&tochange=230b74c414e78e44cc0d589ec704285eb67afb99

Can you confirm that if you go to about:config, and change layout.display-list.improve-fragmentation back to false, the PDFs print as before?

Mats, it seems like the fragmentation improvements cause PDF pages to have more overflow. STR is opening the PDF in comment 0 and setting the page size to "A4". We try to fit to page size but we end up too small.

Any chance you can take a look?

Do you happen to have a smaller PDF that reproduces this issue? It might be easier to debug than a 144 page PDF :-)

Thanks for reporting this!

I landed a workaround for this bug in https://github.com/mozilla/pdf.js/pull/13100, but I think the behavior change is probably unintended and I don't see why that change fixes it, so if you can look into this mats it'd be very appreciated.

Ryan, can we get a pdf.js update with the above change?

Hmm, I don't understand why fragmentation fallback would have this effect. Bug 1674027 seems a more likely culprit. I can see it happening if the page is very tall and printed onto a page with a smaller ratio (scaling down the height while preserving the ratio). Maybe we should center the page in the non-scaled axis when that happens?

Anyway, I'll take a look at why changing the pref changes the behavior at all, it seems it shouldn't...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Mozregression says: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b46517fe6e6b0381c55b5670d2244d4e2c22e082&tochange=230b74c414e78e44cc0d589ec704285eb67afb99

If I enable the pref manually and then continue, I get the real regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5b690fe1945c421349e52e3f065a1b491940a99d&tochange=7dc7a4ef909899bef62b6dc9f0b9eac806096da6

Which is still a bit puzzling because that change shouldn't affect the first page in any way.

So I think what happens is that the bOffset adjustment to reserve space for overflow we made in that bug affects the mShrinkToFitRatio a page reports, since it makes the overflow appear even larger and thus requiring even more shrinking to fit. I forgot that we reflow all the pages and collect the smallest shrink ratio and reflow everything again with that ratio. That's how the first page is affected by a bOffset in later pages.

Hmm, that's an unintentional side-effect for sure... We don't want that offset to affect the shrink-to-fit ratio a page reports in the first phase.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Ryan, can we get a pdf.js update with the above change?

I still have the problem even using "A4".

The difference firefox/chrome is more obvious with this pdf :
https://ks4.imslp.info/files/imglnks/usimg/8/82/IMSLP01445-BWV0183.pdf

Are you using nightly? The fix will take a bit to get to a stable release, but a build from https://nightly.mozilla.org shows the right margins for me.

Thanks Emilio ! I'll try Nightly.

I guess we can call this bug fixed, please reopen if you can still reproduce in a recent Firefox version.