Closed Bug 1666825 Opened 4 years ago Closed 4 years ago

Online bank statement page not printing correctly (at Smile Bank UK)

Categories

(Core :: Printing: Output, defect)

78 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 534182

People

(Reporter: forum, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Logged onto online banking (Smile Bank UK). Attempted to print credit card statement. This can only be done by printing the web page, there is no downloadable .pdf available). I always save the print file as a .pdf first before printing out.

Actual results:

The layout is all over the place. The first page is mostly blank. The second page contains some of the required data but it's bleeding off the edge of the page. Printing in landscape does not solve the problem.
The same happens on a PC running Firefox v81. Other browsers e.g. Safari and Microsoft Edge prine correctly.

Expected results:

Prior to the latest version the required info was printed neatly on the first page, with some general stuff appearing on page 2, which I don't bother to print.
I have 4 screen shots of what happens but it seems I can only send one.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Printing: Output
Product: Firefox → Core

Sorry to hear about that issue, and thanks for the report!

A few questions/notes:
(1) If you'd like to attach your other screenshots, you can do so (one by one) using the "Attach new file" button on this page (in the "Attachments" section above your first comment here)

(2) Just to be sure -- do you see the same problem with the mac Firefox version that you used to file this bug report? (According to the auto-filled part of Comment 1, that Firefox was at version 78 when you reported the bug)

(3) It may be difficult to make direct progress on our end without having a live testcase or knowledge about which precise change caused the issue. There are two things you could do to help on those fronts, if you're willing:
(a) You could save a copy of an affected page, and see if the locally-saved copy still reproduces the issue (hopefully it does); and if so, maybe hand-edit it to remove personally identifying information, and then zip it up & its supporting resources (which end up in a folder alongside it), and send it to me or another Firefox developer (you can reach me at dholbert@mozilla.com). You could post it here as well, but I'd be a bit wary of posting it publicly due to the personal nature of the data & the possibility that you might miss something when redacting it / hand-editing it.

(b) You could try to help us identify the change that introduced the issue, using the tool "Mozregression" ( https://mozilla.github.io/mozregression/ ), which runs individual Nightly firefox builds & asks you to judge if they're good/bad, and bisects down to the day that introduced the issue. This is a bit time consuming but can be extremely valuable for figuring out what change introduced the issue & where we should go looking for the problem.

Blocks: 521204
Flags: needinfo?(forum)
Priority: -- → P2
Whiteboard: [print2020]

For what it's worth: I tried printing the public "front/info" page at https://www.smile.co.uk/online-banking and I'm seeing something similar to what the reporter described (first page mostly empty, second page has lots of content that's clipped at the bottom).

In that case, it's an instance of bug 534182 -- the page is putting most of its content in a display:inline-block element, for some reason, via the rule:

.o-layout__item{display:inline-block;

...in https://www.smile.co.uk/assets/ns/smile/css/style-27bab2a03a.css

If I use the Stylus add-on to add this additional overriding style for this www.smile.co.uk domain...

.o-layout__item{
    display:block !important;
}

...then that works around the issue for me locally, at that front page. I don't know if the bank-statements are hitting the same underlying issue, because they're in a part of the website that I can't access; but it would be interesting if someone who can reproduce this could give that a try, to see if it helps.

(If that is indeed the underlying issue, then the approach in bug 1640197 is likely to help here.)

Severity: -- → S2
Priority: P2 → --
Summary: Online bank statement page not printing correctly → Online bank statement page not printing correctly (at Smile Bank UK)
Attached file Visa300820Redacted.pdf

Here is the redacted .pdf referred to in my reply.

Flags: needinfo?(forum)

Thanks for posting those!

Unfortunately, the ZIP attachment doesn't seem to work (which happens sometimes & isn't your fault) - the page must depend on some additional data that's only available when online & which our "Save" flow doesn't fully capture, for some reason.

But the redacted PDF is quite helpful - that shows the exact same sort of issue that I observed on the public front page of the website in comment 4. Given that, it seems quite likely that the issue you're seeing is the same issue that I saw in comment 4, which is a version of bug 534182.

The only confusing part is your note that this only started happening recently (because bug 534182 is a long-standing bug). I suspect the best explanation for that is a change on the website's end (a partial rewrite of their site design, whether visually detectable or not).

You could help us confirm that theory by testing a somewhat older version of Firefox, e.g. a Nightly build from January 2020 (which would be well before our most recent version-change). mozregression is one tool that could help you with running specific old builds like this, but I saw an email from you saying that mozregression isn't working on your system. That's unfortunate, but fortunately we have other options -- you could also visit our Nightly build archive ( https://ftp.mozilla.org/pub/firefox/nightly/ ) and pick out a Nightly build and download and run it.

e.g. this one should probably be fine:
(either as a standalone .zip
https://ftp.mozilla.org/pub/firefox/nightly/2020/01/2020-01-01-09-29-38-mozilla-central/firefox-73.0a1.en-US.win32.zip
...or as an installable application:
https://ftp.mozilla.org/pub/firefox/nightly/2020/01/2020-01-01-09-29-38-mozilla-central/firefox-73.0a1.en-US.win32.installer.exe
)

Note that these ^^ will auto-update, so you're only guaranteed to be testing the old behavior the first time you run them. After you've quit & restarted them, they might update to the latest Nightly version which would then be testing new code instead of old code.

Anyway - if that old build reproduces the issue for you, then I'm confident that this is bug 534182 and the recent change here was on the website's side (unfortunately making it susceptible to that bug).

I've downloaded and run Firefox Nightly 73.0a1 1st January 2020. It shows the same printing problem as the current version. So your hunch that Smile have changed the website in some way which has revealed a longstanding bug seems correct.
Is it worth trying earlier versions?

Thank you for confirming that! No, I don't think it's worth trying earlier versions. I'm confident this is a version of bug 534182 at this point.

Hopefully bug 1640197 will help out here, then. (It's our current plan for addressing bug 534182, and it's underway.)

In the meantime: if you like & feel confident enough to do so, you could try using the Stylus add-on to add some custom CSS to the page, as I noted in comment 3. (as a local workaround, to hopefully get this working again on your system.)

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Many thanks for this. I'd be happy to give this a go. However, having saved the page, I've been unable to get it to open. I have a file named: Online Banking.html plus a folder containing 9 items, including a folder named p_data containing 67 items. If I simply double-click on: Online Banking.html I get a blank page. I don't have the expertise to know where to go from there! (This is before attempting to modify the code).

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

Attachment

General

Creator:
Created:
Updated:
Size: