Print preview is shown with the wrong paper size sometimes (on Windows 7)
Categories
(Core :: Print Preview, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox81 | --- | disabled |
| firefox82 | --- | fixed |
People
(Reporter: asoncutean, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [print2020_v82] [old-ui-])
Attachments
(3 files)
screencast issue.gif
Affected versions
- 82.0a1 (2020-09-14)
Affected platforms
- Windows 7
Steps to reproduce
- Launch Firefox
- Make sure print.tab_modal.enabled is set on true
- Go to http://example.org/
- Hit Ctrl + P
- Expand More settings and select Print backgrounds
- Switch between Destinations
Expected result
- The way the background is displayed stays constant
Actual result
- The way the background is displayed varies
Regression range
- First bad: 726130eb9a19a4a4619b33dc7fb02d1a25f3ca64
- Last good: b0add3579bcc35ed2bdf8749f230432acd8092b2
- Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0add3579bcc3
5ed2bdf8749f230432acd8092b2&tochange=726130eb9a19a4a4619b33dc7fb02d1a25f3ca64
Additional notes
- The issue is intermittent and is triggered also by opening the modal several times (with the same destination), having a different outcome
Suggested severity
- S4
|
||
Comment 1•4 years ago
|
||
Anca, can you please test with gfx.webrender.force-disabled=false?
If the issue doesn't happen with the pref setting, this issue should be a dup of either bug 1665064 or bug 1663344. (Bug 1665064 has already landed on autoland, hopefully it fixes this too!) Thanks!
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
Based on the screencast, it looks like "Save to PDF" shows one rendering and the network printer shows the other rendering -- is that right?
As far as I can tell, this seems to be sizing difference ("how much content fits on the page, and how much space is left over"). It is not a "did the background paint" difference, even though it kinda looks like that.
The website here (https://example.org) simply has a 600px-wide white-background div, centered in a <body> which has a gray background. And the GIF simply shows two legitimate layouts for that content (I'm only discussing portrait-mode, for simplicity):
*(Layout 1) With "Save to PDF" chosen, that 600px-wide-div exactly fits in the page width (or maybe it's too wide and is shrunk so that it exactly fits). This means there's no room for any gray area on the sides - the white div occupies the full width of the body.
*(Layout 2) With the network printer selected, the 600px-wide-div has more than enough space and there's room for some gray area around it (as there is when you view https://example.org in your browser.
(This would be a bit clearer if there were a border on the 600px-wide-div, probably.)
So the question here is: why are we seeing 2 different layouts? That is a bit of a mystery, since it looks like "A5/Shrink-to-fit" is chosen in both cases. Maybe the network printer simply has a higher DPI as compared to shrink-to-fit?
(The dimensions of the two purportedly-A5 pages look slightly different, too...)
|
|
||
Comment 3•4 years ago
|
||
Here's the piece of the screencast with "Layout 1" (where the background isn't visible at the top). You can see the rounded corners at the bottom of the white area, which is a hint that this content is simply filling the page width.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
|
|
||
Comment 5•4 years ago
|
||
So based on the pages' aspect ratios
- "Layout 1" here (for Save to PDF) seems to legitimately be A5.
(It's shown on a page with a ~0.70 aspect ratio, which is what A5 has, from 140x210mm. 140/210 = 0.70 approx.)
...BUT - "Layout 2" here (the network printer) is, in fact, being shown on a US Letter aspect-ratio page even though the dialog says "A5".
(It's shown on a page with a ~0.77 aspect ratio, which is what US Letter has, from 8.5x11in. 8.5 / 11 = 0.77 approx.)
So the bug here seems to be that we're lying about the Paper Size that we're previewing, I think.
|
|
||
Comment 6•4 years ago
|
||
(Clearing ni from comment 1 since the question there isn't relevant at this point I think.)
|
|
||
Comment 7•4 years ago
|
||
(For a same-units sizing comparison: A5's 140x210mm works out to roughly 5.5x8.25 in. So its longer dimension is a bit smaller than the skinnier dimension of a US Letter page. Given that: the layouts shown in the screencast are entirely reasonable -- the landscape-oriented A5 paper has a bit less width to work with than the portrait-oriented US-Letter paper, which is why there's no gray background visible in the landscape-oriented part of the screencast -- the white-backgrounded "main" div only barely fits & perhaps even has to shrink a bit.)
Anca, a few questions:
(1) Can you still reproduce this in latest Nightly?
(2) Do you know why A5 is being auto-selected as the page size when you switch printers (in your screencast)? (Is that your system/locale default somehow?)
(3) If you can still reproduce cases where the print dialog reports A5 and is showing you gray background at the top of the page ("layout 2" as in attachment 9176944 [details]): does this change if you switch to a different page layout & then switch back to A5? (I'm wondering if this is just a race condition while we set up the print-preview for a newly-selected printer, & some code isn't yet clear on what the desired page size is.)
|
|
||
Updated•4 years ago
|
|
|
||
Comment 9•4 years ago
|
||
(Jonathan Kew mentioned some paper-size handling has changed recently, so this might be fixed?)
|
|
||
Comment 10•4 years ago
|
||
Putting this as P1 because it seems that it could be worse than originally described (not just background but actually wrong paper size).
|
||
Comment 11•4 years ago
|
||
Hello Daniel,
Anca is on PTO right now, so I took the time to look into the issue.
(In reply to Daniel Holbert [:dholbert] from comment #7)
(1) Can you still reproduce this in latest Nightly?
No, I can no longer reproduce the issue in the latest Firefox Nightly. There is no additional gray area generated above the white div when switching back to the available printer.
(2) Do you know why A5 is being auto-selected as the page size when you switch printers (in your screencast)? (Is that your system/locale default somehow?)
My intuition tells me that she has that set up either in the modal window or at the printer level.
While switching to 'save to pdf' indeed does set the paper size to A5, switching back to the available printer reverts the size back to what the printer has the default set as (if it had a different size).
|
|
||
Comment 12•4 years ago
|
||
Thanks, Cristian! Sounds like perhaps this has been fixed, then? (or at least, we're not sure whether it's still reproducible)
Let's see if Anca can still reproduce when she's back from PTO; and if not, then it's likely this has been fixed by one of the changes that's been made in the time since the bug was filed.
|
||
Comment 14•4 years ago
|
||
Hi,
I was able to verify that the bug was fixed on Nightly version 83.0a1 (2020-09-26) (64-bit) on windows 7. (I first reproduced the bug on Nightly version from September 14th). I didn't change the flags because I wasn't sure if that was ok.
Regards, Flor.
|
|
||
Comment 15•4 years ago
|
||
Sounds like we can close this. But we should verify if this was fixed in 82 beta since we plan to ship the feature first there as an experiment first (seems likely since we've been uplifting most patches).
|
|
||
Comment 16•4 years ago
|
||
Flor, would you mind testing the latest 82Beta on Win7, to verify that this is fixed there?
|
|
||
Comment 17•4 years ago
|
||
Sure, give me some time to get the machine running and I'll test it.
|
|
||
Comment 18•4 years ago
|
||
Hi, so I tested it in 82.0b5 (64 and 32 bit) and it worked ok, it was fixed there too.
Regards, Flor.
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 20•4 years ago
|
||
|
||
Updated•4 years ago
|
Description
•