Open Bug 1679041 Opened 4 years ago Updated 1 year ago

Firefox doesn't allow page layout area to be inflated with negative @page margins

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
Desktop
All
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- fix-optional

People

(Reporter: russell.g.palmer, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [print2020])

Attachments

(5 files, 1 obsolete file)

Test case html page to demonstrate issue
341 bytes, text/html
Details
Correct Output from Firefox-82.0.1
5.76 KB, application/pdf
Details
Incorrect Output from Firefox-83.0
6.50 KB, application/pdf
Details
testcase 2 (just a div with negative @page margin on the bottom)
359 bytes, text/html
Details
testcase 3: negative page margins on all sides
3.42 KB, text/html
Details
Attached file test.html (obsolete) —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Using Firefox 83.0 on Archlinux, I opened the following html in the browser and attempted to print on A4 paper (same result on real printer or pdf) :
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
div.thing {
width: 10cm;
min-height: 50cm;
background: red;
border: black dashed 3px;
transform: scale(50%);
transform-origin: 0 0;
}
</style>
</head>
<body>
<div class="thing">This is a test div</div>
</body>
</html>

Actual results:

The red div has dimensions 10cm wide x 50cm tall, reduced to half size by the css transform scale(50%) so should fit on a single A4 page. It is displayed correctly on screen but is split onto two pages when printed, corresponding to where it would be split before the css transform was applied.

Expected results:

One red rectangle should have been printed 5cm wide and 25cm tall on one A4 page. This behaviour has been correct since about 10 years ago until I upgraded last week. The bug described here was introduced somewhere between versions 81.0.2 and 83.0.

In my experience, on both Ubuntu 20 and Windows 10, the print preview would show the HTML above on 2 pages, just like it would show it in a printed version (I used print to PDF). I do not understand how the scale transformation code line should work, so I will set this bug's component to one that relates CSS and leave it to be investigated by a person with more information on the matter.

If the component is incorrect, please set the one you believe to be appropriate.
Also, NI me if there are testing investigations needed (with appropriate information do to so).
Thanks!

status-firefox83: --- → affected
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Attachment #9189507 - Attachment is obsolete: true

@danibodea :danibodea Thanks for looking into this. I think further testing is necessary but I'm afraid I have no idea what 'NI me' means?!

Since posting my original report, I have realized that I missed out an important style tag : the @page tag. I have updated the attached test.html file to include this tag. As far as I can see the issue is entirely related to this @page tag which appears to be completely ignored. For this reason, I think your component classification is probably correct.

Please ignore the code within my first comment and use the attached file instead. If somebody could explain how to edit my first comment to update that code too (or at least flag it as wrong), that would be great (but it looks like it's not possible?).

I have also attached two pdf files to demonstrate what I am seeing with printing from versions 81.0.2 and 83.0 of Firefox. In both cases, background images/colours are on for printing, and print margins are all set to 0, however, you should be able to reproduce this issue without either of these settings (in which case the rectangle will not be red, and the top may be clipped of due to print borders, but the entire rectangle should always appear only on one page).

NI means "need info" which is an internal abbreviation we use to request information (checkbox below the text box), but that was directed to a developer from the component I've set the bug on, not to you.

In any case, I have used your last test case to compare the result of Firefox Release v81 and Firefox Release v83 and I have noticed the difference you are talking about, however, the way it looks in Print Preview is always the same as it looks after being printed to PDF. (This is information for developers picking this up.

Considering this is a regression, I have performed a regression range investigation using mozregression and I have come up with this:

2020-12-09T23:32:12: INFO : platform_version: 82.0a1
2020-12-09T23:32:16: INFO : Can't find symbol 'eglSwapBuffersWithDamageEXT'.
2020-12-09T23:39:17: INFO : Narrowed inbound regression window from [202c4cce, e5d999b6] (4 builds) to [a153feae, e5d999b6] (2 builds) (~1 steps left)
2020-12-09T23:39:17: DEBUG : Starting merge handling...
2020-12-09T23:39:17: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=e5d999b6f07f3d8abb29d4a6117b5416f2141707&full=1
2020-12-09T23:39:29: DEBUG : Found commit message:
Bug 1665001 - Don't allow custom page margins to go under the unwriteable margin. r=jwatt
Differential Revision: https://phabricator.services.mozilla.com/D90231
2020-12-09T23:39:29: DEBUG : Did not find a branch, checking all integration branches
2020-12-09T23:39:29: INFO : The bisection is done.
2020-12-09T23:39:29: INFO : Stopped

Bug confirmed on Windows 10 and Ubuntu 20.

Status: UNCONFIRMED → NEW
status-firefox84: --- → affected
status-firefox85: --- → affected
status-firefox-esr78: --- → unaffected
Ever confirmed: true
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → Desktop
Has Regression Range: --- → yes

Ok, I'm not surprised by this response. I concur that negative page margins are a dirty hack and should never have been possible. When considered as a regression, your wontfix assessment is fair.

But what about the underlying bug for which I was using negative margins as a workaround?

By that I mean : If I create a box that is taller than will fit within the page margins, but I apply a CSS transform to scale that box so that it easily fits on the page, its bottom edge gets clipped to the page margins before the CSS transform is applied. In other words, if it is scaled by 50%, it gets clipped half way down the page, nowhere near the margins. The same issue does not occur horizontally, nor at the top edge.

The example code that I supplied above demonstrates this issue (the @page CSS directive is ignored by recent Firefox versions). I consider this a significant bug, which I was working around using a negative page margin hack. Should I create a new issue or will you consider reopening this one?

Thanks in advance for taking time to look into this.

Note that the wontfixes I did were with respect to specific releases, which is more a reflection of timing rather than the validity of the bug. Given that this bug is still status New, don't read too much into the version-specific flags :-)

Component: CSS Parsing and Computation → Printing: Output
Whiteboard: [print2020_v85]

Blake, Jonathan, is this on someone's radar for 85? There's no priority set and I'm not sure how much to trust the whiteboard flag :)

Flags: needinfo?(jwatt)
Flags: needinfo?(bwinton)

Since no-one is assigned to it, I don't think it's going to be done for 85, but I believe we've talked about it, so it's on our radar.
Since it's a platform bug, I'll leave it to jwatt to set the priority/severity.

Flags: needinfo?(bwinton)

I'm pretty sure that @page support hasn't changed in quite some time.

Keywords: regressionwindow-wanted
Whiteboard: [print2020_v85] → [print2020_v87]
QA Whiteboard: [qa-regression-triage]

Jonathan, I have provided a possible regression range in comment 6. Is it incorrect? Should I reinvestigate?

Keywords: regressionwindow-wanted

(In reply to Bodea Daniel [:danibodea] from comment #12)

Jonathan, I have provided a possible regression range in comment 6. Is it incorrect? Should I reinvestigate?

Ah, I missed that, thanks. That bug looks like it could indeed cause this.

Flags: needinfo?(jwatt)
Whiteboard: [print2020_v87] → [print2020]
Severity: -- → S3

Here's a tetstcase that gets to the crux here. CSS transforms aren't really relevant; the issue seems to be whether negative margins are allowed, and allowed to artificially inflate the "virtual" (ultimately clipped) size of the page.

This testcase has a -16in margin at the bottom of page 1.
Chrome (and presumably old-Firefox) accepts that and produces only 1 page of output as a result (clipping at the bottom of page 1).
Current Firefox seems to reject (or rather, clamp-to-0, I think?) this margin.

I'm not immediately seeing anything in https://drafts.csswg.org/css-page-3 about how to handle negative page margins, but presumably this is something that should be made clear in the spec...

Summary: Printing page clipping is being applied before css transform → Firefox doesn't allow page layout area to be inflated with negative @page margins
Version: Firefox 83 → Trunk

Chrome seems to honor negative page margins on all sides (not just the bottom).

So e.g. this testcase with @page { margin: -1in; } has content clipped on every side of the page. (The text begins off the top left corner of the page.)

Whereas Firefox seems to floors the margin to 0 (or probably to the printer's specified printable area, I think).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: