Confirmation pages from certain websites do not print from Firefox
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
People
(Reporter: smithd550, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
(As far back as 2021) Tried to print confirmation web pages from transactions at Orbitz. The rendering to paper has large blocks of white instead of important content. Workaround since then has been to use Microsoft Edge for Orbitz transactions.
This year I am having the same problem with FirstBank confirmation pages and CU Medicine confirmation pages. Workaround is to use Windows Snipping tool and print from there.
The problem occurs printing to paper (HP Office Jet Pro 9015, Windows 10 Home build 19043.1586).
The same problem occurs printing to disk ('Microsoft Print to PDF').
I saved the CU Medicine confirmation page from Firefox to disk as HTM with supporting files. When I open the saved HTM using Firefox, I get the same rendering problem on paper and to PDF. (See attachment)
Actual results:
The pages appear fine in browser window (browsing from the web or saved HTM). Unfortunately Firefox prints these pages (to paper or PDF) with large blocks of significant information "whited out". For some pages, the entire page is lost.
Expected results:
I expect the image on paper or PDF to be the same contents as the browser window.
When I open the saved HTM with Microsoft Edge, the content renders correctly in the browser window and prints correctly to paper or PDF, as expected.
When I open the saved HTM with Chrome, it also renders and prints just fine (to paper, or using Chrome 'Save to PDF').
This is heartbreaking since I HAVE BEEN RELYING ON FIREFOX FOR THE LAST 15 YEARS and it is now becoming less and less usable for IMPORTANT FUNCTIONS.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
With the attached example, there's something odd happening with respect to the Print Backgrounds option. If Print Backgrounds is disabled in the Print dialog, the content basically all disappears (except for the "Add a Wallet" popup). With Print Backgrounds enabled, the content seems to be present, but it's quite faded-out, as though there's a semi-opaque overlay on top of it.
In Chrome or Safari, it behaves differently: the Backgrounds option controls whether various colored-background elements are present, but the content stays (and isn't faded-out).
|
Reporter | |
Comment 3•3 years ago
|
||
When you say "something odd happening" you are saying the Firefox print rendering is wrong and does not faithfully reproduce what is on the screen. Whereas, Chrome and Edge print just fine.
I am now having the same problem with certain emails that do not print faithfully.
Am I the last user to realize that Firefox is a SINKING SHIP ????
Are you going to fix this bug so I don't have to TRANSITION OFF OF FIREFOX after being a faithful and happy user for THE LAST FIFTEEN YEARS ????
|
|
Reporter | |
Comment 4•3 years ago
|
||
If you privide an email address, I can furnish a copy of the email that fails to print. (Note to self: SMS 11:08am 4/4/2022)
|
|
||
Comment 5•3 years ago
|
||
If you click on my user-name here above the comment, it should show you my address -- feel free to send me a copy of the problem email, and I'll see how it behaves for me. (It's possible the results will depend on the email system being used, which may affect how it is displayed; so what I see on gmail might not be the same as you see on yahoo. But it'd be useful to check.)
|
|
Reporter | |
Comment 6•3 years ago
|
||
Good news. It appears the defect in print rendering is associated with "Format=Original" (in the print dialog). When I choose "Format=Simplified", the missing information reappears.
(So far I have just tried this with the email I am about to forward and printing to PDF, but I am hopeful this will fix the problem with confirmation web pages from Orbitz and FirstBank as well.)
|
|
Reporter | |
Comment 7•3 years ago
|
||
Bad news. When I open the FirefoxBug.htm file (submitted with this bug report) using Firefox, and then I go to print the page, I do not see the "Format=Original/Simplified" option in the print dialog. Grr.
However, that option does appear in the print dialog when printing an email at the Yahoo mail website. I click the little print icon in the upper right of the Yahoo message preview frame.
I hope this helps isolate the problem.
|
|
Reporter | |
Comment 8•3 years ago
|
||
If I go to the Yahoo mail site using Edge and click the print icon, the barcode shows up in the print preview. Also there is no "Format=Original/Simplified" in the print dialog that appears when using this browser. But I don't care! (Because the barcode renders just fine.)
|
||
Comment 9•3 years ago
•
|
||
Thanks for the bug report, and thanks for being a long-time user. I've gotta step back for a sec and request-that-you-refrain from these sorts of all-caps/not-constructive comments, though:
(from comment #0)
This is heartbreaking since I HAVE BEEN RELYING ON FIREFOX FOR THE LAST 15 YEARS and it is now becoming less and less usable for IMPORTANT FUNCTIONS.
(from comment #3)
Am I the last user to realize that Firefox is a SINKING SHIP ????
Are you going to fix this bug so I don't have to TRANSITION OFF OF FIREFOX after being a faithful and happy user for THE LAST FIFTEEN YEARS ????
We realize you're passionate; please keep in mind that we're a small team, trying to do our best, and these sorts of comments aren't helpful. I've gotta call attention to it & ask that you not post stuff like that going forward.
Having said that, let's move forward here and do our best to isolate the specific bugs/quirks that are causing trouble here.
|
|
||
Comment 10•3 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #2)
With the attached example, there's something odd happening with respect to the Print Backgrounds option. If Print Backgrounds is disabled in the Print dialog, the content basically all disappears (except for the "Add a Wallet" popup). With Print Backgrounds enabled, the content seems to be present, but it's quite faded-out, as though there's a semi-opaque overlay on top of it.
This piqued my interest; this behavior seems to come from this CSS rule:
@media (max-width:767px) {
.backdrop[_ngcontent-vmf-c292] {
top: 0;
bottom: 0;
right: 0;
left: 0;
width: 100%;
height: 100%;
background-color: hsla(0, 0%, 100%, .8);
filter: none
}
}
This causes an element in the page to become a full-screen partially-transparent overlay (which you can see in a regular browser viewport, as well, if you simply reduce your viewport width to be less than 767px wide).
Worse, though: this partially-transparent overlay apparently becomes fully opaque with "print backgrounds: disabled". That's what's making this page end up rendering blank. That seems like something we should avoid; I'll spin off a dedicated bug on that with a reduced testcase. We can use this bug here to further investigate the issues that the user reported with emails.
|
|
Reporter | |
Comment 11•3 years ago
|
||
I apologize for my intemperate shouting in all caps.
This has been a problem for over a year, but it's my fault for assuming somebody else would have brought it to your attention.
The email that fails to render for printing was forwarded a few minutes ago to Johnathan Kew at 'jfkthame@gmail.com'.
|
|
||
Comment 12•3 years ago
|
||
Thanks. It's somewhat late in Jonathan's timezone, so he may not be able to take a look for a day or so, but hopefully he'll post some thoughts/analysis soon.
Following up on my comment #10:
Worse, though: this partially-transparent overlay apparently becomes fully opaque with "print backgrounds: disabled". That's what's making this page end up rendering blank. That seems like something we should avoid
To my surprise, this actually happens in Chrome and Safari as well in simplified testcases; so there's something more subtle that's causing the Firefox-specific trouble in the attached testcase.
|
|
||
Comment 13•3 years ago
|
||
Aha! Comparing Firefox vs. Chrome (which should be equivalent to Edge), it looks like we actually agree with them on the attached testcase, if you adjust the page margins to just overshoot or under-shoot the (767px) threshold for the CSS rule that I quoted in comment 10.
Firefox happens to have slightly-larger default margins than Chrome has (0.5in vs 0.4in). If I increase the margins a little bit in Chrome (e.g. to 0.6in on both sides), then Chrome renders with full-blank page just like Firefox does. And if I decrease the margins a bit in Firefox (e.g. to 0.2in on both sides), then Firefox renders all the page content as-expected.
So, this is just an unfortunate case where the page itself happens have some markup that makes it print in a broken mostly-blank state (in Chrome/Edge as well as Firefox), if the viewport is skinnier than 767px wide. And Firefox's default configuration happens to put it just on the "bad" side of that threshold, whereas Chrome's default configuration happens to put it on the "good" side of that threshold.
|
|
||
Comment 14•3 years ago
|
||
|
|
||
Comment 15•3 years ago
|
||
So, the attached .zip file is in fact not-a-Firefox bug; it's essentially a bug in the website.
If you like, you could report it to whoever runs the website, and let them know that their "Add a wallet" element seems to inadvertently create a full-page overlay that covers up the rest of the printout, in at least Firefox and Chrome, if the page area is just under a 767px wide (which it is in Firefox, and it is in Chrome with a very-small-tweak to default configuration, as shown in my attached screencast).
So that part of the bug is not really something we can fix. We can keep this open to close the loop on whatever issue you're hitting with the email that you mentioned, though.
|
|
||
Comment 16•3 years ago
|
||
Also, if you want a workaround for your own daily workflow: it looks like you could work around this particular website-issue in Firefox by printing the site with smaller margins (e.g. 0.25in margins work for me), or by printing in landscape mode -- either of those changes should make the content area be wider (on the "good side") of than the site's arbitrary 767px threshold that I quoted in comment 10.
Alternately: if you feel like using a power tool, you could use an add-on like Stylus to disable the problematic CSS, e.g. by adding a rule like .backdrop[_ngcontent-vmf-c292] { display: none } for the site in question (to simply disable the rendering of the fully-opaque element).
(Neither of these are a solution; really, the site needs a fix here. These are just actions you could take to avoid the issue yourself, if you like.)
|
|
Reporter | |
Comment 17•3 years ago
|
||
It sounds like another way to phrase it is that certain websites have style-sheet settings tailored to work with the default configurations of Chrome and perhaps Edge. Web pages tailored to work that way will break on Firefox because it has different default settings. A welcome fix would be to tweak Firefox's default to match the other browsers. (Of course who knows what that might break. Haha.) I can send html from other websites, but I need to try the workaround below for those.
Suitable workaround seems to be to do the following in the print dialog: a) set paper size to 'letter', b) set left and right margins to '0.25'.
I don't know if these are manipulating what you call the view port, but they seem to do the job on the test file.
Thanks for looking into this.
|
|
||
Comment 18•3 years ago
|
||
(In reply to David Smith from comment #11)
I apologize for my intemperate shouting in all caps.
This has been a problem for over a year, but it's my fault for assuming somebody else would have brought it to your attention.
The email that fails to render for printing was forwarded a few minutes ago to Johnathan Kew at 'jfkthame@gmail.com'.
Unfortunately, I can't seem to reproduce the problem with the forwarded email; attempting to print it from Firefox (on either macOS or Windows) seems to work OK, with the barcode appearing as expected. I suspect this may be because my gmail interface ends up displaying emails rather differently from your yahoo mail system. But it makes it difficult to investigate further.
It's also possible that the very act of "forwarding" the mail affects its display, because it is no longer a standalone message but wrapped in additional forwarding headers, etc. Do you have an option to "redirect" it instead? This may deliver it to me in its original form rather than wrapped in a new message that treats it as an embedded or quoted item. Maybe that would help us reproduce the issue.
|
|
Reporter | |
Comment 19•3 years ago
|
||
I have attached 'FirefoxProblemEmail.pdf'. This is the email I forwarded, printed from my Sent box, using 'Microsoft Print to PDF'. This shows the wrapping of the email in a forwarded email is not the problem. This suggests the problem is in how Yahoo prints (versus Gmail). Interestingly, it is the entire second page of the printout that is messed up here.
|
|
Reporter | |
Comment 20•3 years ago
|
||
PS: Creating a Yahoo email account is free.
|
|
Reporter | |
Comment 21•3 years ago
|
||
I have attached file 'FirefoxProblemEmailAdjMargin.pdf'. I printed the email again to PDF, but adjusted the left and right print margins to 0.25 inch. This succeeded in causing the 4-point list and barcode to render onto page two. However, there is a new problem in that the text rendered on page 2 is moved downward, causing the top half to be blank and the text that should have appeared at the bottom disappeared. (PS: I tried again setting the top and bottom margins to 0.25 inch as well, but no change, so that file is not included.)
|
|
||
Comment 22•3 years ago
|
||
Thanks -- there are some known issues with printing & yahoo mail, tracked in bug 1648947, and it looks like your attachment shows a version of those same issues (content pushed down unexpectedly on a page, and in some cases running off the page & ending up missing).
So we've gotten to the bottom of the issues for two of the sites you mentioned:
(1) CU Medicine: this one's essentially a website bug (with a fragile dependency on precise margin/viewport size, and code that renders blank in any browser if viewport is a bit too small); I filed bug 1763030 to see if there's anything we can do there (there's a see-also link on that bug which points at a spec issue that's relevant to that bug)
(2) Yahoo Mail: unfortunately this one's a known issue, bug 1648947; hopefully one of us can address that before too long. (I've just increased the severity rating over there.)
To avoid investigating too many potentially-distinct issues on one bug page & keep things readable, let's close out this bug at this point; I'll mark it as a duplicate of bug 1648947 for item (2) noted above.
If you have printing issues with other sites (you mentioned Orbitz and FirstBank), would you mind filing those as their own bug reports? (ideally with testcases or saved copies of the pages attached, if you can remove personal information. Alternately, feel free to email saved zipped-up copies to me or Jonathan and we can investigate & redact as-needed); and you can include us in the CC field on those bugs to be sure we see them.
Thanks again for the reports & the testcases/PDFs to demonstrate the issues.
|
|
||
Comment 23•3 years ago
|
||
Thanks, Daniel - yes, this looks very much like bug 1648947 is involved.
I was able to confirm that with the "problem" mail forwarded to a yahoo account, I see similar glitches to what David reported. With normal page sizes, the "To return to store:" section of the message doesn't fit on the first page, so it goes onto the second (it is an unbreakable table in the message), but it gets pushed way down the page, such that some/most of its content gets cut off at the bottom. That's where the bar-code is disappearing. By choosing Legal instead of Letter paper, for example, it becomes visible for me (although the content is still pushed far down from where it should be).
Description
•