242237 - ability to freeze (and thaw) all page animation: GIFs, DHTML (e.g. to prevent "DHTML popup ads")

Status: NEW

(Core :: General, enhancement)

Description

[Dan M]

Now that good tools to control unrequested windows are becoming common,
advertisers are moving into the same window as the actual page content. It's
taken a surprisingly long time. It's going to get worse.

I'm not advocating getting rid of all advertising. I'm just advocating a way to
control the really obnoxious "my first marketing job" stuff. Unrequested windows
are very annoying because they force your attention away. In-page animation is
less distracting, but not very much. I've actually trained myself to not even
glance at the part of a page that's jumping up and down, demanding my attention.
This is unnatural and it's going to get me run over in a crosswalk some day. Or
eaten by a cougar. It upsets me that I have to do this to myself.

I tend to watch TV with closed captioning on because at least the steady black
and white text is less distracting than the in-show advertising. Behind the
unattractive black text box I can see the edges of huge swaths of animated crap
sliding in and flashing and gyrating and being orange. Turn off closed
captioning and I can feel my pupils contracting to fight the light. TiVo, bless
them, brought TV to this. Popup controls will do the same thing to the web. I've
uninstalled Flash because it was only used to annoy me.

You can't escape advertising. In my opinion you don't want a complete escape.
But it seems reasonable to clamp down on the animated stuff. I suggest an
enhancement allowing the user control over page animations. Animated elements
should be stoppable and restartable, individually and page-wide.

If it survives, this bug could be a metabug bringing together a range of smaller
tasks to make this happen. Much of what needs to be done already exists as
hidden preferences and extensions. I think they should be brought together in a
single pref panel and enhanced. Perhaps this is an extension, but it will
require some core hacking as well.

Animated GIFs can be deanimated system-wide. I'd like to see finer control: the
ability to start and stop them, individually and page-wide. I'd love to see (the
configurable option to have) a little handle next to each animated GIF
signifying that it can be animated; click here to start it up. Or stop it again.
Maybe it animates automatically on :hover. A similar button in the chrome
toolbar could return the entire page to its jumping, flashing self.

There's an extension available for hiding Flash objects, and showing them when a
little placeholder is clicked. That's useful. I'd love to see Mozilla capable of
capturing and displaying the first frame, and starting and stopping the animation.

I'm beginning to see brightly coloured DIVs sliding over the page content as it
loads. Today this happens mostly on test sites, but occasionally on real sites.
These sites suddenly become less annoying if one uses CAPS to disable
setInterval and setTimeout. It would be nice if these two functions also could
be stopped and started, page-wide.

Others?

Comment 1

[Dan M]

Attachment: access to PresContext::SetAnimationMode for chrome script

I think most of this bug should be implemented as an extension. Unfortunately
it's not entirely possible without some core code help. This patch gives a
script extension the ability to stop and start animated GIFs.

Comment 2

[Johnny Stenback (:jst)]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

+interface nsIDOMWindowAccess : nsISupports {
+
+  void    setImageAnimationMode(in unsigned short aMode);
+};

Hey Dan, how would you feel about renaming this nsIDOMWindowUtils, to make it
more generic. That way we could put other non-access related things here in the
future too, things that we want to access from JS in our code, but not from
webpages?

Comment 3

[Dan M]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

Sure, that's a fine name. Well as long as the concept is acceptable, consider
the name changed and yourself on the r= seat :)

PS this change is necessary to get at background animated GIFs from script. As
far as I know. Images that belong to image elements are no problem.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

>+[scriptable, uuid(7e1ec6ff-2e67-4b26-aa39-a3eb2a3b8a4e)]
>+interface nsIDOMWindowAccess : nsISupports {
>+
>+  void    setImageAnimationMode(in unsigned short aMode);

How about:

  readonly attribute unsigned short imageAnimationMode;


>+class nsDOMWindowAccess : public nsIDOMWindowAccess,
>+                          public nsSupportsWeakReference
>+{
>+public:
>+  nsDOMWindowAccess(GlobalWindowImpl *aWindow) {
>+    mWindow = aWindow;

Use an initialization list.  E.g:

  nsDOMWindowAcces(GlobalWindowImpl *aWindow) : mWindow(aWindow) {}


>Index: dom/src/base/nsGlobalWindow.h
>===================================================================
>RCS file: /cvsroot/mozilla/dom/src/base/nsGlobalWindow.h,v
>retrieving revision 1.225
>diff -u -p -r1.225 nsGlobalWindow.h
>--- dom/src/base/nsGlobalWindow.h	26 May 2004 18:10:47 -0000	1.225
>+++ dom/src/base/nsGlobalWindow.h	27 May 2004 23:33:12 -0000
>@@ -293,6 +293,7 @@ protected:
>   nsRefPtr<BarPropImpl>         mPersonalbar;
>   nsRefPtr<BarPropImpl>         mStatusbar;
>   nsRefPtr<BarPropImpl>         mScrollbars;
>+  nsCOMPtr<nsIWeakReference>    mWindowAccess;
>   nsTimeoutImpl*                mTimeouts;
>   nsTimeoutImpl**               mTimeoutInsertionPoint;
>   PRUint32                      mTimeoutPublicIdCounter;


It kind of sucks that we put an extra ptr here on the window; the alternative I
propopsed to johnny was to turn the nsIDOMWindowUtils interface into a service
to which the actual window would get passed in as an argument.	The other
upshot of doing things that way would be that you wouldn't need to call
GetInterface() on every window you need to do this.  Jst seemed to think the
way in the patch (using getInterface) was slightly better and it doesn't really
matter much to me, I'm just including this comment here for posterity.	:-)

r=caillon with my other comments addressed and jst's name change as well.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #4)
> (From update of attachment 149457 [details] [diff] [review])
> >+[scriptable, uuid(7e1ec6ff-2e67-4b26-aa39-a3eb2a3b8a4e)]
> >+interface nsIDOMWindowAccess : nsISupports {
> >+
> >+  void    setImageAnimationMode(in unsigned short aMode);
> 
> How about:
> 
>   readonly attribute unsigned short imageAnimationMode;

Er, I meant writeonly.  But come to think about that, I don't guess we support
that.  Which sucks.  So nevermind this.  :-D

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

sr=jst

Comment 7

[Dan M]

It'd be easy enough to make it a full access, read- and write-able attribute.
Come to think of it, why not?

Comment 8

[[e-mail]]

(In reply to comment #0)
>I'm beginning to see brightly coloured DIVs sliding over the page content as it
>loads. Today this happens mostly on test sites, but occasionally on real sites.
Dilbert springs to mind... what's really annoying is that the stupid advert
obscured the calendar so you couldn't browse the archive properly.

Comment 9

[[e-mail]]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

Since your helper object doesn't have any state you could simply create a new
one every time someone needs one, rather than caching it.

Comment 10

[Dan M]

I debated checking this in at all because it doesn't address the really useful
part, stymieing animated DHTML. I'm not even sure it's possible to do a decent
job of that. Finally I decided it was somewhat useful and could lay groundwork
for other tasks (like bug 245920 for which admittedly we haven't yet even
figured out what approach we want to take). And maybe some bright person will
figure out some good animated DHTML heuristics that can be layered on.

Agreed at this point the cached helper object isn't strictly necessary. But four
additional bytes per DOM window seems cheap to me, and I was hoping to save some
heap thrashing. Which is better? I imagine it's a wash.

Comment 11

[Dan M]

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

Comment 12

[Dan M]

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

Comment 13

[Matthias Versen [:Matti]]

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

Comment 14

[Dan M]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

I need the DOMWindowUtils object for bug 172962.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

too late for feature changes on the branch.

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

my bad. a couple of us missed the dependency. a=asa for checkin to the aviary
branch.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

Should probably sync this to 1.7 branch too...

Comment 18

[Steven Hunter]

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

Comment 19

[Dan M]

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

Comment 20

[Phil Ringnalda (:philor)]

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

Comment 21

[Asa Dotzler [:asa]]

This bug seems to have an aviary branch checkin associated with it. If this has
landed on the aviary branch (as much as it's going to for 1.0) can you please
add the "fixed-aviary1.0" keyword? Thanks.

Comment 22

[Mime Čuvalo]

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

Comment 23

[Manish Jethani]

Does this bug address the Flash issue?

Comment 24

[Asa Dotzler [:asa]]

Comment on attachment 149457 [details] [diff] [review]
access to PresContext::SetAnimationMode for chrome script

a=asa for 1.7.x checkin.

Comment 25

[Stefan Borggraefe]

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

Comment 26

[Mike Kaply [:mkaply]]

Why is this bug still open?

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

was this ever checked in to the trunk?

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

and why exactly are we adding non-frozen files to the SDK???

Comment 29

[Benjamin Smedberg]

This interface should definitely not have been in SDK_XPIDLSRCS. XPIDLSRCS is
the correct place for non-frozen interface. We should correct this on the 1.7
branch and replace the 1.7.5 SDKs that have this interface incorrectly included.

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: move this iface to XPIDLSRC

Comment 31

[Chase Phillips]

[cmp@spruce base]$ cvs commit Makefile.in
Checking in Makefile.in;
/cvsroot/mozilla/dom/public/idl/base/Makefile.in,v  <--  Makefile.in
new revision: 1.13.28.3; previous revision: 1.13.28.2
done

Comment 32

[Chase Phillips]

Comment on attachment 169070 [details] [diff] [review]
move this iface to XPIDLSRC

FYI, after committing this patch to MOZILLA_1_7_BRANCH, I moved the 1.7.5
release tag to cover the new revision of Makefile.in.  Before doing so, I
applied a new tag (MOZILLA_1_7_5_RELEASE_ORIG) to reflect the revision we
originally shipped 1.7.5 as.

Comment 33

[Chase Phillips]

New Gecko SDK files have been generated and put in place for Mozilla 1.7.5. 
Could take an hour or two to propagate to all of the mirrors.

Comment 34

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 169070 [details] [diff] [review]
move this iface to XPIDLSRC

Too late for 1.7.6.  Also a friendly reminder that things like this need to go
in both branches, not just one.  If approval is still wanted for future
releases on this branch, please request for both 1.7.x and aviary.

Comment 35

[Jesse Ruderman]

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

Comment 36

[Jesse Ruderman]

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

Comment 37

[Jesse Ruderman]

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

Comment 42

[ipatrol]

Go to http://www.popuptest.com/ and see the drop down and sticky popups.