[FIX]Print Preview animates GIFs!

RESOLVED WORKSFORME

Status

()

Core
Printing: Output
P3
normal
RESOLVED WORKSFORME
19 years ago
4 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: rods (gone))

Tracking

Trunk
Future
x86
Windows 95
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: troy → michaelp
Component: Layout → Rendering

Comment 1

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

Michael, this is a fun one

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 2

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

Updated

19 years ago
QA Contact: 4110 → 1698

Comment 3

19 years ago
changing QA contact to elig@netscape.com

Updated

19 years ago
Assignee: michaelp → syd
Status: ASSIGNED → NEW

Updated

19 years ago
Assignee: syd → dcone

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11

Updated

19 years ago
Blocks: 11275

Updated

19 years ago
Target Milestone: M11 → M20

Comment 4

19 years ago
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.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → REMIND

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 5

19 years ago
Verified REMIND.
(Reporter)

Comment 6

18 years ago
Reopening and marking Future.

It would be nice to get this fixed, though. Animated GIFs in a print preview
is quite silly...
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
Target Milestone: M20 → Future

Comment 7

18 years ago
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.
Depends on: 14768

Updated

18 years ago
Assignee: dcone → pnunn
Status: REOPENED → NEW

Comment 8

18 years ago
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

18 years ago
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

Assignee: pnunn → dcone

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
QA Contact: elig → petersen
(Reporter)

Updated

17 years ago
Whiteboard: [Hixie-P5]

Comment 10

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

Comment 11

17 years ago
print preview is not a feature.. so this is invalid till that feature is 
working.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 12

17 years ago
Reopening and reassigning to me so that I don't lose track of this bug.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 13

17 years ago
I'll reassign as appropriate once we have print preview again.
Assignee: dcone → ian
Status: REOPENED → NEW
Whiteboard: [Hixie-P5] → [Hixie-P5] (py8ieh: pending...)

Comment 14

17 years ago
Why isn't print preview handled by operating systems?

Comment 15

17 years ago
It appears to be, by Mac OS X.
(Reporter)

Comment 16

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

Comment 17

17 years ago
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.
(Reporter)

Comment 18

17 years ago
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.
(Assignee)

Updated

17 years ago
Blocks: 103890

Comment 19

17 years ago
Just a heads up: print preview is back in recent builds.  Gifs are still 
animated.
(Assignee)

Comment 20

17 years ago
taking bug
Assignee: ian → rods
(Assignee)

Comment 21

17 years ago
I don't think this is a compositor issue, changing to "printing"
Status: NEW → ASSIGNED
Component: Compositor → Printing
Summary: Print Preview animates GIFs! → [FIX]Print Preview animates GIFs!
Whiteboard: [Hixie-P5] (py8ieh: pending...)
(Assignee)

Updated

17 years ago
QA Contact: petersen → sujay
(Assignee)

Updated

17 years ago
Target Milestone: Future → mozilla0.9.7
(Assignee)

Comment 22

17 years ago
Created attachment 57624 [details] [diff] [review]
patch for stopping and starting animated gifs

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

Updated

17 years ago
Severity: minor → normal
(Assignee)

Comment 23

17 years ago
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

17 years ago
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.
Attachment #57624 - Flags: superreview+

Comment 25

17 years ago
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))
(Assignee)

Comment 26

17 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 27

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

Comment 28

16 years ago
verified.
Status: RESOLVED → VERIFIED
*** Bug 129471 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
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

16 years ago
Bug 133808 still exists in Win98 build 2002081716 and seems quite related to
this bug, so I'm reopening it...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.7 → ---

Updated

15 years ago
Priority: P2 → P3
Target Milestone: --- → Future

Updated

15 years ago
Blocks: 119597
Now that bug 133808 is confirmed as fixed, this can be closed as well.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.