Open Bug 96873 Opened 23 years ago Updated 15 years ago

animated gif files should not animate after being inserted

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: TucsonTester2, Unassigned)

References

Details

(Keywords: polish) 

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1)
BuildID:    20010821

When animated gif files are created and then turned into a link they freeze. 
This happens with any animated gif file.

Reproducible: Always
Steps to Reproduce:
1. Open a new composer page 
2. Click on insert and image
3. Select and animated gif image and click on ok
4. Right click on image and choose create link
5. enter a website and click on ok

Actual Results:  After the image is created as a link then it freezes

Expected Results:  The image should remain animated even when created as a 
link.  This will be useful when creating banners

When creating a animated GIF as a link and freezes, it also creates a graphic 
relic at the bottom right corner
One thing to also note is that if composer is opened with the frozen animated
gif then the browser itself will display the frozen image instead of the
animated one.
Animated gifs in Composer are not supposed to animate.  Is this the issue for 
this bug?
Summary: When animated gif files are created and then turned into a link they freeze → animated gif files are created and then made a link they freeze
that is the issue as far as I know.  So is it a bug then that the gifs are
animating when they are inserted into Composer?  I've always seen them animating
after inserting them into composer.  The gif will only animate in the view it
was inserted in (excluding HTML source which doesn't show the gif at all of
course).  Once you switch to another view the gif will stop animating even if
you switch back.  The gif also stops animating if you add a link or drag and
drop it to a new area.

Steps to Reproduce:
1. Open Composer
2. Insert an animated gif using the image button on the toolbar
3. Observe that the image is animating
4. Switch to any other view and then switch back

Actual Results:  The image stops animating

Expected Results:  I expect that the views would be consistent.  Either the
image will animate or not animate regardless of the view.
-->akkana
Assignee: brade → akkana
Hardware: PC → All
Summary: animated gif files are created and then made a link they freeze → animated gif files should not animate after being inserted
Another Note:  I checked this out in NS 4.7 and it worked.  I was just wondering
why this was taken out.

I tested this out in Netscape 4.7 and the gif was animated after dragging and
dropping and manipulating it in a number of ways.

And I checked animated gifs that are set as backgrounds and they appear to
always animate in the new and old version of composer.  In the new version of
composer it does not matter if you switch back and forth between views, the
background will still animate.  This is unlike the images that are inserted into
the page using the imag button on the toolbar.
*** Bug 96835 has been marked as a duplicate of this bug. ***
Regressed because of the new imagelib, I expect.  We're waiting on imagelib
fixing its "stop animation" functionality.
Depends on: 70030
Confirming based on the dependency and dupe...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Accepting, targeting based on dependencies.  (I suspect this regression will be
fixed automatically once the imglib regression is fixed, if APIs don't change.)
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Priority: -- → P3
akkana, can you supply URLs for the dependencies so that I can ensure this bug
is tracking them correctly?
URL?  Just click on the bug number (bug 70030) listed under "Bug 96873 depends
on", below the attachments table and above the additional comments field.
spam composer change
Component: Editor: Core → Editor: Composer
70030 got put off, so this one has to as well. :-(
Target Milestone: mozilla0.9.5 → mozilla0.9.6
I'm tired of seeing this in my list when it's really just bug 70030.  Sending
over to Pavlov since it's his bug.  If 70030 gets fixed and by some strange
circumstance this bug is still visible, send it back to me.
Assignee: akkana → pavlov
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → mozilla0.9.8
*** Bug 105756 has been marked as a duplicate of this bug. ***
Blocks: 119597
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Priority: P3 → P4
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Target Milestone: mozilla1.2 → mozilla1.0
Target Milestone: mozilla1.0 → Future
Keywords: nsbeta1, polish
Composer triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Product: Browser → Seamonkey
I disagree.  I am building a site where I depend on this behavior.
Assignee: pavlov → composer
QA Contact: sujay
Assignee: composer → nobody
Priority: P4 → --
QA Contact: composer
Target Milestone: Future → ---
I am confused on this one...

Initial reporter requested for animated .gif files to remain animated even after being converted to links or after switching to other view and then back.

At some point it was changed to the opposite (?).

Some people like to have that feature while others don't. So, make it a pref and let user decide. This makes all people happy. Anyhow, the summary of the bug shouldn't have changed to the opposite. Please change it (back) to something like:

'Animated .gif should remain animated after conversion to link or switching views'
You need to log in before you can comment on or make changes to this bug.