Bugzilla

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings for Margin, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a "no just print this us-letter PDF faithfully to a US-letter sheet" option.

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly get migrated to "Margins: 0 0 0 0" on Firefox upgrade, which might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content is getting clipped and how to avoid it.  So: this would be future-proof, aside from producing a slightly-more-verbose "Custom margin settings" dialog for users who have currently chosen "None".

What do you think?

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings for Margin, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a "no just print this us-letter PDF faithfully to a US-letter sheet" option.

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly start seeing "custom-margins: 0 0 0 0" on Firefox upgrade (which is how we've been representing their "None" anyway), and this might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change in terms of the actual print output -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content suddenly would start getting clipped [if they took that action] and how to avoid it.  So: I claim this approach would be ~future-proof, aside from producing a slightly-more-verbose "Custom margin settings" section in the print-dialog for users who have currently chosen "None".

What do you think?

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings for Margin, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a "no just print this us-letter PDF faithfully to a US-letter sheet" option.

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special exempt-from-clamping treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly start seeing "custom-margins: 0 0 0 0" on Firefox upgrade (which is how we've been representing their "None" anyway), and this might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change in terms of the actual print output -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content suddenly would start getting clipped [if they took that action] and how to avoid it.  So: I claim this approach would be ~future-proof, aside from producing a slightly-more-verbose "Custom margin settings" section in the print-dialog for users who have currently chosen "None".

What do you think?

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings available in our print dialog, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a "no just print this us-letter PDF faithfully to a US-letter sheet" option.

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special exempt-from-clamping treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly start seeing "custom-margins: 0 0 0 0" on Firefox upgrade (which is how we've been representing their "None" anyway), and this might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change in terms of the actual print output -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content suddenly would start getting clipped [if they took that action] and how to avoid it.  So: I claim this approach would be ~future-proof, aside from producing a slightly-more-verbose "Custom margin settings" section in the print-dialog for users who have currently chosen "None".

What do you think?

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings available in our print dialog, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for even if it causes clipping), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a "no just print this us-letter PDF faithfully to a US-letter sheet" option.

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special exempt-from-clamping treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly start seeing "custom-margins: 0 0 0 0" on Firefox upgrade (which is how we've been representing their "None" anyway), and this might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change in terms of the actual print output -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content suddenly would start getting clipped [if they took that action] and how to avoid it.  So: I claim this approach would be ~future-proof, aside from producing a slightly-more-verbose "Custom margin settings" section in the print-dialog for users who have currently chosen "None".

What do you think?

At a high level, there are a few overlapping but distinct issues to consider here:

(1) **Our margin options are effectively redundant right now, which feels silly/wasteful.**  We have distinct "Margins: None" vs "Minimum" settings available in our print dialog, and these do map to distinct behaviors under the hood -- but not in a user-visible-way, since we clamp the user's margin selections to "minimum" before we actually print.

(2) **We don't offer users any way to bypass our unwriteable-margin clamping behavior**.  It's not obvious to me that users really care about this for regular/traditional web content [except for as noted below in (3)].  It would be **theoretically** useful in a "div that's reliably 4in from the left of the page" scenario that I mentioned in comment 0, but I'm not sure how much people care about doing that sort of thing.  It might be useful to address this from an interop/competitive-landscape perspective, since Chrome trivially lets people bypass unwriteable-margin clamping (just honoring whatever margins users ask for even if it causes clipping), though I'm not sure whether that's a considered choice on their part vs. just doing-what-was-easy; and plus, Safari/WebKit seems to disregard user-specified margins entirely as discussed in bug 1781947.

(3) **For printing PDFs (and e.g. `@page{ size: letter }` web-content), we really do need to offer a true "Margins:None" option**.  If someone's printing a US Letter sized PDF onto US Letter paper, it's a bit silly for us to require that they scale down their PDF to 98% size to dodge the unwriteable margins; and we should give them a discoverable "please just print this us-letter PDF faithfully to a US-letter sheet" option (even if it's not the default).  In Chrome, user-selected "Margins:None" is how you do this (or one way to do this).

And whatever approach we take should ideally maintain some invariants:
(4) **Things should be coherent/understandable**.  Ideally we don't want to end up in a situation where e.g. changing the left-margin from 0.0" to 0.01" causes the right-margin to be reinterpreted & suddenly start getting clamped (which I think the currently-posted patch might do).  I'd rather not have that arbitrary-feeling action-at-a-distance.

(5) **Whatever we do here, we need to be cautious to avoid cases where a user has currently-working settings which suddenly start causing clipping/dataloss with a Firefox update.**  If we e.g. just trivially switched to chrome's not-clamping-custom-margins behavior, we would likely run into this problem for lots of users who may have set small custom-margins, or set "margins:None".

**Thoughts about these points**
I originally filed this bug on point (1) (when "None" and "Minimum" were added as newly-available-but-seemingly-identical options in our print dialog)

IMO point (2) is lowest-priority here; I'm not sure that's a real issue in practice.  (And to the extent that it is an issue or becomes one in the future, I think we could address it in the future.)  And I'm not sure that it's possible to address (2) without either adding more UI or violating concerns (4)/(5) to some extent.

**Suggested/possible way forward**
For now, I **think** we could address all the other points that I've mentioned by simply giving "None" special exempt-from-clamping treatment, using something like the `ignoreUnwriteableMargins` flag that you added in the initial patch here.  To ensure that it roundtrips properly, I think we would need to store this flag (or some indication that the user really chose `None`) as part of the print settings in our about:config prefs.  And if the user happens to just have `margins:0 0 0 0` without this new flag set, we would just restore that as custom `margins: 0 0 0 0`.

This would have the small downside that any users who **currently** have "Margins:None" selected would suddenly start seeing "custom-margins: 0 0 0 0" on Firefox upgrade (which is how we've been representing their "None" anyway), and this might be slightly-confusing/off-putting to them.  However, they wouldn't see any behavior-change in terms of the actual print output -- i.e. we wouldn't start clipping their content unless they actively/manually choose "None" again in the print dialog, at which point hopefully they'd have a clue about why their content suddenly would start getting clipped [if they took that action] and how to avoid it.  So: I claim this approach would be ~future-proof, aside from producing a slightly-more-verbose "Custom margin settings" section in the print-dialog for users who have currently chosen "None".

What do you think?