Closed Bug 1681183 Opened 4 years ago Closed 2 years ago

Tab-modal print dialog's "Margins: None" option should allow users to print with page margins actually set to 0, regardless of unwriteable area

Categories

(Core :: Printing: Output, task)

Product:
Core
Component:
Printing: Output
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
105 Branch
Tracking Flags:
Tracking Status
firefox105 --- fixed

People

(Reporter: dholbert, Assigned: dshin)

References

Details

(Keywords: parity-chrome, Whiteboard: [print2020])

Attachments

(1 file)

Bug 1681183: Ignore unwriteable margins user specifies `Margins: None` for printing. r=#layout-reviewers
(deleted), text/x-phabricator-request
Details

STR:

  1. View a testcase that tries to print right up to the actual edge of the page, like this one:
data:text/html,<body style="margin:0"><div style="border:1px solid;height:400px ">abc
  1. Ctrl+P to open the print dialog.
  2. Under "Destination", choose a real physical printer (not print to PDF)
  3. Expand the "More Settings" section.
  4. In the "Margins" dropdown, choose "None"
  5. Print (or just look at the print preview rendering)

ACTUAL RESULTS:
The page is printed (and shown in print-preview) with some margins, despite my choice of "Margins: None". (I think we're setting aside some space for the printer's "unwriteable margins", probably?

EXPECTED RESULTS:
The page should be printed (and shown in print-preview) with literally no page-margins. This should probably mean that the text and/or borders are clipped along the top and sides of the page.

Chrome gives EXPECTED RESULTS.

Our behavior here for "Margins: None" seems to behave exactly the same as "Margins: Minimum" (and matches how I would expect Minimum to behave), where "Minimum" is interpreted as "minimum without any clipping" and None means "literally no margins, which may produce clipping, which is fine".

We need EXPECTED RESULTS in order for people to be able to print out precisely measured content, with e.g. a div that's reliably 4in from the left of the page.

(This might be slightly off-topic for this bug, but I'll record it here for the record anyway.)
Fwiw, the spec has a concept of printable/non-printable areas: https://drafts.csswg.org/css-page/#printable-area
After a quick glance over the sections that mention margins I get the impression that it assumes margins are always inside the printable area.
If neither we, nor Chrome, has implemented it like that then it's probably worth filing a spec issue summarizing what browsers are actually doing and try to reach consensus on a model that we all can implement interoperably. It must be rather annoying for authors to have to deal with getting different results in different browsers.

I think what you're proposing above is that we converge on Chrome's behavior? That seems fine to me, but we should get that documented in the spec as well.

Keywords: parity-chrome
Whiteboard: [print2020]

(In reply to Mats Palmgren (:mats) from comment #1)

I think what you're proposing above is that we converge on Chrome's behavior?

Yeah, I think so.

That seems fine to me, but we should get that documented in the spec as well.

(Agreed.)

Assignee: nobody → dshin
Status: NEW → ASSIGNED

Two things that we have to probably make a decision about before we proceed here...

(1) It looks like the Chrome print dialog's custom-margins:0 0 0 0 setting also prints content right up to the edge of the page (gleefully drawing into unwriteable area area and getting clipped as a result). Whereas in the Firefox print dialog, custom margins:0 0 0 0 gets shifted in to accomodate unwriteable area. If we're aligning with Chrome on what "None" meants w.r.t. the unwriteable area, we might want to consider aligning on the explicitly-zero-margins scenario as well (or make sure we've documented the distinction & made sure it's intentional).

(2) If we do want to create a behavioral distinction between "Margins:None" vs. "Margins: Custom/0-0-0-0" (as I was initially proposing in this bug), we've got a bit of a problem, because we seem to represent them both the same way in the saved state in about:config, and we restore them both as "Margins:None" the next time you open the print dialog.

Safari doesn't seem to let me customize the margins in the print dialog at all. Their print dialog (the system print dialog) lets me create a custom "paper size", with "Margins:User Defined", but zero margins there seem to get floored to the printable area when I actually print.

(Large margins there seem to get ignored, too, interestingly, in Firefox and Safari, though not in Chrome! I'll spin off another bug for that. [EDIT: done, filed as bug 1781947])

Summary: New print dialog's "Margins: None" option should allow users to print with page margins actually set to 0, regardless of unwriteable area → Tab-modal print dialog's "Margins: None" option should allow users to print with page margins actually set to 0, regardless of unwriteable area
Attachment #9287279 - Attachment description: Bug 1681183: `Margins: None` print option ignores unwriteable margins. r=#layout-reviewers → Bug 1681183: `Margins: None` or `Custom` with all zeroes ignore unwriteable margins. r=#layout-reviewers

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?

Flags: needinfo?(dshin)

At this moment, pdf.js looks to be using @page { margin: 0; }, which we honor, ignoring unwriteable margins (Though see bug 1681206), so we're printing things like e.g. smartwatch sizing guide, to-scale documents like PCB layouts, etc. Most of printables where scale matters at least seem to be PDFs. so that's good. If there is a need outside of avoiding scaling down PDF files, I am not sure. I've checked an online CAD app, online LaTeX editor, wall poster generator, etc, and they all seem to generate PDF files.
However, if any option apart from Default was persisted through a previous print interaction, we will nudge and scale the PDF document out of unwriteable margins, which does not seem ideal. Filed bug 1782240.

So.. Overall, reason 2) being low priority, and 3) being addressed for the time being with "Margins: Default" (+ bug 1782240), it's also an option to simply remove "Margins: None" option, which is a lot less complexity but less futureproof, potentially

Flags: needinfo?(dshin)

Just to butt in here with a drive-by opinion: I feel (pretty strongly, actually) that explicitly-specified margins, whether 0 or non-zero, should be honoured as specified, and not adjusted to force them within the printable area. ISTM this is the only readily-understandable behavior that will allow users to accurately control printed output, when they care about doing so.

The "Default" margins should be well inside the printable area for any normal device, and "Minimum" should fit the content right up to the edges of the printable area for the chosen device. But any explicitly-specified value (whether zero or not) should measure from the (fixed) edge of the page, not from the (output-device-dependent) edge of the printable area.

One concern I have with changing the meaning of custom margins is the persisted value that users set previously suddenly changing meaning. I entertained the idea of adding a checkbox for "Have this margin value ignore unwriteable margins," but that's admittedly clunky. Perhaps the impact could be dampened if e.g. if we can inform users "Hey, you're about to clip content"/overlay current & unprintable margin/etc? That's a lot more work, but it could also help users self-diagnose some issues where margins get messed up.

I agree it'd be nice to have a way to warn users if they set custom margins that imply content will be clipped, but I'd like it to be as lightweight (in terms of disruption to the user's workflow) as possible. What I imagine -- with no thought for how easy or not it'd be to implement -- is that we might do something like overlay faint red guidelines on the preview to indicate the limits of the printable area, perhaps only if the current margin settings are such that the content extends into the non-printable margins.

In reply to David Shin[:dshin] from comment #7)

At this moment, pdf.js looks to be using @page { margin: 0; }, which we honor, ignoring unwriteable margins (Though see bug 1681206)

Aha, right. I had forgotten that "Default" existed & was special here.

So this mitigates my concern (3) to some extent ("..we really do need to offer a true "Margins:None" option") -- we do offer such an option, but we just call it "Default" instead of "None"; and "None" does something quite-different-from-what-you-might-expect.

However, if any option apart from Default was persisted [...] we will nudge and scale the PDF document out of unwriteable margins, which does not seem ideal. Filed bug 1782240.

Thanks!

it's also an option to simply remove "Margins: None" option, which is a lot less complexity but less futureproof, potentially

That's hypothetically an option, yeah (particularly since "none" is just an alias for "0 0 0 0" and stored-as-such). I don't love that, but it'd be arguably more-coherent than our current setup where we have "None|Minimum" which are ~equivalent (and which makes "None" feel mislabeled).

(In reply to Jonathan Kew [:jfkthame] from comment #8)

I feel (pretty strongly, actually) that explicitly-specified margins, whether 0 or non-zero, should be honoured as specified, and not adjusted to force them within the printable area.

I somewhat agree -- that's concern (2) from comment 6 -- but I think we need to tread cautiously there since it's got a risk of causing dataloss/user-frustration from saved settings (in particular 0/0/0/0) suddenly causing clipping & dataloss when we make that hypothetical change. I also think we can potentially address this bug's "None" concerns separately & without that risk (e.g. via proposal in comment 6, or even via removing None as David noted).

So: I spun this custom-margin-handling question off to bug 1782268.

Combined with discussions on elements + fact that we want to look into custom margins ignoring unwriteable margins, agree that we should implement Margins: None as suggested by dholbert instead of getting rid of it.

mstriemer, just want to be sure this makes sense to you -- are you OK with special-casing "margins:none" here as uniquely-exempt from unwriteable margins for the time being? (See end of comment 6 for the proposal, and the rest of that comment for the motivation.)

Feel free to add yourself as reviewer on the patch if you'd like -- though mostly I'm just curious if you're OK with the high-level idea (not sure if we need to bother having you explicitly review, unless you want to).

Flags: needinfo?(mstriemer)

Setting this for None works for me. We might be able to set it as well for Custom which should only trigger when the margins are updated, but that could still result in some weirdness for users so I'm good with looking in to that in bug 1782268

Flags: needinfo?(mstriemer)
Attachment #9287279 - Attachment description: Bug 1681183: `Margins: None` or `Custom` with all zeroes ignore unwriteable margins. r=#layout-reviewers → Bug 1681183: Ignore unwriteable margins user specifies `Margins: None` for printing. r=#layout-reviewers
Pushed by dshin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/46226656faef
Ignore unwriteable margins user specifies `Margins: None` for printing. r=dholbert,mstriemer

https://hg.mozilla.org/mozilla-central/rev/46226656faef

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox105: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: