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

Steps to reproduce:

Printed a page in 72 branch
Printed the same page in 73 branch

In both cases:

The page size is 149×219mm. The page image to be printed has twice that dimension, so in Print Setup, I had the scale factor set to 50%... but no automatic scale to fit.

Margins are set to zero, and headers and footers are empty.

Actual results:

In 72 branch, the image was printed and fill the page.

In 73 branch, the image was scaled by a different factor in each dimension. The scale was close to being like as if the page image had been rendered to a letter or A4 size paper, and then scaled down to fit the actual page size... except the ratios weren't quite the same as either paper size scaled in that manner. The smaller page image was then printed aligned with the upper left corner of the actual paper size, with large white margins below and to the right.

The other strange thing (will be bug 3 of 3) is that the page image is created as absolutely positioned iframes of the same size, and some of the content is in each iframe. On screen, and for 72 branch, all the iframes were included in the print, but in 73, only the top iframe was visibly included.

Expected results:

In both 72 and 73, the page image should have filled the page.

The attachments show how to set create the page size in Windows (that tends to be hard to find), and then the differing results from printing the same page in 72 and 73.

The code is complex; I made a simple test case with just a border box, and it printed correctly on both branches. I'll continue trying to find a test case that is less complex, although I'm hoping that whoever has been changing the printing recently will recognize that something might have gone wrong. I'd sure appreciate a list of the bugs that were "fixed" regarding printing in 73 branch, but I'm not expert enough at bugzilla searches to find them.

Adding a new paper size in Windows is still done in Control Panel, not in Settings. Go to this page, and select a printer (hover, not click, or click once instead of twice).

Then you can create a new form, and dimension it below in either metric or english units. I used metric for this project.

Here are the dimensions I used.

results from 72 branch, look OK

results from 73 branch are scaled differently, but shouldn't be

Whoops, prior from73.pdf was the wrong file. This is the right one.

These are "just" the crop marks, which are in the top iframe, but scaled wrong. The content of the page is not included in these files.

Comment 5 and its attachment could be deleted, if there is a way to do that.

Maybe problem 3 doesn't exist... I'm getting content on the pages now, but in the wrong scale as shown by this bug.

Unfortunately, I'm having difficulty coming up with a test case; my actual case depends on a local server with specific functionality to get things loaded.

I'd really like a list of the changes made to 73 branch that were not in 72 branch, to see if one of them stands out as a possible cause. Otherwise, I'm just throwing darts at what possible features I'm using that might have changed, that I should include in a test case.

OK, I installed nightly to discover if this had been fixed based on other reports, and it hasn't, but while configuring Nightly to have a similar configuration, I missed one step, and happily it led to noticing point one. The other points are conclusions.

1. The bottom crop marks shown in my PDF files are longer than the top ones and the ones on the side. This is probably some sort of bug, because they shouldn't be. They are exactly twice as long as they should be, if printed on big paper or different zoom factors, but on small paper with the "right" zoom factor, they get cropped off so they aren't quite twice as long... I had noticed they were a little longer than the others even in branch 72, but it wasn't a big deal, so I hadn't investigated. On screen, they are the right length, this only happens during printing.

2. If the scaling calculations I had done one the output had compensated for the longer crop marks, rather than just measuring the total extent of the ink, then the horizontal and vertical scale factors would have been the same.

3. Now that they were perceived to be the same, I realized that the scale factor was exactly that I was using on the screen, but that when printing, I was setting a different scale factor around the call to window.print(). So it turns out that this bug is exactly the same as 1608018.

4. I don't have evidence yet whether the long crop marks are a bug in my code or in Firefox, but either way it can be separated from this bug: I'll submit another if it turns out to be Firefox.