Open Bug 96873 Opened 23 years ago Updated 16 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.