1745446 - Firefox 95.0 for Windows doesn't save Printer Page Orientation or query the Printer's Default Orientation

Status: REOPENED

(Core :: Printing: Setup, defect, P2)

Description

[alfadog]

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

Steps to reproduce:

In Windows 10, setup my printer to print "Portrait"
In Firefox, open a webpage
Click "Print"
Click "Print using system dialog..."
Click "Preferences"
Click "Portrait"
Click "Print"
Close the webpage.

Open another webpage.
Click "Print"
Click "Print using system dialog..."
Click "Preferences"

Actual results:

"Landscape" is selected, even though I have setup my printer defaults to "Portrait", and even though I have set the "Preferences" to "Portrait".

Expected results:

"Portrait" should still be the orientation.

I have confirmed this on 2 separate machines with 2 different brands of printer.

it used to save the settings selected in Firefox's "Preferences", but the orientation is no-longer saving.

Comment 1

[alfadog]

I've just been informed that this is happening on every station in my business.

Comment 2

[Patrick (he/him)]

I was able to reproduce this issue in Firefox 95 on Windows, but not in a fresh profile. If you go to about:config and change the preference 'print.printer_[printer name].print_orientation', e.g 'print.printer_Microsoft_Print_to_PDF.print_orientation' to 0, does this solve the problem?

Comment 3

[alfadog]

It does not solve the problem, nor does it create a viable workaround for the bug.
My users must manually select "Portrait" for several different installed printers whose default orientation is "Portrait".

Before submitting the bug report, I tried:

1. A fresh profile, which was unsuccessful because didn't read the default printer orientation.
2. Updating the printer orientation in about:config, but the setting was ignored.
3. Updating the printer orientation in prefs.js, but the setting was ignored.
4. Updating the printer orientation in User.js, but the setting was ignored.

None of the above would make the orientation save for subsequent prints, and none would make the orientation read from the printer defaults.

Even when I create a profile then write User.js with appropriate Orientation, the setting must be changed manually through "Print using system dialog...".

Comment 4

[alfadog]

Since you've confirmed the bug, could you change the status from "Unconfirmed", please?
The workaround for this bug requires training many employees.

Thanks!

Comment 5

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

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Daniel Bodea [:danibodea]]

I can't seem to reproduce this on my system, but I don't have an actual printer to test with, only the "Print to PDF" option.

What I see on my system is:

1. Open a new profile.
2. Load about:config
3. Check the value of print.printer_Microsoft_Print_to_PDF.print_orientation
   Notice: This preference is not yet created.
4. Load any random webpage
5. Click "Print"
6. Click "Print using system dialog..."
7. Click "Preferences"
8. Select "Portrait"
9. Click "Print"
10. Check the value of print.printer_Microsoft_Print_to_PDF.print_orientation
    Notice: This preference is created with value 0.
11. Close the webpage.
12. Open another webpage.
13. Click "Print"
14. Click "Print using system dialog..."
15. Click "Preferences"
    Observe: The "Portrait" orientation is selected by default, as intended.

Note: After the first print, the pref "print.printer_Microsoft_Print_to_PDF.print_orientation" is created with value 0, representing "portrait", as intended. It appears that the original issue can not be reproduced on my system (using the described steps).

@alfadog, could you help us investigate this issue as it appears to be specific to your work setup configuration?

I will do my best to explain how to do it:

1. For starters, we need to make sure it is, in fact, a regression; The information that will help us determine that are:
   a. Whether the issue reproduces in the latest nightly build. (Just download, extract, run and test in a new profile)
   b. Whether the issue did start reproducing in the later builds. If this is a newly reproducing issue, you should take a build for some time ago when it did not reproduce, like... let's say... 5 versions ago and retest the reported issue. If it's still reproducing, make sure by testing an even older build...
   c. If (in step b) you find an old build in which it does not reproduce, it means it's a regression and it could be properly investigated using the mozregression app.
2. Properly determine the build in which it started reproducing:
   a. Download, install and open the mozregression GUI app.
   b. Click the "Run a new bisection" button (cutting scissors icon in the top left corner)
   c. On "Basic configuration" screen just click "Next"
   d. On "Profile selection" screen just click "Next"
   e. On the Build selection screen you need to select the builds that were found to be "good" (not reproducing the issue) and "bad" (reproducing the issue.
   i. IF the issue reproduces in the latest nightly, just select today's date in the "First Known bad build"
   ii. IF the issue did not reproduce in the build from step 1.b, then you should input the date of 2021-07-11 at the "Last known good build" line.
   iii. IF the issue still reproduced in build from step 1.b, but did not in the build from step 1.c, then you should input the date of 2021-01-01 at the "Last known good build" line.
   f. Click "Finish"
   e. mozregression will run different nightly builds one by one and it will let you attempt to reproduce the issue and mark each loaded build as good or bad. When completed, this determines exactly when the issue was introduced and thus finding the culprit.
3. Copy the last few (~20) lines of information from the "Log" screen (especially containing words like pushlog, changelog, and bisection) and post them here.

Feel free to ask for further help regarding this issue. I will do my best to explain any part of the process.
I'm sorry for the wall of text; I'm here to help. Thanks!

Comment 7

[alfadog]

The issues on my machines showed up when 95.0 automatically installed via the Mozilla Maintenance Service.
Not all of my printers were affected.

ZDesigner printer driver, which is the driver for several different Zebra printers in my jurisdiction, is one such driver that would neither read the default orientation nor save orientation.

Another driver, Panduit TDP43ME, also suffered the bug.

Several other printer drivers on my systems worked fine.

I reverted all of my machines that use those printers to 91.4 ESR and the orientation issues disappeared.
I did not try the version previous to 95.0.

Apologies, but all of the machines in question are in a production environment, and cannot be regressed, or take the nightly build. They will remain on 91.4 ESR until it's obsoleted. I hope it's enough to help you find the source.

I appreciate your efforts!

Comment 8

[Mark Striemer [:mstriemer]]

alfadog confirmed this is working for them in v101 in bug 1389767, so it looks like this was fixed.

Comment 9

[alfadog]

Hi ya... My production machines just automatically updated from 91.4ESR to 102ESR.
They are now experiencing the bug that surfaced with FF95.

Here's my setup:
Printer: ZDesigner GC420t (EPL) (A VERY common POS printer driver)
Printer Driver: https://www.zebra.com/us/en/support-downloads/printers/desktop/gc420t.html
OS: Win 10
FF: 102ESR

Orientation for the above printers will not save. Each time I use this printer with Firefox, I have to click "Print using the system dialog" and set it up each time. There are other printers that demonstrate this behavior in FF, but this one specifically should be enough to troubleshoot.

The problem does NOT exist in 91.4ESR
and DOES exist in 95.0. (My first discovery)
and DOES exist in 102ESR.

I see bug 1389767 and bug 1745446 are marked as a duplicates of each other. I posted to both.

Thanks,
Alfadog

Comment 10

[alfadog]

It occurs to me that you might not be able to install a printer driver without a printer.

Maybe this is a clue:
In the FF v95+ Print GUI, there's no fast toggle for orientation for these printers that are having this issue.
My guess is that FF is erring while trying to query/set these printers' orientation.

Comment 12

[Mark Striemer [:mstriemer]]

Emilio, do you know what sort of logs could be helpful here? Looks like this issue is still happening

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I don't think the relevant "get the orientation from the printer" code has logs looking at this. We could try to add some... The main thing to figure out is whether we're getting the data correctly and mishandling it or we're getting the data wrong in the first place... if you paste this in the browser console, what do you see?

var printerList = Cc["@mozilla.org/gfx/printerlist;1"].getService(Ci.nsIPrinterList);
var printers = await printerList.printers;
printers[0].name; // Make sure it's the printer you want
var info = await printers[0].printerInfo;
info.defaultSettings.orientation

Comment 14

[Daniel Bodea [:danibodea]]

I believe this question is meant for the reporter.

Comment 15

[alfadog]

Sorry for the late reply, I was just passing thru and saw your request.

When I paste this into the console on my current win11 FF102.5esr:
var printerList = Cc["@mozilla.org/gfx/printerlist;1"].getService(Ci.nsIPrinterList);
var printers = await printerList.printers;
printers[0].name; // Make sure it's the printer you want
var info = await printers[0].printerInfo;
info.defaultSettings.orientation

It returns this:
Uncaught (in promise) ReferenceError: Cc is not defined
<anonymous> debugger eval code:6
<anonymous> debugger eval code:12

Comment 16

[alfadog]

Interestingly, the new FF Print GUI after 91.4esr doesn't show any orientation for certain thermal printers. And when I adjust orientation through the Windows GUI, it doesn't save. I'm a coder, so I would likely start looking at the differences between 95 ( where I first noticed the bug ) and whichever pushed release came before it. And since the bug seems to appear in the Firefox Print GUI, I would likely start looking for changes in that module between those two versions.

When 95 came online, at-least 2 brands of thermal printer stopped honoring the orientation settings in the printer, and stopped saving them.

All of my production machines are currently on 91.4esr, which has been obsoleted. Last week, somebody accidentally upgraded a FF to 102esr, and like clockwork, the orientation bug re-appeared. I re-installed 91.4esr, and like clockwork, the bug disappeared again.

Comment 17

[alfadog]

I consider Firefox's printing capabilities to fall under "Major Functionality".
I have 7 production machines relegated to 92.1ESR which is obsolete, because there is not a viable workaround for this bug.

Would you please consider upgrading the severity of this bug to S2?

Thanks!

Comment 18

[alfadog]

I just realized that the "needinfo" flag is checked.
I'm posting here to clear it, as all the information that has been requested was posted above.

Thanks!

Comment 19

[Daniel Bodea [:danibodea]]

The information requested from the reporter has been provided.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

(In reply to alfadog from comment #15)

When I paste this into the console on my current win11 FF102.5esr:
var printerList = Cc["@mozilla.org/gfx/printerlist;1"].getService(Ci.nsIPrinterList);
var printers = await printerList.printers;
printers[0].name; // Make sure it's the printer you want
var info = await printers[0].printerInfo;
info.defaultSettings.orientation

It returns this:
Uncaught (in promise) ReferenceError: Cc is not defined
<anonymous> debugger eval code:6
<anonymous> debugger eval code:12

You need to paste this into the firefox console, not the website's console. So Ctrl+Shift+J or the browser console.

(In reply to alfadog from comment #16)

Interestingly, the new FF Print GUI after 91.4esr doesn't show any orientation for certain thermal printers. And when I adjust orientation through the Windows GUI, it doesn't save. I'm a coder, so I would likely start looking at the differences between 95 ( where I first noticed the bug ) and whichever pushed release came before it. And since the bug seems to appear in the Firefox Print GUI, I would likely start looking for changes in that module between those two versions.

Well, the GUI code is here but was pretty much rewritten on 95. If you're interested, the print preview code is here and here, but the back-end code that provides data is here.

Comment 21

[alfadog]

Hi, thanks for the reply.

I'm not qualified to find the bug, but I am willing to provide a printer and drivers to whomever needs it to write this bug out. My company's future with Firefox depends on it.

I had never used "Ctrl+Shift+J"; thank you for the primer.

When I run the code provided, it returns 0. No printer name is returned. This is a copy/paste of the Browser Console Log:

var printerList = Cc["@mozilla.org/gfx/printerlist;1"].getService(Ci.nsIPrinterList);
var printers = await printerList.printers;
printers[0].name; // Make sure it's the printer you want
var info = await printers[0].printerInfo;
info.defaultSettings.orientation
<- 0

However, I got the printer.name using alert(printers[0].name) ("XPS Document Viewer"), and observed that the default orientation was "Portrait"
I then changed the default to "Landscape", and ran the code again, and it still returned zero. I repeated the test on 2 other printers, and both returned zero regardless of default printer orientation.

Should info.defaultSettings.orientation change from zero after I change the default in Windows?

Comment 22

[alfadog]

BTW, the above was run on 102.6.0esr.

Good day :-)

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Yeah, what I wanted to indicate with printers[0].name; // Make sure it's the printer you want is that you should change the 0 for the index you want that selects your printer.

I don't think we'd expect the printer information to reflect windows settings live. But after a restart it should reflect the default orientation indeed.

Comment 24

[alfadog]

I ran the below program on several printers, adjusting the Windows Orientation in between restarts, and FF worked as expected.

var printerList = Cc["@mozilla.org/gfx/printerlist;1"].getService(Ci.nsIPrinterList);
var printers = await printerList.printers;
var outText = "Choose a printer to query:\r\n\r\n";
printers.forEach(
function(prtr, ix){
outText += ix + ": " + prtr.name + "\r\n";
}
);
var ixP = prompt(outText, 0);
var info = await printers[ixP].printerInfo;
alert(printers[ixP].name + "\r\nDefault orientation: " + info.defaultSettings.orientation);

So I looked into the CSS of my page, and discovered that the following CSS disables the orientation button in 95+, but not in <95.

@page { size: 4.000in 1.000in; }

Is this a bug?

Comment 25

[alfadog]

I've done a little more research on this. It's not printer-specific; that was a red herring. But with your guidance, we have discovered the following in FF95+:

With this css, there is no Orientation option in the print gui.

@page { size: 4.000in 1.000in; }

With this css, the Orientation buttons show up, and Portrait is selected in the print gui.

@page { size: 4.000in 1.000in portrait; }

With this css, the Orientation buttons show up, but for some reason, Portrait is selected in the print gui instead of Landscape.

@page { size: 4.000in 1.000in landscape; }

I didn't actually see an example here of a length, width and orientation.
https://developer.mozilla.org/en-US/docs/Web/CSS/@page/size

Thanks!

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Ah, no, that's expected, we didn't support @page { size } before. So I think this is working as expected then. Emily can you confirm?

Comment 27

[Emily McDonough [:alaskanemily]]

This looks expected. Specifying a page size as two dimensions and also having landscape/portrait is actually malformed. The landscape/portrait in a page-size is for modifying paper names, or indicating an orientation and no size at all.

As per spec: https://drafts.csswg.org/css-page-3/#page-size-prop

Because laying out a page with a specified size/orientation on the wrong orientation would mean scaling the content down to fit on an incorrectly oriented piece of paper, we disable the toggle. The alternative is wondering why it seems like the orientation selector isn't working, as the page content itself wouldn't have different content/scaled dimensions.

It is possible we should have a "do not use CSS page size at all" checkbox, which would ignore any page-size and allow changing orientation. This has been discussed in the past.

Comment 28

[alfadog]

Thanks for the reply.
A couple of things come to mind.

Firstly, this page says @page:size is not supported by FF. Shouldn't FF leave it alone (like it did <95), especially in an esr?
https://developer.mozilla.org/en-US/docs/Web/CSS/@page

Also, if it's working as expected, then shouldn't the below set the toggle to landscape (which it does not seem to be doing)?

@page { size: landscape; }

The toggle is visible, but set to portrait.

Comment 29

[Emily McDonough [:alaskanemily]]

Ah, the MDN documentation is out of date on that one. It has been supported and enabled by default since Firefox 95.

Can you post a complete HTML document that shows the orientation not being set in the print preview UI? Thanks!

Comment 30

[alfadog]

Hi Emily,

I cannot reproduce the error and I know why. The following is invalid syntax, thus causing FF to ignore it, thus showing the Orientation Selector:

@page { size: 4.000in 1.000in landscape; }

I believe this is near resolution now.

As soon as the documentation reflects FF's support, and as soon as the documentation indicates that the Orientation Selector (and whatever else) will become invisible if the @page selector is used (Chrome and Edge do that, too), I believe this loophole will be closed.

Thanks everyone!