Closed
Bug 1681214
Opened 3 years ago
Closed 3 years ago
Users' print-dialog margin choices aren't respected, if the content uses "@page { margin: ... }"
Categories
(Core :: Printing: Output, task)
Core
Printing: Output
Tracking
()
RESOLVED
DUPLICATE
of bug 1661663
People
(Reporter: dholbert, Unassigned)
Details
(Keywords: parity-chrome, Whiteboard: [print2020])
Attachments
(1 file)
224 bytes,
text/html
|
Details |
STR:
- Load attached testcase.
- Ctrl+P to open print dialog (with
print.tab_modal.enabled
set to true, as it is in Nightly) - Open "More Settings"
- Try the various options under "Margins" (Default vs. Minimum vs. None vs. Custom) and see how they affect the preview rendering.
ACTUAL RESULTS:
The user's choice seems to be disregarded entirely. The rendering always uses 1.5in margins, regardless of the user's choice.
EXPECTED RESULTS:
If the user chooses "Default", we should honor the page's provided 1.5in page-margins.
Otherwise, if the user chooses "Minimal" or "None" or "Custom", we should honor what the user requested, and override the @page margin.
The "expected results" here are "expected" from the perspective of "respect the user's choices over the author's choices, where presentation is concerned", as well as from a webcompat perspective (Chrome gives EXPECTED RESULTS).
Reporter | ||
Updated•3 years ago
|
Whiteboard: [print2020]
Reporter | ||
Updated•3 years ago
|
Keywords: parity-chrome
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•