The new print preview design calls for margin indicator lines to be displayed in print preview when the custom margin value fields are focused. We will need to implement platform support for this and a mechanism for the frontend code to enable them.

I imagine the lines will be implemented as anonymous content related to https://searchfox.org/mozilla-central/source/layout/generic/nsPageSequenceFrame.cpp , or rather nsPageFrame.cpp

This bug may be lower priority than some of the other platform work for the new design given that it is a visual enhancement to the design whereas other bugs are about functionality for the user.

(In reply to Jonathan Watt [:jwatt] from comment #0)

The new print preview design calls for margin indicator lines to be displayed in print preview when the custom margin value fields are focused. We will need to implement platform support for this and a mechanism for the frontend code to enable them.

Suggestion: we could expose a boolean attribute showMarginGuides on nsIPrintSettings, which the front-end code can set to true when it wants lines to appear and false (default) to suppress them. Would that be adequate for the front-end needs?

I imagine the lines will be implemented as anonymous content related to https://searchfox.org/mozilla-central/source/layout/generic/nsPageSequenceFrame.cpp , or rather nsPageFrame.cpp

I wonder if we can go lighter-weight than that, and just add the margin indicator lines at display-list-building time in nsPageFrame (without needing to create anonymous content at all). They'd be a purely transient paint-time embellishment of the rendering. Or is there a specific need to have anon content associated with them?

If this seems a workable approach, I think I could find cycles to put up a simple patch.

Daniel, jwatt suggested I should check with you about this. Any thoughts on the above? Do we know more about what the front-end requirements may be?

I think jwatt mentioned that we might want the lines to be interactively-draggable at some point (not in v1 maybe but in some future version). For that to work, I think they'd need to be something drawn/controlled by the frontend code.

Also, this feels a lot like our CSS Grid Highlighter devtools feature, where we have a platform API to return the positions of "virtual" lines/areas on the page (not the positions of actual elements -- grid lines are a layout abstraction but don't have any content-box/margin-box/etc. associated). And then devtools JS uses this API and goes ahead and draws the lines on-screen. (In that case, I don't think the lines are draggable, but they could be in theory, given a way to communicate back "here's the new position we want for this line" or whatever.)

So we might want to use that API for inspiration.

Having said that, maybe doing a display-list hardcoded thing (with just on/off) is good for the first pass here.

Thanks, that makes sense.

I'm inclined to suggest we do the simple thing as an immediate solution, just adding a showMarginGuides attribute that triggers a simple rendering of guide lines, with the understanding that it could be replaced with a more advanced mechanism in a future version if there's a desire for that. That should make it trivial for the front-end to enable this; all they'd have to do is set the flag (and call bug 1653340's updatePrintPreview).

If/when the front-end people want to adopt an approach where they handle the drawing (and potentially support direct interaction with the lines), we could drop the showMarginGuides attribute and painting support, and instead expose the coordinates at which to draw.

Depends on D84158

https://hg.mozilla.org/mozilla-central/rev/bc3193ad9b66
https://hg.mozilla.org/mozilla-central/rev/1b33cf4206f6