Bug 23945 - Please add a function to WebKit to stop all in-progress GIF animations (on the current page only)
: Please add a function to WebKit to stop all in-progress GIF animations (on th...
Status: NEW
: WebKit
Images
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To:
:
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2009-02-12 23:58 PST by
Modified: 2013-12-16 10:35 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-02-12 23:58:02 PST
Please add a function to WebKit to stop all in-progress GIF animations *on the current page only*.  (Then, I hope future WebKit-based browsers will make it so that pressing the Escape key while viewing a webpage will call this function.  For example, I hope Safari will fulfill the feature request http://code.google.com/p/chromium/issues/detail?id=5276 .)
------- Comment #1 From 2009-02-13 00:04:38 PST -------
This would be handy because some web browsers (Safari and Google Chrome) have very minimalist UI and don't have a preference to prevent all animated GIFs from animating.  But Google Chrome is full of features only accessible by keyboard[1] like Ctrl+Shift+T and Shift+Esc.  So I am sure they would be glad to add an Esc feature if WebKit had this function.

^  [1].  see http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95743
------- Comment #2 From 2009-03-28 19:51:48 PST -------
Please implement this! It's the only thing keeping me from google chrome.
------- Comment #3 From 2009-11-30 07:57:37 PST -------
This function would be really appreciated!

Alternatively, an option like Fx's image.animation_mode (in about:config) would work too.
------- Comment #4 From 2009-12-03 07:00:44 PST -------
Yes please. Safari used to have a way to do suppress animated GIFs (PithHelmet plug-in) but it relied on an input interception technique that Apple first deprecated, then disabled. PithHelmet provided somewhat granular control: looping GIF animations could run once, indefinitely, or not at all. Adding the hook to Webkit would advantage multiple browsers.
------- Comment #5 From 2009-12-03 07:36:53 PST -------
*** This bug has been confirmed by popular vote. ***
------- Comment #6 From 2009-12-03 09:19:00 PST -------
This bug has been confirmed by popular vote.  Can we get a radar ticket for this, please?
------- Comment #7 From 2009-12-08 11:44:19 PST -------
See also bug 9767.
------- Comment #8 From 2009-12-08 11:46:37 PST -------
<rdar://problem/3483064>
------- Comment #9 From 2009-12-08 11:52:00 PST -------
Sorry, <rdar://problem/3483064> is a Safari feature request. <rdar://problem/7171719> is the correct one.
------- Comment #10 From 2009-12-08 11:56:35 PST -------
Also, the aforementioned Safari feature request is for something subtly different, so a new bug filed to <http://bugreport.apple.com> would be appreciated.
------- Comment #11 From 2009-12-08 12:07:06 PST -------
Note that other browsers already support this feature: on Firefox and IE, pressing ESC will halt animated GIF images on the current tab.

Additionally, Firefox provides an advanced preference ("image.animation_mode") to set GIF animation to "always" "never" or "once" (where the GIF animates through once but then stops on the last frame before repeating).

It would be great if WebKit browsers supported this, but obviously they can't implement it until there's a WebKit API to support it.
------- Comment #12 From 2009-12-08 12:08:39 PST -------
I can't see radars, but I also filed <rdar://problem/7453553> on this.  (ap advocated a very general feature request; smfr advocated a more specific API request.  I presume both issues have been filed at some point.)
------- Comment #13 From 2009-12-15 14:54:40 PST -------
Adding yet another comment in support of this. I'd use Safari/Chrome far more often if I could just stop animated GIFs without having to block the images in question entirely.
------- Comment #14 From 2011-07-27 20:45:40 PST -------
They aren't just unsightly.
They kill batteries and remote desktop connections.

Yet, I want to use Chrome for many other reasons. If I can't handle the expense of animated gifs, I certainly can't handle the even greater expense of running Firefox.

I notice the Android browser does not play animated gifs!

What does the Chromebook do? I know the iPad plays them and I know it costs significant cpu and battery.
If you don't care about me, maybe you care about making the Chromebook and iPad as good as possible?

A single animated gif will increase my cpu usage on an otherwise idle Vaio P from 1%-4% to 12%-20%. One single not-very-large gif. Under the best of circumstances this device only gets between 3-4 hours of run time even with the extra capacity battery. 

It's a real problem.
------- Comment #15 From 2011-11-28 13:01:06 PST -------
Why is it taking so long to implement this change? Are there technical issues? If so, what are they?
------- Comment #16 From 2012-05-02 14:00:52 PST -------
(In reply to comment #15)
> Why is it taking so long to implement this change? Are there technical issues? If so, what are they?

Maybe because it is assigned to nobody.

I am too (comment#11) with the firefox way, doing once globally, no need for this bandwidth and CPU consumption for these effects.
------- Comment #17 From 2012-05-10 22:51:10 PST -------
I too would like this function. I opened a bug report against Konqueror, and was pointed here (https://bugs.kde.org/show_bug.cgi?id=298897).

Konqueror has a setting for animations: Enabled/Disabled/Show Only Once. Also, you can configure the browser to use either KHTML or WebKit. The animations setting works in KHTML, but not in WebKit, which is... interesting, considering WebKit's history.

Dare I suggest the relevant code should be ported from KHTML?
------- Comment #18 From 2013-12-15 16:08:26 PST -------
Safari appears to inhibit updating while the escape key is held down, except each mouse event allows another update to slip through.  Not as good as pause but better than nothing.