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.

Yeah, if we're going to be WYSIWYG then animating an image seems wrong. Michael, this is a fun one

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

changing QA contact to elig@netscape.com

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.

Verified REMIND.

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

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.

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.

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

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

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

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

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

Why isn't print preview handled by operating systems?

It appears to be, by Mac OS X.

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

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.

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.

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

taking bug

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

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

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

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))

fixed

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

verified.

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

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?

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

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