815408 - CSS animation in print preview is animated

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Andy Boze]

Attachment: HTML doc with animated <p> element

I have a Web page that contains a <p> animated using CSS animation property and @keyframes. When I do a print preview, the animation is animated in the print preview. Perhaps this is the normal behavior, but I didn't expect it. This happens in both FX 17 and SeaMonkey 2.17a1. At the end of the animation in print preview, the animated <p> is blank; in SM, the animated <p> displays as just like the page in the browser after the animation stops. Further, if I print the page from the print preview screen (to PDF), both FX and SM print the animated <p>, but not at the end of the animation, rather at the beginning of the animation.

I know I can use an @media rule to produce the desired results; I'm just not sure that FX and SM are doing what they should when an @media rule is not present to specify print behavior.

I've attached a couple of files that should show the problem -- an HTML file with an animated <p> and a PDF showing the printed result

Comment 1

[Andy Boze]

Attachment: "Printed" PDF of HTML doc

Comment 2

[Matthias Versen [:Matti]]

confirmed with Seamonkey trunk on Windows7

Comment 3

[Robert Utasi [:hunboy]]

workaround: at the end of the css structure/file:

@media print { p#anim {animation: none;} }

I can repro this bug under windows xp and fedora linux as well.

So platform should be --> ALL
Version should be --> Trunk
Keywords : css-animation


In my opinion this is not specifically a print preview issue, this is a print issue. I'm not sure if printing (and print preview) is a paged media or visual, but w3c says: animation is only for visual media.

In my opinion the expected behavior at print is ignoring animation.

links:
www.w3.org/TR/css3-animations/
https://developer.mozilla.org/en-US/docs/Web/CSS/@media#Media_groups

To clarify this I asked needinfo.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, we shouldn't be running animations in print-preview or printing.

There are two options in theory here, but one is clearly better:
http://lists.w3.org/Archives/Public/www-style/2013May/0650.html

I think we should fix things to not have animations (and perhaps also disable transitions code) for static media.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Work in progress patch at https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/be41c4ea95ca/print-ignore-animations-transitions

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Ignore CSS transitions and animations in print and print preview.

Note that this patch has a little bit of a belt-and-braces aspect to it.
In each file, either one of the changes should be sufficient, but one of
them prevents us from doing unneeded work and the other one ensures that
we never apply style resulting from transitions and animations even if
somehow we do that work.

Also note that the tests don't actually test anything usefully, since
the reftest harness doesn't currently make the pres context non-dynamic.
(Thus they're marked as failing.)  I'm not sure what I should do about
that, though I'm considering just deleting the tests entirely.

Comment 7

[Robert Utasi [:hunboy]]

David, yes I've read your mess at w3c: one user wants start state of animation and an other one wants final state. Someone doesn't want to see at all. The sitebuilder, who is able to define "from" and "to" rules also able to add the static css code that state rules he wants to see in print (and in old browsers). The animation overrides it when fired.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 754353 [details] [diff] [review]
Ignore CSS transitions and animations in print and print preview.

r=me

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/14b9894272cb

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/14b9894272cb

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://lists.w3.org/Archives/Public/www-style/2013May/0783.html resolved that this is the normal behavior but that implementations can also experiment with snapshotting if they wish.

Comment 12

[Robert Utasi [:hunboy]]

Attachment: snapshot printing workaround

David, I've read the mailing list and about snapshot issue.

I've prepared a workaround testcase which one does this. It works on the trunk after this bugfix. (I mean prints the snapshot when paused)

I have tried to use the eventlistener to make it automatic, but currently no way. So I would like to suggest you to think about supporting some type of animationpaused and animationresumed listeners at animationEvent, but this requires w3c consultation coz currently not in the draft.