Closed Bug 1564128 Opened 3 years ago Closed 2 years ago

Unable to print CSS animations/transitions and web animations

Categories

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

67 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: keyboarder, Assigned: alaskanemily)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020_v78][layout:print-triage:p1][layout:backlog:78])

Attachments

(8 files, 1 obsolete file)

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.

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

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.

Flags: needinfo?(keyboarder)
Priority: -- → P3
Whiteboard: [layout:print-compat][layout:print-dataloss]

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

Flags: needinfo?(keyboarder)

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

Flags: needinfo?(keyboarder)
Attached file Firefox no graphics

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

Flags: needinfo?(keyboarder)

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

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!

Flags: needinfo?(keyboarder)

(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.

Flags: needinfo?(keyboarder)

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

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase 1

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.
See Also: → 826670

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.

Flags: needinfo?(hikezoe.birchill)

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.

Flags: needinfo?(hikezoe.birchill)

(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.

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

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.

Whiteboard: [layout:print-compat][layout:print-dataloss] → [layout:print-compat][layout:print-triage:p1]
Summary: Unable to print graphics on some website while Chrome is fine → Unable to print CSS animations/transitions and web animations
Blocks: 1601429

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

Flags: needinfo?(svoisen)

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

Flags: needinfo?(svoisen) → needinfo?(emcdonough)
See Also: → 1615274
Assignee: nobody → emcdonough
Flags: needinfo?(emcdonough)
Whiteboard: [layout:print-compat][layout:print-triage:p1] → [print2020_v77][layout:print-triage:p1][layout:backlog:2020:77]
Whiteboard: [print2020_v77][layout:print-triage:p1][layout:backlog:2020:77] → [print_v77][layout:print-triage:p1][layout:backlog:2020:77]
Depends on: 1626133
See Also: → 1626790
Status: NEW → ASSIGNED
Whiteboard: [print_v77][layout:print-triage:p1][layout:backlog:2020:77] → [print_v77][layout:print-triage:p1][layout:backlog:77]
Attachment #9137230 - Attachment is obsolete: true

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

Attachment #9137231 - Attachment description: Bug 1564128 part 2 - Apply animations to cloned nodes as fixed styles when creating static document clones. → Bug 1564128 part 2 - Copy animations to static document clones and pause them
Severity: normal → S3
Whiteboard: [print_v77][layout:print-triage:p1][layout:backlog:77] → [print_v78][layout:print-triage:p1][layout:backlog:78]
Target Milestone: --- → mozilla78
Whiteboard: [print_v78][layout:print-triage:p1][layout:backlog:78] → [print2020_v78][layout:print-triage:p1][layout:backlog:78]
Attachment #9144461 - Attachment description: Bug 1564128 part 1 - Add constructor for KeyframeEffect which copies the properties of another effect but not the target. → Bug 1564128 part 1 - Add copy constructors for Animation and KeyframeEffect to copy properties but not the target.
Attachment #9144461 - Attachment description: Bug 1564128 part 1 - Add copy constructors for Animation and KeyframeEffect to copy properties but not the target. → Bug 1564128 part 1 - Add clone function for Animation and constructor for KeyframeEffect to copy properties but not the target.
Attachment #9137231 - Attachment description: Bug 1564128 part 2 - Copy animations to static document clones and pause them → Bug 1564128 part 2 - Copy animations to static document clones
Pushed by ccoroiu@mozilla.com:
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

\o/ Thank you Emily!

Regressions: 1669933
Duplicate of this bug: 1626790
You need to log in before you can comment on or make changes to this bug.