I think this is subsumed by the more general system consisting of bug #15148 and bug #15145 (combined with the existing Disable Java preference).

Move to M15.

Move to M16 for now ...

spam, changing selected qa contact on selected bugs from paulmac@netscape.com to claudius@netscape.com

Backend might be done with bug 33810.

Move to M20 target milestone.

John, do we intend to do this feature for NS6? If so, we need to get it on the exception radar for beta 3. (Just re-assign back to me when you comment on this).

Reassigning to claudius so he can describe to me what this feature is - I don't understand. Then you can reassign back to me and I'll make the call.

based on reading the other bugs mentioned I would presume this bugs refers to some way of stopping (or preventing them from starting in the first place) animations and applets. They can be annoying and lots of users may want this. I'm uncertain as to whether this would be accomplished by a user defined pref, additional UI, or the plain old stop button. That's all I know, if anyone else has info, pipe up. no need to reassign to me - I'm on the QAContact.

Speaking as "anyone else", here is my opinion:-) I'd be glad if animated images just weren't implemented. I don't care whether they render as broken images or as the "first" image, if they just go _away_. A separate Mozilla binary without'em would be fine, a prefs setting better. More advanced ways to deal with them would be cool, but for me that's a lower priority. With animations gone, I might not even bother to turn Autoload Images off again as soon as I leave a site where it _has_ to be on. The same goes for anything else which reactivates the browser after it has stopped or I've stopped it: javascript babble, page refresh initiated by the server, anything. But I bet other Bugzilla bugs deal with that. About the Stop button: That one is almost so overloaded that one might want a stop _menu_. I think you'll have to list what _can_ be stopped before we poor users can answer what we want from it. I can think of: 1a. stop download in the window of images but not of the HTML document, 2a. stop download in the window, 3a. stop animation, 4a. stop and block Javascript (or does that come with "stop animation"?), 5a. terminate the window's server connections to avoid refresh from server, 6a. stop everything in the window, chop connections, and stay stopped, 1b-6b. same list as above, but for the current _frame_, 1c-6c. same list as above, but for all of Mozilla. Me, I think I want (in order) 6a, 1a, (2a+3a+4a), 6c.

It appears the original bug report text was eaten a Bugzilla upgrade. What appears as the original text is I think a comment I added later (I've seen this on a couple of bugs). This report is *not* about a pref. That is bug #17686. This is about a button to turn animation on or off temporarily in that particular window, for this session. Hence it's an independent feature. I believe this should be closed out in favour of bug #15148, which is a more general proposal.

Bug #15148 is mostly about preferences to control _existing_ features. This is about a _new_ feature: To disable animations.

nav triage team: Sounds good, but don't have time for beta1. Marking nsbeta1-.

not sure who should look at this, reassigning to pchen

Marking nsbeta1- bugs as future to get off the radar.

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

These four bugs are related: bug 11875 stopping animations with Esc should also stop applet animations bug 19118 Plug-In Manager (ui for choosing mimetype-plugin associations) bug 24418 Allow user to turn on and off rendering of video/audio bug 94035 Allow blocking of any media type by site

ugh, -why- does this bug seem to be so complicated? the stop button in navigator 4.x caused animated images to stop animating. it should do it here. advertisements are too flashy these days making reading any text on a page where they can't be scrolled out of view impossible! this is the only major gripe i have about mozilla/ns6 compared to 4.x. i'm not asking for a way to disable animations for good, stop specific animations or applets. I just want the old simple functionality back.

Greg, bug 70030 covers the problem where the stop button (or the Esc key) doesn't stop image animations. By the way, I've already encountered flash ads on news sites that I wasn't able to stop with the Esc key (in Internet Explorer). I ended up moving my IE window so that the ad was off the screen. I've only had flash for a week, and I'm considering removing it again...

-> default assignee

->future

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

Please, don't forget to stop the blink-Tag, too.

Mass moving all of my open Nav/toolkit bugs to new owner.

hm...I've been thinking about how to do this for Flash 6 and I think it's remotly possible by via scripting. Some privileged JS could enummerate over all the Flash objects in all the windows and call something like StopPlay(). Here are the methods Flash 6 exposes: C:\nstrunk\Plugins>xpt_dump flashplayer.xpt Header: Major version: 1 Minor version: 2 Number of interfaces: 3 Annotations: Annotation #0 is empty. Interface Directory: - ::nsISupports (00000000-0000-0000-c000-000000000046): [Unresolved] - ::FlashIObject (42b1d5a4-6c2b-11d6-8063-0005029bc257): Parent: ::nsISupports Flags: Scriptable: TRUE Function: FALSE Methods: uint32 evaluate(in string, out retval FlashIObject); Constants: No Constants - ::FlashIScriptablePlugin (d458fe9c-518c-11d6-84cb-0005029bc257): Parent: ::nsISupports Flags: Scriptable: TRUE Function: FALSE Methods: uint32 IsPlaying(out retval boolean); uint32 Play(); uint32 StopPlay(); uint32 TotalFrames(out retval int32); uint32 CurrentFrame(out retval int32); uint32 GotoFrame(in int32); uint32 Rewind(); uint32 Back(); uint32 Forward(); uint32 Pan(in int32, in int32, in int32); uint32 PercentLoaded(out retval int32); uint32 FrameLoaded(in int32, out retval boolean); uint32 FlashVersion(out retval int32); uint32 Zoom(in int32); uint32 SetZoomRect(in int32, in int32, in int32, in int32); uint32 LoadMovie(in int32, in wstring); uint32 TGotoFrame(in wstring, in int32); uint32 TGotoLabel(in wstring, in wstring); uint32 TCurrentFrame(in wstring, out retval int32); uint32 TCurrentLabel(in wstring, out retval wstring); uint32 TPlay(in wstring); uint32 TStopPlay(in wstring); uint32 SetVariable(in wstring, in wstring); uint32 GetVariable(in wstring, out retval wstring); uint32 TSetProperty(in wstring, in int32, in wstring); uint32 TGetProperty(in wstring, in int32, out retval wstring); uint32 TGetPropertyAsNumber(in wstring, in int32, out retval double); uint32 TCallLabel(in wstring, in wstring); uint32 TCallFrame(in wstring, in int32); uint32 SetWindow(in FlashIObject, in int32); Constants: No Constants Of course this would only work for Flash 6 that's scriptable and embedded. Full-page plugins aren't scriptable yet due to bug 90256. Quicktime and Real have their own way of being stopped and I'm not sure how to do it for Java. One possible idea is to define and evaneglize a new frozen interface for plugin developers to implement that will have a common Stop() method.

Peter Lubczynski, that sounds like it's likely to fail (for some plugins, in some situations, e.g. can the animation decide to restart?). If I would use such a feature, I'd expect it to work in any case. I wouldn't mind, if it was something "brutal" technically, in fact I'd probably expect something like that. "Stop" is usually not recoverable without reloading the page - pageload halts, page JS halts, animated GIFs should as well, all of them without way to continue, I think. So, I don't think you have to care to make flash animations being able to recover and continue playing after the user said "stop!". How about just taking a "screenshot" of the current state of each plugin, show that and unload the plugins? Or maybe even unload them and just show a placeholder.

If the user wants to restart a stopped item (say, a plugin), that item can just be reloaded. That's an edge case anyway; users who like animations don't stop them in the first place. In most cases, once they're stopped, they're going to stay stopped. So the "take a screenshot and show that" solution seems good to me. If that's too hard to do, a placeholder would be an acceptable kludge. Ideally, the context menu then should have a "reload stopped item" (or s/item/plugin/ or whatever wording the UI people like) option which would reload the item. As far as enhancing the plugin API to support this, there are two good reasons not to do it that way: 1. every plugin would have to implement it separately (bad) and 2. it's honour system then, but we want to enforce the user's decision. If I thought there were a way to do it portably I'd suggest capturing the state of the process so that it can be recreated where it left off if desirec, but that is probably not worth the portability issues it would create; I don't think all Mozilla platforms have that level of process control. So just terminate it. If this bug is implemented, I might be able to tollerate having Flash installed. Regarding Comment 9: refreshes are already covered; in the prefs, under Advanced, under Cache, set it to "once per session", and the expires header will be ignored. I imagine you know about the Once setting for GIF animations.

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

Whatever the killFlash() logic is, it needs to be extended. Go to http://www.homestartunner.com and it works fine. Go to http://story.news.yahoo.com/news?tmpl=story&cid=578&u=/nm/20040212/ts_nm/iraq_abizaid_dc_6 or indeed most of yahoo news and if you get a flash animated ad the killFlash() does nothing noticable. That button, or another very like it, needs to traverse the document tree and make whatever standard plug-in call is made when you navigate away from a page. So the ads leave blank holes. Cry me a river 8-). Clearly the flash programer responsible for animating the ad has the option of hiding/blocking things like the play check-box from the right-click menu. The script-accessible calls are not going to survive with full fuction as, if there isn't an "allow stopPlay() checkbox in the flash compiler interface, there will be soon. Only the WeAreLeavingNow() function (whatever it is) at the raw plug-in inteface is trustworth for termination. Leaving the standard frame-with-torn-image icon in its wake would be "nice" as you could probably do the view/refresh image to call it back if you wanted. Blank is good. Traversing the tree and just unloading everything plug-in-esque would usually be the right thing. Having a drop-down that listed all the plugins on the page and let you unload all of a certian type would be extra sweet. None of this would be version spesific to Flash or anything else, just a nice geneirc UnloadPlugins().

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Shouldn't bug 397302 block this? It's Core, this is SeaMonkey.

Happy birthday, Bug 11875! Happy 11 years!