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?

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

(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 on attachment 149457 [details] [diff] [review] access to PresContext::SetAnimationMode for chrome script sr=jst

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

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

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.

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

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

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

Comment on attachment 149457 [details] [diff] [review] access to PresContext::SetAnimationMode for chrome script I need the DOMWindowUtils object for bug 172962.

Comment on attachment 149457 [details] [diff] [review] access to PresContext::SetAnimationMode for chrome script too late for feature changes on the branch.

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 on attachment 149457 [details] [diff] [review] access to PresContext::SetAnimationMode for chrome script Should probably sync this to 1.7 branch too...

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

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

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

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.

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

Does this bug address the Flash issue?

Comment on attachment 149457 [details] [diff] [review] access to PresContext::SetAnimationMode for chrome script a=asa for 1.7.x checkin.

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

Why is this bug still open?

was this ever checked in to the trunk?

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

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.

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

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

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

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

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

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