Closed Bug 1761843 Opened 3 years ago Closed 1 year ago

Print Preview Interface alters user's default printer settings as specified in about:config causing headers and footers to be outside printable range of printers.

Categories

(Toolkit :: Printing, defect)

Product:
Toolkit
Component:
Printing
Version:
Firefox 98
Platform:
x86_64
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1669910

People

(Reporter: jdxtr, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #1695166 +++

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

) I updated FF to 85.0.2 on my iMac desktop computer with OS 10.13.6. This FF update contains the new print preview interface feature. This feature was not available in any of my prior FF updates.

  1. I went to print a webpage and discovered that my headers and footers that normally print out at the top and bottom of each printed page were not fully visible on the printed pages.

Actual results:

  1. The headers are positioned too high and the footers are positioned too low so they are cut off all printed pages and are no longer clearly visible at the top and bottom of each printed page. Only an indecipherable edge of the header and footer text is visible across the top and bottom of each printed page now.

  2. The headers and footers are cut off of every printed page regardless of whether I use FF's print preview interface to print, or whether I click the link in FF's interface to "Print using system dialog..." which bypasses FF's interface and opens the computer's print window instead.

  3. I went into about:config and discovered that the unwriteable top and bottom margin settings that I had previously set to 25 were altered to 17 after this update containing FF’s new print preview interface. The narrower setting of 17 caused the headers to be positioned too high and the footers to be positioned too low on the page, placing them beyond the printable range of all my printers. As a result, the headers and footers were cut off all printed pages.

  4. I went to the print.printer settings in about:config and manually changed the unwriteable top and bottom margins back to my user specified setting of 25. I saved the changes in about:config and shut FF down so those changes could take effect.

  5. I reopened FF and went to a webpage. I tried to print the page using FF's print preview interface and also by clicking the link within the interface to "Print using system dialog." Regardless of which method I used, the headers and footers were still cut off all the printed pages.

  6. I went back into about:config and discovered that the unwriteable top and bottom margin settings that I had manually changed back to 25 had inexplicably reverted to 17 again which explains why the headers and footers were still cut off the printed pages.

  7. FF is overriding my user print.printer settings in about:config and setting the unwriteable top and bottom margin settings at 17 which places the headers too high and the footers too low on each page where they cannot be printed since that area exceeds the printable range of most printers.

  8. I had no choice but to disable FF’s print preview interface in the about:config settings so I could permanently restore the unwriteable top and bottom margin settings of 25 that I previously had set so my headers and footers could print out fully on all documents just as they always used to.

Expected results:

  1. The new print preview interface that is featured in FF for printing should not override the user’s previously set personal print.printer settings in about:config. The user’s settings should always have priority.

  2. If FF’s print preview interface has default unwriteable printer margin settings that it wants to use with its print preview preference, but the user changes those settings to accommodate the proper placement of headers and footers in consideration of their printers’ characteristics, the user’s preferences in about:config should take priority and hold.

  3. My hope was that by manually changing the top and bottom unwriteable margins back to 25 in about:config and shutting down FF to enable those changes to take place, that this action would permanently override FF's default setting of 17 for the unwriteable top and bottom margins so I could make use of the new print preview interface, but that is not the case. FF continues to override my personal print.printer settings in about:config.

This behavior continues in FF 98.0.2 running on Windows 10. This may have been resolved for Save to PDF, but the problem still happens for Canon MX920 printer. Changing the value of print.printer_Canon_MX920_series_Printer.print_unwriteable_margin_bottom_twips
to a value that keeps footers inside the printer's printable area works consistently when only the system print dialog is used. However, as soon as the Firefox Print Preview UI is used to print, the value is set back to 286 twips again, causing the bottom half of footers to be cut off.

Hey Emilio, looks like the printing code is likely setting the unwriteable margin from the printer. Have you seen this before? Is there a known workaround or a dupe on file?

Flags: needinfo?(emilio)

Yes, so... This is the code that reads the unwriteable margins from the printer: https://searchfox.org/mozilla-central/rev/1ca8ea11406642df4a2c6f81f21d683817af568d/widget/windows/nsPrinterWin.cpp#135-139

When switching paper sizes and so on presumably the UI saves the paper id and unwriteable margin here, but maybe it doesn't have to?

The unwriteable margins come from the paper ID, so as long as we use the right paper id then the unwriteable margin should be good.

But anyways, the root problem is that for that printer the margin we compute seems wrong, I'm not sure if that is because the printer driver is bogus, or our calculation is off somehow.

Flags: needinfo?(emilio)

Seems like this might be an issue with the configuration of your printer. Perhaps there's a way to change the unwriteable margins with the printer?

I'm also curious if this is something that's happening in other browsers. That could help identify if it's a general printer issue or something with Firefox.

Another option could be that there's another paper type that would work correctly. My printer has a US Letter and US Letter (Borderless) size, perhaps there's another one that works correctly?

We could theoretically do something to use the unwriteable margins that are in prefs if they exist, but this is likely to cause other bugs with the way we store the data since it isn't tied to a specific paper type.

Let us know how this goes and we can investigate some more, thanks!

Flags: needinfo?(jdxtr)

I see nothing in any of the printer configuration options that offers borderless printing for anything other than photographs.
After doing some research on this printer, I am, however, going to amend my report somewhat.
Canon says the unwriteable margins are:
Top = 0.12 in = 3.0mm = 173 twips
Bottom = 0.20 in = 5.0mm = 288 twips
Left = 0.25 in = 6.4mm = 360 twips
Right = 0.25 in = 6.4mm = 360 twips

The corresponding Firefox parameters in print.printer_MX920_series_Printer_unwriteable_margin_xxxxx_twips are 168, 286, 362, and 362.
Not precisely equal to Canon's specification, but should just cut off only 5 twips from the bottom of the footer. Instead it cuts off about 70% of the footer. So FF is printing the footer partially into the unwriteable margin even when the unwriteable_twips configuration is very close to what's needed. That's one issue I failed to note earlier.

My original problem was that I can correct this problem by specifying a larger unwriteable bottom margin (like 368, for example) in FF and the footers print properly when I use the system print UI. But, if I use the FF Print Preview UI, FF changes this parameter back to 286 and the footers are cut off again. FF should leave my changes alone.

To summarize the two problems:

  1. FF attempts to print footers part way into the unwritable_margin_bottom_twips specified even when that parameter is correct for the printer.
  2. FF Print Preview UI changes user modified specifications of unwriteable margins back to some FF default every time it prints.
Flags: needinfo?(jdxtr)

One additional thing. I physically measured the point at which the bottom footers are cut off, and it is at exactly 5.0mm above the bottom edge of the page, so Canon is being accurate in thus specifying the unwriteable bottom margin.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(mstriemer)

So we save the unrwiteable from what we get from the printer because there were a lot of cases where it was wrong. I'm a bit unsure about allowing it to be set from prefs. It isn't tied to a paper size, so basically you'd be forced in to managing it yourself and any time you change papers you'd get weird prints.

@jwatt it seems like maybe the headers and footers are incorrectly positioned here for some reason. If the unwriteable margin is off by 5 twips that should be < .1mm right? Any ideas?

Flags: needinfo?(mstriemer) → needinfo?(jwatt)

(In reply to John Larson from comment #4)

I see nothing in any of the printer configuration options that offers borderless printing for anything other than photographs.

For what it's worth -- I don't know if this was present when you posted comment 4, but these days In the Firefox print-preview dialog, you can choose "margins: minimum" to get your page content printed right up to the edge of the printable area.

You can use that, with a testcase like the following...

data:text/html,<body style="margin:0"><div style="box-sizing:border-box;height:100vh;border:3px solid black"></div>

...and with header/footer un-checked in the print dialog, to exercise the limits of your printer (or what Firefox understands them to be).

I wonder if you're still seeing this issue, with "margins:minimum" and that^ data URI testcase? (I imagine/hope maybe the issue has gone away in the past year or so, if there was something that's been fixed in Firefox or your printer driver or in an OS update.)

My original problem was that I can correct this problem by specifying a larger unwriteable bottom margin (like 368, for example) in FF and the footers print properly when I use the system print UI. But, if I use the FF Print Preview UI, FF changes this parameter back to 286 and the footers are cut off again. FF should leave my changes alone.

I don't think this is something we're going to change. We've encountered issues over the years with these about:config prefs being stuck on bogus values and completely breaking someone's print experience as a result. This could happen from a one-off issue with a printer driver giving us bad data, or the user inadvertently setting these about:config values and forgetting, or something else; but in any case, if we don't update these values based on what the printer actually tells us, then we're at the risk of having bad/broken values that are saved indefinitely there.

(This is less of an issue for other print settings like e.g. margins/orientation that are exposed and user-customizable in the print dialog. We could hypothetically expose these unwriteable margins there too, but the UX would not be great, for an application like Firefox that aims to provide a relatively simple print experience.)

The about:config prefs mostly just exist at this point for testing purposes (so that we can mock up fake values in automated tests to be sure that the rendering matches what we expect, for a particular set of values that we might get from a real printer in the wild). I don't think we intend-for/recommend-that users set custom values for them.

To summarize the two problems:

  1. FF attempts to print footers part way into the unwritable_margin_bottom_twips specified even when that parameter is correct for the printer.

Do you see this same issue from other applications printing to the same printer? As noted above, Firefox just uses the values that it gets back from the system printer info APIs -- so if we're having trouble here, I would expect that all applications would be having the same trouble, since they're working with the same information.

  1. FF Print Preview UI changes user modified specifications of unwriteable margins back to some FF default every time it prints.

(Yeah; as discussed earlier in this comment, this is intentional, to help avoid people getting stuck with severely broken print configurations, and probably not going to change.)

Flags: needinfo?(jwatt)

So, I believe the issue as-described in the bug summary ("Print Preview Interface alters user's default printer settings as specified in about:config") is the behavior that we intend at this point, per middle of comment 8.

The "...causing headers and footers to be outside printable range" part is not-intended, but it's not yet clear whether that's a Firefox-specific problem or not. (and maybe/hopefully it might've gone away?)

Severity: -- → S3

To answer the question posed in Comment 8, I do not see this same issue from other applications using this same printer. Specifically, Chrome does not have this problem, but FF 113.0.1 still has it. Does someone have any idea why that might be the case?

Thanks for the response! Just to clarify a few things:
(1) Do you see this clipping in Firefox if you load my data:... URI from comment 8 and choose "Margins: Minimum" in the print dialog? (with "Scale: fit to page width" or "100%", and "print headers/footers" unchecked). That testcase is meant to print a full-page black-bordered rectangle -- does the bottom border get cut off?

(2) Can you check if that happens in Chrome if you print that same data URI with the exact same configuration there? ("Margins: Minimum", headers/footers disabled, "Scale" set to default or 100%)

(I ask because, at least on my local printer, Chrome seems to print its footers somewhat distanced from the bottom edge of the writable area, though they print the headers smooshed right up against the edge. Firefox prints both smooshed right against the edge. So: if your system is wrong about the printer's unwriteable bottom-margins, you might not be able to tell from Chrome's footer placement -- but my data URI testcase printed with "margins:minimum" and no headers/footers should still be drawing to the extreme edges and should let you know.)

Re: Comment 11
Firefox cuts off the bottom border. Interestingly, Chrome cuts off the top border.

On my other printer, Canon ip8700, FF prints both top and bottom borders OK.

Thanks! Interesting/odd that Firefox and Chrome cut off opposite borders. The fact that both have some clipping, specifically with that printer, are a good sign that your system has some incorrect information about that printer's writeable areas. You might poke around at your system printer settings to see if you can find out anything there?

So I suspect there's not exactly a Firefox bug here. Though bug 1669910 would be a good step towards robustness against this sort of issue. (Bug 1669910 evolved a bit, but the bottom of bug 1669910 comment 6 encapsulates the idea -- "hey let's not draw the header/footer right at the bleeding-edge-extreme bounds of where we think we could possibly draw.")

I think :AlaskanEmily has some print-header/footer work planned, so this might end up being somewhat fixed by that?

Anyway: I think we can close this as a duplicate of bug 1669910.

Really, there are 3 kind-of distinct issues:
(1) the fact that we're ignoring/overwriting about:config prefs; that's 'wontfix' i.e. intended-behavior, to prevent users accumulating busted values there by accident and being entirely unable to print (as has happened in the past)
(2) the reporter possibly having a printer/print-driver that's returning wrong information, which is unfortunate but isn't something we can fix (we previously provided more configurable workarounds, but we've stepped away from that per (1)).
(3) ...but we can possibly get more graceful in the face of that possibility, which is what bug 1669910 is about.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1669910
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.