2586 - [FIX]Print Preview animates GIFs!

Status: RESOLVED WORKSFORME

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

Description

[Hixie (not reading bugmail)]

Quite comical, really.

In Print Preview, animated GIFs are still animated. I would love to say
that it is not a bug, but unless the printing code can then back the
preview up by animating the printed copy, I suggest the Print Preview
should show a static image.

This also applies to applets, Javascript, "hover" and "active" pseudo
classes, and so on.

Comment 1

[troy]

Yeah, if we're going to be WYSIWYG then animating an image seems wrong.

Michael, this is a fun one

Comment 2

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 3

[Christine Hoffman]

changing QA contact to [e-mail]

Comment 4

[dcone (gone)]

There is no way to have layout do a static image on an animated gif at the
moment.  Maybee sometime in the future we can make a switch that will stop the
animation.. but for the time being.. this will be a low priority.

Comment 5

[Eli Goldberg]

Verified REMIND.

Comment 6

[Hixie (not reading bugmail)]

Reopening and marking Future.

It would be nice to get this fixed, though. Animated GIFs in a print preview
is quite silly...

Comment 7

[Daniel Bratell]

Someone is working on flags to control gif animations which should be useable 
for this bug (see bug 33810). This is to be able to control animations in the 
editor (see bug 14768) where they don't want animations either. I'll mark this 
bug as dependent on that so that the solution they used can be copied to the 
print preview.

Comment 8

[dcone (gone)]

There are no API's to do this, will give this to Pam Nunn.. I suggest a remind 
since I don't think this is a high priority for this release.

Comment 9

[pnunn]

Don:

As of last week you can set 'animation controls' from
nsPresContext. The editor folk needed it too.


Go to nsIFrameImageLoader.h 
Here are the possible settings:

enum nsImageAnimation {
    eImageAnimation_Normal      = 0,    // looping controlled by image
    eImageAnimation_None        = 1,    // don't loop; just show first frame
    eImageAnimation_LoopOnce    = 2     // loop just once
};

In image lib the control field (for now) is
ic->animate_request.

To set it from  nsPresContext, take a look at
mozilla/layout/base/src/nsPresContext.cpp ~line 941
where loader->init() is called in nsPresContext::StartLoadImage().

Reassigning to you, since you know where the 
print stuff should be hooked up.
Call me if you need to know more...
-Pam

Comment 10

[Chad Austin]

I don't even see a print preview anymore...  (someone tell me how to get to it?)
 What's the status here?

Comment 11

[dcone (gone)]

print preview is not a feature.. so this is invalid till that feature is 
working.

Comment 12

[Hixie (not reading bugmail)]

Reopening and reassigning to me so that I don't lose track of this bug.

Comment 13

[Hixie (not reading bugmail)]

I'll reassign as appropriate once we have print preview again.

Comment 14

[Jesse Ruderman]

Why isn't print preview handled by operating systems?

Comment 15

[Greg K.]

It appears to be, by Mac OS X.

Comment 16

[Hixie (not reading bugmail)]

Jesse: On Linux, exactly how would you say that should work?

Comment 17

[Jesse Ruderman]

I don't use Linux much, and I haven't written any graphical programs for it, so 
I don't know how it would work.

This is what I would expect to happen if print preview worked at the OS level 
(I haven't seen Mac OS X's print preview feature):

- Application developers would be able to add a print preview feature much more 
easily, so more apps would have the feature.  (The OS-level feature might even 
be a button in the print dialog, making it work with old applications as well 
as new ones.)

- Users wouldn't have to figure out a new UI each time they select "print 
preview" in a new application.

- The print preview window would be grayscaled if the printer is a black-and-
white printer, so the user would be able to tell if there are contrast problems 
with the colors chosen.

- The print preview window would be able to show the actual fonts that will be 
used to print, rather than the font shown in a normal document window scaled to 
the zoom factor of the print preview window.

Comment 18

[Hixie (not reading bugmail)]

Jesse: The problem on Linux is that there is no one subsystem that is in charge
of both the windowing system and the printing system, and the OS doesn't do either.

Comment 19

[rcummins]

Just a heads up: print preview is back in recent builds.  Gifs are still 
animated.

Comment 20

[rods (gone)]

taking bug

Comment 21

[rods (gone)]

I don't think this is a compositor issue, changing to "printing"

Comment 22

[rods (gone)]

Attachment: patch for stopping and starting animated gifs

This also includes the beginnings of code for switching back to galley mode
when in PrintPreview

Comment 23

[rods (gone)]

Overview patch:
Renamed the mIsDoingPrintPreview to mIsCreatingPrintPreview and added a new 
variable mIsDoingPrintPreview which is NOT static and is per DocViewer, that way 
the DocumentViewer knows whether it is in PP mode.

For now the Print Preview menu item toggles between print preview and galley 
mode.

Also, added method for switching back to galley mode (re-creates lall the 
frames)

Added code to the PresContext to walk the content tree looking for images and 
its hash table of images, so when the Animation mode changes they can be turned 
on or off.

Added code in the imgContainer to start and stop animation depending on the 
current state of the animation.

Comment 24

[Marc Attinasi]

Comment on attachment 57624 [details] [diff] [review]
patch for stopping and starting animated gifs

sr=attinasi
One thing I dislike about the change is having to walk every image to disable
the animation when, in reality, very few of the images will even be animated.
It would be far better to tell the imageLib that animation is globally
disabled, and then every animation would be overridden until that global flag
was cleared. Granted, PP is not a performance intensive operation, but an O1 is
better than an O2n algo anyday.

Comment 25

[dcone (gone)]

r=dcone.
one comment.. it would be nice to have #defines or enums for
even if its just in this file.. it would make it easier to maintain.. and 
document what your trying to test for.
if (mAnimationMode == 0 && (aAnimationMode == 1 || aAnimationMode == 2))

Comment 26

[rods (gone)]

fixed

Comment 27

[:deanis74]

Verified with 2002010703 on Win2K using bongo.gif out of res/samples/sampleimages.
Mac?  Linux?

Comment 28

[sujay]

verified.

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 129471 has been marked as a duplicate of this bug. ***

Comment 30

[rcummins]

Not really sure if bug 133808 is a dupe of this bug, the former involves
changing orientation in Print Preview and GIFs becoming reanimated (but only on
pages with frames).  I was able to verify this behavior on trunk build
2002070708 under Windows 98.  Would bug 2586 need to be reopened for this
special case?

Comment 31

[rcummins]

Bug 133808 still exists in Win98 build 2002081716 and seems quite related to
this bug, so I'm reopening it...

Comment 32

[Simon Montagu :smontagu]

Now that bug 133808 is confirmed as fixed, this can be closed as well.