* TITLE/SUMMARY [PP] Viewing animated GIF for ~20 minutes results in "total spankage" (broken out of bug #2148) * STEPS TO REPRODUCE 0) Launch Apprunner 1) View a page with an animated GIF. (I've been using http://www.prometheus-music.com/about.html, scrolling to the bottom of the page. Please note that this GIF doesn't quite animate as a result of this page triggering bug #6393; if you'd prefer, I can investigate this further and confirm that this bug occurs with just a working animated GIF.) 2) Go do something else 10-20 minutes. * RESULT - What happened After a while, Seamonkey will demonstrate signs of what Simon Fraser described as "total spankage". (I assume this is a highly technical term used by Mac engineers. ;-) More specifically, the GIF will animate, the page chrome (from the left-hand border of the chrome, ending at the left-hand border of the throbber) will be overwritten with the page content. The entire page content region will animate from left to right (as well as a second throbber). It's hard to explain, so I'll include a PICT or two (no druids, sorry). - What was expected Behavior equivalent to Communicator 4.x * REGRESSION - Occurs On Mac OS Apprunner (5.13.99 AM optimized build) - Can't Reproduce On Linux Apprunner (5.13.99 AM optimized build) Win32 Apprunner (5.13.99 AM optimized build [NT 4, Service Pack 3]) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.6 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.

Wacky. I took several snapshots (Command-Shift-3), received aural feedback that each one had taken place, the hard drive had plenty of space...and not a single one actually worked. So, no images; sorry. If you'd like this reproduced, just drop by.

[Parenthetically, yes, I did confirm that having Mozilla as the foreground app doesn't inhibit the screen snapshot feature.]

Puhing my Mac-specific bugs to M9 before reassigning them to someone else.

Reassigned to dcone

After talking with Pam, seems the leak is in the ImageLibrary. Let me know how I can help.. if I can. This is probably a dupicate also, I will let her put in the Dup bug number.

ok. I think this bug will be cleared up when sfraser & I check in our 'porkjet' changes. There is a leak in the gifdecoder that would accumulated with an animated gif. The crash is due to the fact, allocations that fail were not caught with a error code. These changes propogate the error info through the components. pending review. -pn

Annnnnd, I got no crash and/or spankage when I left my mac apprunner running an animated gif overnight. And this is before the porkjet checkin. Eli: What are you seeing on a release build.

I'm not seeing this problem on my mac. I'm pushing the milestone to m12 for more testing.

[was out of the office yesterday --- will give this a shot during the Seamonkey all-hands.]

Using the 1999110808 build, I left this running for 8 minutes, at which point the animated GIF memory leak terminated the animation. Thus, I'm marking this as dependent upon 15817, as Seamonkey won't stay up long enough to verify until that's fixed.

I'm calling this a dupe of 15817. -pn *** This bug has been marked as a duplicate of 15817 ***

Agreed. Marking as verified dup of 15817.