11875 - [FEATURE] Stop animation/applets

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Matthew Tuck [:CodeMachine]]

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

Comment 1

[don]

Move to M15.

Comment 2

[don]

Move to M16 for now ...

Comment 3

[Paul MacQuiddy]

spam, changing selected qa contact on selected bugs from [e-mail] to 
[e-mail]

Comment 4

[Ben Bucksch (:BenB)]

Backend might be done with bug 33810.

Comment 5

[don]

Move to M20 target milestone.

Comment 6

[don]

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).

Comment 7

[johng]

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.

Comment 8

[Claudius Gayle]

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.

Comment 9

[Hallvard B Furuseth]

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.

Comment 10

[Matthew Tuck [:CodeMachine]]

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.

Comment 11

[Hallvard B Furuseth]

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

Comment 12

[Paul Chen]

nav triage team:

Sounds good, but don't have time for beta1. Marking nsbeta1-.

Comment 13

[johng]

not sure who should look at this, reassigning to pchen

Comment 14

[Paul Chen]

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

Comment 15

[Peter Lubczynski]

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

Comment 16

[Jesse Ruderman]

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

Comment 17

[Gregory P. Smith]

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.

Comment 18

[Jesse Ruderman]

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...

Comment 19

[Asa Dotzler [:asa]]

-> default assignee

Comment 20

[Peter Trudelle]

->future

Comment 21

[R.K.Aa.]

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

Comment 22

[Gerold Veith]

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

Comment 23

[Peter Trudelle]

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

Comment 24

[Peter Lubczynski]

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.

Comment 25

[Ben Bucksch (:BenB)]

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.

Comment 26

[Jonadab the Unsightly One (Nathan Eady)]

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.

Comment 27

[R.K.Aa.]

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

Comment 28

[Robert White]

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().

Comment 29

[Robert Kaiser]

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

Comment 30

[Robert Kaiser]

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

Comment 31

[Robert Kaiser]

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

Comment 32

[Robert Kaiser]

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

Comment 33

[Robert Kaiser]

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

Comment 34

[Robert Kaiser]

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

Comment 37

[WulfTheSaxon [:Wulf]]

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

Comment 38

[nidaisfree]

Happy birthday, Bug 11875!

Happy 11 years!

Comment 39

[Job Bautista]

Shouldn't this one be an RFE?

Comment 40

[Frank-Rainer Grahl (:frg)]

Shouldn't this one be an RFE?

Probably but ancient bug and unless someone adds a patch we usually don't touch them to avoid sending emails to people on cc

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/424a3e249d93
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11875 - Prevent mixup of region / locale based search engines