User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161104212021 Steps to reproduce: I am the developer of the Print Edit add-on. For a long time, Print Edit has had the ability to print a web page to a PDF file, using the Cairo library that is built into Firefox. However, since the release of Firefox 50.0, several users of Print Edit have reported to me that when they print to a PDF file, the landscape orientation setting in page setup is ignored. I can reproduce this behaviour consistently. I have checked through the Print Edit source code, and I have also checked on DXR for changes to printUtils.js and printPageSetup.js, but I cannot find anything that accounts for this problem. I have done some testing, which indicates that 'printSettings.orientation' is correctly set when browser.print() is called. As far as I know, the only places that the print to PDF feature in Cairo is used is in Print Edit and Firefox for Android. I suspect that this problem may be caused by changes to support Android or by changes following on from the changes made in Bug 1189846.

Bob, Are you aware of any changes that may have caused this problem? Printing to PDF from the parent process works fine with Firefox 49.0, but not with Firefox 50.0.

(In reply to dw-dev from comment #1) > Bob, > > Are you aware of any changes that may have caused this problem? > > Printing to PDF from the parent process works fine with Firefox 49.0, but > not with Firefox 50.0. Not between those two versions, no. A low integrity sandbox is now enabled on 50, but that shouldn't have affected printing via the parent. In fact that's why we originally implemented it. I'll leave the needinfo, to remind me to look into this.

I have done a lot more investigation of this problem, trawling through the source code of Firefox 49.0 and Firefox 50.0. Basically, Firefox 50.0 does not respect the orientation and paper-size print settings, whereas Firefox 49.0 does respect these settings. I have found changes in three files in Firefox 50.0 relating to printing in PDF format (kOutputFormatPDF): widget/android/nsPrintOptionsAndroid.cpp widget/gtk/nsDeviceContextSpecG.cpp widget/windows/nsDeviceContextSpecWin.cpp I suspect the changes in 'widget/windows/nsDeviceContextSpecWin.cpp' are causing the problem. Specifically, in line 255, I do not understand the effect of 'IntSize::Truncate(width, height)' Please can you confirm that this is the cause of the problem?

I have now walked through all of the relevant 'print settings', 'print options' and 'print as PDF' source code in Firefox 49.0 and Firefox 50.0 - and fully understand the cause of this problem. Print Edit is trying to save the previewed page as a PDF file by calling browser.print() with these print settings: printerName set to "", outputFormat set to kOutputFormatPDF, paperHeight/paperWidth & orientation set by the user. This works with Firefox 49.0 (and earlier) and the paperHeight/paperWidth & orientation print settings are honoured. This also works with Firefox 50.0 (and later), BUT the paperHeight/paperWidth & orientation print settings are ignored. The only way I have found to make Firefox 50.0 honour the paperHeight/paperWidth & orientation print settings, when printing to a PDF file, is to set the printerName to a valid printer name (rather than ""). This works even though none of the print settings are set from the printer's settings. However, this feels like a kludge. Firefox for Android also saves a web page as a PDF file by calling browser.print() with printerName set to "", but does not set paperHeight/paperWidth & orientation, and so does not encounter this problem. In my opinion, it would be better if Firefox 50.0 worked the same way as Firefox 49.0, so that with printerName set to "", the paperHeight/paperWidth & orientation print settings are still honoured.

Forgot to mention - I have submitted Print Edit 17.6 to Mozilla for review and release. Print Edit 17.6 includes a workaround for this problem, which sets printerName to the default printer name, but this only works if there is a default printer name.

Sorry, I've taken a while to get to this, I was away at a conference all last week. OK, the issue here is a little more subtle than not allowing a blank print name. In theory this was always replaced with the default printer and things just tended to work because of other anomalies later on in the printing, not necessarily by design. The root of this problem is down to the changes I made to make the printSilent pref work when printing via the parent. These don't work properly when the settings haven't been pulled from the prefs originally. I think I can come up with a fairly simple fix for this as it stands and one of the next things I'm going to be working on is rewiring much of the print settings code, so that we don't touch the print device in the child.

Too late for firefox 52, mass-wontfix.

Hi, is this still an issue?

This bug report relates to my legacy Print Edit add-on. I ahve not had any recent reports from users of similar problems. I have just tested Print Edit in Firefox 56 (on Windows 10) and saving PDF's works in both Portrait and Landscape orientations. So, I think this bug can be closed.

Thanks