Open Bug 1721895 Opened 4 years ago Updated 4 years ago

Printed content migrates down the page, gets truncated

Categories

(Core :: Printing: Output, defect, P3)

Product:
Core
Component:
Printing: Output
Version:
Firefox 90
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: dannyfox, Unassigned)

Details

(Keywords: testcase-wanted)

Attachments

(1 file)

Amazin Order Details example (Fit to page width / Save to PDF)
215.22 KB, application/pdf
Details

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Just print typical standard pages (such as transaction line-items) from certain websites...

Actual results:

I just installed FF 90.0.2 and when I read the notes that Bug #1720621 had been fixed, I was overjoyed. But when I went in to my banking site which has regularly given me bad printing issues recently, I see the problem remains. When I look at transactions, the page image is never complete -- the line-items migrate down the page (bigger white space at the top of each succeeding page) while those at the bottom just vaporize (don't spill to the next sheet of paper nor do they merge into the next page of the report) -- the bottom lines are truncated and just go missing from the output. Amazon order details also do not render well.

I never reported or commented on this before because I could never say whether what I see is a FF issue or a problem with the printer driver (a new HP LaserJet Pro M118dw with complete software & firmware updates). BUT... the same print run works fine right now on Google Chrome, while failing on FF.

Today I'm testing only with PDF generation and not to paper because I'm very low on toner at the moment and can't waste pages -- but the problem still exists in PDF, and I find the paper image is usually as bad or worse so no reason to suspect hardcopy works any better.

Running Windows 7 Pro/32
HP driver is 8.00.1329.6503
Printer is HP LaserJet Pro, identifies as "M118-M119 (v3)", running on USB 2.0 port

BTW, I did have printing issues previously (~ Summer 2020) with this banking page and worked with their tech support people on it. They swore they were doing everything right -- and sure enough, it worked fine after a major release of FF. I'm sure they had programmed ahead for that release, and this was before the current printer...

Expected results:

Page should print normally, as anticipated by web programmers and expected by the customers & users.

Can you post a pic of the pdf output?

No, not really -- it's private banking info. But that's the type of page where it really shows up (and the only one I know off hand). The Amazon orders are just shrinking and then jumping around or growing larger in size as one continues to decrease the image size, losing more or less from the right edge as the image shrinks (or not) on the page.

But let me describe the transaction output better:
Imagine a typical display of 90 transactions, size to fit, where there might end up being 20 on a page. For simplicity, no tombstone block up top but there might be some footer details at the end -- so you would expect 5 pages: 20+20+20+20 + 10, with Footer info.

I should see...

<line item 1>
... 2-19 ...
<line item 20> one full page (1-20)
<page break>
<line item 21>
... 22-39 ...
<line item 40> another full page (21-40)
<page break>
<line item 41>
... 42-59 ...
<line item 60> another full page (41-60)
...and so on.
Last page is partial, so it is shorter but complete (81-90 + footer info).

But what I get is:

<line item 1>
... 2-18 ...
<line item 20> (usually) one full page (1-20)
<page break>
<white space>
<line item 24> some lines missing (we see 24-40, maybe)
... 25-39 ...
<line item 40?>
<page break>
<BIGGER white space>
<line item 47> MORE lines missing (we see only 47-60, maybe)
... 48-59 ...
<line item 60>
<page break>
<EVEN BIGGER white space>
<line item 70> EVEN MORE lines missing (we see only 70-80, maybe)
... 71-79 ...
<line item 80>
...and so on.
Last page is partial, and is often incomplete (page truncated at bottom, last transactions lost, no footer info) -- so we might get Lines 87 & 88 running off the bottom of the page (and no footer info).

Just to confirm, the problem is with an HTML page and not a PDF in the built-in PDF viewer.

Do you lose content on the bottoms of pages on my test page: https://www.jeffersonscher.com/res/widepage.html ? The paragraphs are numbered, so you can quickly tell what is missing. Note: Use Fit to page width / Shrink to fit for this page. If you lose content on the right ends of lines, make sure you have 90.0.2 installed.

Yes, AFAIK, it is output from an HTML page going into a print driver that goes either to paper or a PDF file.
And HELP, ABOUT says: "90.0.2 (32-bit)"

With fit-to-page, your sample fits the width properly, breaks in the right places, etc -- for example Par 8 & 9 break exactly between pages, and the text fills exactly two pages. But because there are only two pages, I can't tell what happens at the transition between second page and the non-existent third page -- but I suspect nothing goes wrong as everything else works consistently, predictably, and as expected.

If I scale the page, still everything fits well. Paragraphs may break midway, but no lines are lost. If I scale up, the box loses its right edge and the text truncates on the right -- as expected. The text spills over onto more pages, breaking mid-paragraph but never losing a line. If I scale down, everything fits everywhere, again maybe breaking mid-paragraph but never losing a line -- and not taking more than the second page either.

So I just printed the bank transactions to PDF. I do not get the same output as per screen. The screen always has what is expected -- width truncated or not, but all lines seem to appear, depending on fit or scaling.

However, if I print fit-to-width, everything fits left-right, but on successive pages, after the second everything migrates farther & farther downward as documented in the STR. Yet if I print scaled to 100%, yes I lose the right side detail, but the page info migrates upward on successive pages, leaving more & more white space at the bottom!

Thanks for testing that. The patch in 90.0.2 is doing what it was meant to do.

Was the bank page printing correctly in Firefox 90.0 - 90.0.1? It sounds as though problems may have started earlier.

I'm not sure what style rules the bank is using to create the impression of separate formatted pages. Is there any scaling that leads to "correct" page breaks?It would be useful to know of a public page that demonstrates the same problem.

If you do a general web search for your bank's name with Firefox and print, are there other reports of problems that might have some insight?

(In reply to Dan Pernokis from comment #0)

Amazon order details also do not render well.

I don't have any large orders in my 2021 history, but this is an example of a two-item order details page. Does your Firefox have a problem with this much or only the page break issue?

Was the bank page printing correctly in Firefox 90.0 - 90.0.1? It sounds as though problems may have started earlier.

It was not. I'm pretty sure (but not positive) the problem started with 90 -- only because I recall thinking "oh, brother, this printer issue is back again" and recalling a recent update. (I log my updates to the minute, but don't run every single app at that moment to check everything. If I updated on Monday and didn't print banking stuff until Friday, I might not connect the two and would tend to blame the bank -- why not? They've been wrong before!)

And as I said in the STR (unfortunately bolded, should be just italics :)
I did have trouble previously (last summer, I think, which would be FF late 70s / early 80s according to my logged updates) that mysteriously showed up with -- I think -- a bank website update (or some notice of such), but it also suddenly went away following a major FF update. The bank tech people had told me they suspected my machine (can't be their programming! :) and maybe I should wait for another FF update. (I'm thinking, major institutions like my bank probably subscribe to nightlies just to keep ahead of the curve and may have used something not quite ready for prime time...) Sure enough, the problem went away around the time of the major FF update -- but again, I couldn't quite link the two or prove anything, because the bank may have made changes too as a result of my complaint.

And just while I think of it: My HP M118 UI has a printer selector listing everything installed. The "Save to PDF" choice is first in this list of "printers" -- but I don't know if it is a pure pass-through to FF browser save-to-PDF, to my Adobe Acrobat PDF generator, or to its own version.

If I search ... are there other reports of problems that might have some insight?

Didn't see any. The closest was a few generic things in the Mozilla forum, and a few very specific browser-security issues (not related to printing) between my bank and early FF and ancient predecessors dating back 20 years.

Is there any scaling that leads to "correct" page breaks?

I had to do exactly this in Chrome -- because the bank had their pages a tad long for their page framing -- to get a balance between it breaking between transaction segments (2-3 lines) and within a segment, and yet not have it happen on some pages and not all on others. (I was able to fudge it.) But FF at the time was missing actual lines and segments, so a rough GC printout was better than a FF'd one.

But to your question now, there doesn't seem to be -- or at least I didn't push all permutations. Suffice to say I squeezed as small as I could (still readable) and as large (until the edges broke) without getting anything workable.

As for Amazon order details... (Comment #6)

Your PDF looks fine -- exactly as I get mine to work, usually. I tried one of my orders tonight and it worked perfectly -- don't know why. It had been failing by breaking too early or too late and not cooperating with a nice page fit. The reference in the STR was that -- on one particular order -- as I decremented the page size, the page got smaller and the right-side text gradually appeared. (Not sure what happened beyond the page break, I was watching the overall size fit at the moment.) But suddenly as I kept decreasing size, the page image would jump (increase) in size a few percent, then gradually lessen again as I kept decreasing. I couldn't get a sweet spot, so I went to Chrome for the printout and didn't investigate any further. But then I couldn't get this behaviour to repeat tonight!! Fluke? Amazon patch? Different order? Actually a different site? Full moon?

(BTW, there are different versions of Amazon at various times, perhaps depending what was ordered and where. I've seen variations in appearance and functionality -- not just between .com and .ca but between two different orders within .com or within .ca sites. I think if it is an Amazon direct sale vs third-party, they may use different templates.)

I'm sure I did have problems with page break and things disappearing, but often this content wasn't critical -- just recommendations evoked by my order items -- whereas every single line in a transaction log is critical. (Some breaks we can live with, some we can't...)

I have to think some more -- I know there are other common pages that don't always print very well. I'll try to report back if I think of any.

(In reply to Dan Pernokis from comment #7)

The "Save to PDF" choice is first in this list of "printers" -- but I don't know if it is a pure pass-through to FF browser save-to-PDF, to my Adobe Acrobat PDF generator, or to its own version.

"Save to PDF" is a purely internal feature added when the new print overlay was rolled out.

Is there any scaling that leads to "correct" page breaks?

I had to do exactly this in Chrome -- because the bank had their pages a tad long for their page framing -- to get a balance between it breaking between transaction segments (2-3 lines) and within a segment, and yet not have it happen on some pages and not all on others. (I was able to fudge it.) But FF at the time was missing actual lines and segments, so a rough GC printout was better than a FF'd one.

But to your question now, there doesn't seem to be -- or at least I didn't push all permutations. Suffice to say I squeezed as small as I could (still readable) and as large (until the edges broke) without getting anything workable.

It sounds as though the bank has tried to create its own pagination for a different paper size/shape rather than letting the content flow naturally onto whatever paper the user prefers. I don't think anyone can solve this without hands on. Even then, I'm not sure there will be a convenient workaround, or whether it would be acceptable for your purposes to modify the page layout to force it to print better.

I know there are other common pages that don't always print very well. I'll try to report back if I think of any.

There is no shortage of pages that Firefox doesn't paginate correctly. I created an extension to tweak some pages for better printability for some of the more common reasons. https://addons.mozilla.org/firefox/addon/printable-the-print-doctor/

Further to my Comment #7 (for the sake of clarity)...

Was the bank page printing correctly in Firefox 90.0 - 90.0.1? It sounds as though problems may have started earlier.

It was not. I'm pretty sure (but not positive) the problem started with 90 -- only because I recall thinking "oh, brother, this printer issue is back again" and recalling a recent update.

I just found a note of problems with FF 89.0 which I didn't like when it arrived -- I wrote "bad" at the top of the note, and unfortunately I didn't file any bugs at the time. (Thought surely somebody else would catch these... and it was a short-lived release in any case.)
(i) The mouse suddenly became jerky (which I now know to be an issue with the BitDefender anti-tracker extension).
(ii) I had trouble quitting, of all things! (Don't recall how or why...)
(iii) Most importantly, I wrote: "PRINT PAGES fails with stuff that worked fine before!" This definitely includes my banking transactions and Amazon orders, two things that always had worked reliably.

And just while I think of it: My HP M118 UI has a printer selector listing everything installed. The "Save to PDF" choice is first in this list of "printers" -- but I don't know if it is a pure pass-through to FF browser save-to-PDF, to my Adobe Acrobat PDF generator, or to its own version.

Actually there are two PDF buttons in the drop-down. The one at top says "Save to PDF" -- still not not sure what that triggers (Jeff says it's "...a purely internal feature added when the new print overlay was rolled out." And near the bottom of the list is "Adobe PDF". I tried to print THIS page since it's handy. The "Save to PDF" function works correctly for Fit to Page, for scaling at 100%, and at 68%, printing three pages each time. The "Adobe PDF" selection throws a FF popup saying "Print Review Error" / "An error occurred while printing" -- and produces either a proper Page 1 with two blank pages, or just the two blank pages. (But previously I've had occasional errors with this in FF and elsewhere.)

If you are patient and have a lot of bandwidth, you can triangulate the change that messed up printing from the bank page using this tool:

https://mozilla.github.io/mozregression/

You can specify Firefox 87 as the last known "good" release and Firefox 90 as the first known "bad" release, or any range that makes sense to you.

Today (12-Aug-2021) I installed the new standard release FF 91.0 and it seems to have fixed the jerky mouse problem -- no hesitation anywhere. Also a couple of other irritants seem to have gone away.

So I happily tried my bank transactions again -- print-to-fit as usual -- and the transactions still migrated down the page! For the first page, it crowded the footer and split a line-image horizontally, printing the top half crowded to the footer and the bottom half about 3" down the next page. This page ended normally (from what I can see on paper) but there were two lines of detail missing on the third page AND its text started about 4" down the page. And this third page likewise ended normally (from what I see), with the fourth/final page losing FIVE (!) blocks (2 lines + 2 blanks each) of detail and starting almost 5" down the page (it ending normally at the bottom).

I'm thankful for normal mouse action -- affects everything -- but the print migration issue still sucks and I have to use Chrome for certain important things (which is frustrating).

...I installed the new standard release FF 91.0 and it seems to have fixed the jerky mouse problem -- no hesitation anywhere.

Actually, the mouse is still a little jerky at times (when things are loading), but not nearly as bad as it was, and not noticeable in many cases. (But still is noticeable if FF is running and I'm mousing in an unrelated window.)

I also re-tried print-previewing some Amazon pages. They all scale up & down and do not have the weird resizing I mentioned in my Comment #2 -- but then I couldn't reproduce this issue last time either.

Dan, can you reproduce the bug if you save the page to a local HTML file first?
If so, can you edit it to replace the sensitive parts with some equivalent text instead and then upload it here?
Thanks.

Severity: -- → S3
Flags: needinfo?(dannyfox)
Keywords: testcase-wanted
Priority: -- → P3

FYI, I updated FF today (18-Aug-2021) to 91.0.1 (32 bit), running on Windows 7 Pro/32 (Aero) as usual.

I cannot reproduce from an offline HTML. Not everything gets saved locally, in particular style sheet(s) or other formatting stuff, which defeats the purpose. Even if still connected online, the offline instance does not seem to fetch what's missing.

But here's what I did do:
(1) I previewed 6 months of this account in Fit-To-Page to my HP M118dw LaserJet -- looks perfect (as it always does). I then printed to paper (first test on new FF 91.0.1), hoping to scan them to PDF for you. (I can bleep out sensitive info if such a scan would be useful.) Problem very apparent.

(2) I previewed same 6 months in Fit-To-Page for PDF -- looks perfect too (as it always does). I saved to PDF (another first test on NEW FF 91.0.1), and watched the lines walk down the page as it lost many lines of detail. I can send you all but the first two pages (which contain too much personal detail and can't be blocked from the PDF), but you'd be missing the first lines of detail too and how they screwed up (including a line of detail split horizontally across Pages 2 & 3).

(3) I previewed same info at 100% Scale for PDF -- again looks perfect (as it always does too). When I saved to PDF, again I lost many lines of detail -- but at 100%, lines were truncated too and I lost the Amount column on the right side of the page.

If these examples would be useful, please let me know and I will submit them as unadulterated as I can make them. But I'm sure you're aware -- you will see visually just what I described in my Comment 2 above) but not the code for how it got that way.

Flags: needinfo?(dannyfox)

Here's a thought:

The bank is the Canadian Imperial Bank of Commerce (aka "CIBC") at www.cibc.com

Perhaps you can contact their web tech people and sweet-talk them into logging you on to a dummy test account (with at least 4-5 pages of line-item details) and you can print to your heart's content. Then you can give them immediate feedback as ask what's going on. (I've never been able to talk directly to their programmers, only intermediaries who, of course, lose the nuance & immediacy of any Q&A that might go on.)

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

Attachment

General

Creator:
Created:
Updated:
Size: