1564128 - Unable to print CSS animations/transitions and web animations

Status: RESOLVED FIXED

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

Description

[Jim]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

When one has an email account on Rackspace.com one can print off step by step instructions for a use so that they can configure say an iOS or Android device. One goes to https://emailhelp.rackspace.com/ logins with the account's credentials. You then select device type iOS, Android, Windows etc and model. It gives you instructions including screen shots of how to configure your email on that device. I want to create a PDF for someone at the location to assist the person by simply printing the output to a PDF

Actual results:

What happens in 67.0.4 on Windows10 1809 on some sites to print graphics on some websites? I have made sure that graphics and background printing is enabled. Print Preview even fails. Chrome has no such issue.

Expected results:

Graphics that are visible on the browser's screen should print. Running the same series of steps in Firefox safe mode produces the same results. White spaces where the graphics should be when one does a print preview, prints to a PDF or just to a local printer.

Comment 1

[Sean Voisen (:svoisen)]

Jim: Any chance you can include screenshots or the actual PDFs generated by both Firefox and Chrome as attachments? Unfortunately, this is difficult for us to reproduce given that we would require credentials to sign into Rackspace.

Comment 2

[Jim]

I have PDFs from Firefox and Chrome already but I see no way of attaching them to this bug report?

Comment 3

[Daniel Holbert [:dholbert]]

You should see an "Attach file" link, just above your first comment on the bug here.

Comment 4

[Jim]

Attachment: Firefox no graphics

This is the result when I attempt to print the page with Firefox

Comment 5

[Jim]

Attachment: Chrome Success printing

This is the result when I attempt to print the page with Chrome

Comment 6

[Daniel Holbert [:dholbert]]

Thanks, Jim! One more request - would you mind trying to save a copy of the affected page, and if the saved copy of the page loads successfully, attaching that (as a .zip file) to this bug report? That'll hopefully help us investigate without needing a hosted Rackspace account.

To save the affected page, you'd choose "File | Save Page As..." and then in the save dialog, be sure "Web Page, Complete" is selected as the save-type. (That makes sure the graphics/etc are saved, in most cases at least.)

That should produce a file called e.g. "example.html" (or whatever name you choose) and a folder called "example_files" with all the images/scripts/etc, and you'd then want to put those in a .zip file and attach that here. Thanks!

Comment 7

[Daniel Holbert [:dholbert]]

(My current guess is that the page has a Print Stylesheet, with different styling specified, which is activated in Firefox but not in Chrome for some reason. But this is just a guess from looking at the PDFs.)

It'd also be useful if you could try Microsoft Edge and see what the printout looks like there.

Comment 8

[Jim]

Attachment: Save page as complete website

Comment 9

[Jim]

Tried MS Edge non-Chromium and the same issue as Firefox. Graphics do not show up in print out.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks! So the reason the images aren't shown is that the page has the images styled as "opacity:0", and they play a 1-second animation on pageload to fade them in.

.article .content img {
[...]
    opacity: 0;
    animation: fadeIn ease-in 1;
    animation-fill-mode: forwards;
    animation-duration: .5s;
[...]
}
@keyframes fadeIn {
  0% {
    opacity: 0
  }
  to {
    opacity: 1
  }
}

Firefox renders the page by cloning its document, with no animations and no scripting, and then printing that. This means the page is stuck with the initial opacity: 0 styling.

In a perfect world, perhaps our document-clone would use the instantaneous animated values of every animated CSS property for every element, at the moment the user chose to print. But for now, that's not how our print pipeline works.

Probably the best way to address this is for Rackspace to include a print stylesheet (@media print {...}) which sets opacity:1 on these elements to override the opacity:0. But we'll keep this on our radar as something to look into fixing as well.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 2, slower animation with changing color

Here's a testcase with a slower animation where the text-color is changing instead of its opacity.

With this version:

• Firefox Print-Preview uses orange (which is the underlying text-color, if there were no animation).
• Chrome's Print-Preview (from Ctrl+P) uses whatever the instantaneous animated color is, at the moment that you activated it.

Comment 13

[Daniel Holbert [:dholbert]]

hiro, do you know if this animation/printing interaction is something we've run into & have any sort of plan for? (I found Bug 826670 which initially looked like the same issue, but on closer inspection, that bug was actually asking for what is now our current behavior (ignoring animations entirely for printed output). That bug's testcase didn't have any underlying opacity:0 -- its hiding was done by the animation itself. So I've closed that one out since we match its expected behavior now. :))

Do you have any thoughts on how hard this would be to fix? (I suspect we'd need to effectively replace animation: foo with [animated-property]: [instantaneous value] in every stylesheet for our cloned print document, or something like that.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

I haven't heard we have some plans for printing.

hiro, do you know if this animation/printing interaction is something we've run into & have any sort of plan for? (I found Bug 826670 which initially looked like the same issue, but on closer inspection, that bug was actually asking for what is now our current behavior (ignoring animations entirely for printed output). That bug's testcase didn't have any underlying opacity:0 -- its hiding was done by the animation itself. So I've closed that one out since we match its expected behavior now. :))

Do you have any thoughts on how hard this would be to fix? (I suspect we'd need to effectively replace animation: foo with [animated-property]: [instantaneous value] in every stylesheet for our cloned print document, or something like that.

The way sounds the right way but it requires some amount of work. (Though I don't know what we do when we clone document, it also clone the script state at the moment?)

An alternative way I can think of, if we don't need to run any CSS transitions and Web animations, we can just have a cloned the most recent refresh time of nsRefreshDriver and use it for CSS animation on printing.

Oh, I just remember we have already implemented Animation.commitStyle thanks to Brian (here is the link to the spec) so that we can now easily do the right way. We just need to do the commitStyles just before cloning document and revert it after cloning, then all animations at the moment in the document appear in printing document as well.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #14)

(Though I don't know what we do when we clone document, it also clone the script state at the moment?)

I believe we clone the DOM/document entirely, and then scripts are disabled [and unnecessary] on the cloned document. And we build a new presentation for the clone. (including e.g. print stylesheets which wouldn't have been active on the original document)

Oh, I just remember we have already implemented Animation.commitStyle thanks to Brian (here is the link to the spec) so that we can now easily do the right way. We just need to do the commitStyles just before cloning document and revert it after cloning, then all animations at the moment in the document appear in printing document as well.

Nice! It sounds like that approach could work, yeah.

Comment 16

[Jim]

This is another page https://support.code42.com/CrashPlan/6/Configuring/Replace_your_device that has issues if you do a CTL-P in windows. The resulting output is only 2 pages when it should be 12+ pages

Comment 17

[Sean Voisen (:svoisen)]

I'm going to put this at P1 for printing since it involves data loss, but seems like a case we may not run into very frequently.

Comment 18

[Mats Palmgren (inactive)]

Given that we have a proposed fix (comment 14, last paragraph) do we have someone who could try implementing that?

Comment 19

[Sean Voisen (:svoisen)]

I will talk with alaskanemily about this as a potential first print bug.

Comment 20

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1564128 part 1 - Add version of Animation::CommitStyles with different source and target elements.

Comment 21

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1564128 part 2 - Copy animations to static document clones

Comment 22

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1564128 part 1 - Add clone function for Animation and constructor for KeyframeEffect to copy properties but not the target.

This can also share code with one of the existing static constructor functions.

Comment 23

[Emily McDonough [:alaskanemily]]

Attachment: Bug 1564128 part 3 - Reftests checking for if animations are applied in print preview

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e9e8c329a21c
part 1 - Add clone function for Animation and constructor for KeyframeEffect to copy properties but not the target. r=hiro
https://hg.mozilla.org/integration/autoland/rev/b533efb48731
part 2 - Copy animations to static document clones r=emilio,hiro
https://hg.mozilla.org/integration/autoland/rev/01970559781a
part 3 - Reftests checking for if animations are applied in print preview r=hiro

Comment 25

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e9e8c329a21c
https://hg.mozilla.org/mozilla-central/rev/b533efb48731
https://hg.mozilla.org/mozilla-central/rev/01970559781a

Comment 26

[Hiroyuki Ikezoe (:hiro)]

\o/ Thank you Emily!