print preview failure when huge margins are specified
Categories
(Core :: Print Preview, defect)
Tracking
()
People
(Reporter: mahyaar.mohammadi, Assigned: emilio)
Details
Attachments
(5 files)
19.46 KB,
image/png
|
Details | |
23.90 KB,
text/plain
|
Details | |
589.95 KB,
video/mp4
|
Details | |
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
6.36 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36
Steps to reproduce:
Menu => Print => Page Setup => Margins & Header/Footer =>
Change the margin to 20 or higher number
Actual results:
The print Preview popup with "Progress: Preparing ..." was opened and not closed.
After closing and opening the browser, the issue remains.
![]() |
||
Comment 1•3 years ago
|
||
Mahyar,
Could you please attach results of about:support (Help –> Troubleshooting Information)?
Comment 2•3 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Hi,
I have managed to reproduce this issue on release version 78.0.2, Beta 79 and latest Nightly 80.0a1 (2020-07-27) using Windows 10.
Further, I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.
I attached here my about:support from latest Nightly build.
Thanks for the report.
Comment 3•3 years ago
|
||
Comment 4•3 years ago
|
||
It sounds like the issue is margins being set so large that no actual content would be able to appear on the page?
I can't seem to reproduce this locally; even when I set 20" margins, the print preview appears (with a large number of pages, empty except for header and footer -- not very useful, but it seems like the expected outcome).
Maybe the exact behavior is dependent on the printer driver in some way, or other settings? Or is it specific to the webpage being printed/previewed?
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
I couldn't reproduce either on any of my two windows machines. Alin, could you give us a recording of the issue so that we can check if we've missed something trying to repro it? Thanks a lot.
Comment 6•3 years ago
|
||
Sure, I attached here the screen recording, but I need to mention that the issue seems to not be reproducible all the time, I managed to reproduce it 1 of 3 tries on the same machine with new clean profile each time.
Assignee | ||
Comment 7•3 years ago
|
||
Thanks! I could repro with those margins on that page. Here's a profile: https://share.firefox.dev/2X9aK3D
It seems we either get stuck at layout without being able to make progress, or we make such little progress that it takes forever to finish laying out the page.
Assignee | ||
Comment 8•3 years ago
|
||
We were already guarding against huge @page { margins } and so on, but
not about huge default margins.
This uses a lambda so that in the case of oversized margins and such we
still show an (empty) page with headers and footers (the existing code
would just make the page zero-size).
I could move the lambda to a separate method if you want or what not,
might be cleaner.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a9309860b5e3 Properly guard against huge default margins in nsPageFrame::Reflow. r=jfkthame
Comment 10•3 years ago
|
||
bugherder |
Comment 11•3 years ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 12•3 years ago
|
||
Comment on attachment 9166804 [details]
Bug 1654489 - Properly guard against huge default margins in nsPageFrame::Reflow. r=jfkthame,dholbert
Beta/Release Uplift Approval Request
- User impact if declined: hangs if too-big default margins are specified in the print settings.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0 / comment 6
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Bails out on a condition that causes us to reflow infinitely because there's not any available space.
- String changes made/needed: none
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Verified - Fixed in latest Nightly 81.0a1 (20200803213927) using Windows 10.
Comment 14•3 years ago
|
||
Comment on attachment 9166804 [details]
Bug 1654489 - Properly guard against huge default margins in nsPageFrame::Reflow. r=jfkthame,dholbert
approved for 80.0b4
Updated•3 years ago
|
Comment 15•3 years ago
|
||
bugherder uplift |
Comment 16•3 years ago
|
||
Seeing reftest failures on beta, it's quite possible I messed up the rebase there.
Comment 17•3 years ago
|
||
Backed out for now:
https://hg.mozilla.org/releases/mozilla-beta/rev/2f7d9a147be6
Assignee | ||
Comment 18•3 years ago
|
||
This is easier than doing merge conflicts, and it's the same fix, just without the additional cleanup :)
Comment 19•3 years ago
|
||
bugherder uplift |
Comment 21•3 years ago
|
||
Verified - Fixed in latest Beta 80.0b5 (build id: 20200806203447) using Windows 10.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•