(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,<html style="margin:0; box-sizing:border-box;height:100vh;border:3px solid black"> ``` ...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? > 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. > 2. 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.)
Bug 1761843 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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? > 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. > 2. 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.)
(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. > 2. 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.)