Please add a function to WebKit to stop all in-progress GIF animations (on the current page only)
https://bugs.webkit.org/show_bug.cgi?id=23945
Summary Please add a function to WebKit to stop all in-progress GIF animations (on th...
Jason Spiro
Reported 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 .)
Attachments
Jason Spiro
Comment 1 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
Evan
Comment 2 2009-03-28 19:51:48 PDT
Please implement this! It's the only thing keeping me from google chrome.
Teun
Comment 3 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.
Keith Dawson
Comment 4 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.
Nelson Sproul
Comment 5 2009-12-03 07:36:53 PST
Dan Fabulich
Comment 6 2009-12-03 09:19:00 PST
This bug has been confirmed by popular vote. Can we get a radar ticket for this, please?
Simon Fraser (smfr)
Comment 7 2009-12-08 11:44:19 PST
See also bug 9767.
Simon Fraser (smfr)
Comment 8 2009-12-08 11:46:37 PST
Simon Fraser (smfr)
Comment 9 2009-12-08 11:52:00 PST
Sorry, <rdar://problem/3483064> is a Safari feature request. <rdar://problem/7171719> is the correct one.
Alexey Proskuryakov
Comment 10 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.
Dan Fabulich
Comment 11 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.
Dan Fabulich
Comment 12 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.)
Cody 'codeman38' Boisclair
Comment 13 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.
Brian K. White
Comment 14 2011-07-27 20:45:40 PDT
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.
Glen A.
Comment 15 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?
Alon Bar-Lev
Comment 16 2012-05-02 14:00:52 PDT
(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.
Graeme Hewson
Comment 17 2012-05-10 22:51:10 PDT
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?
Devon Sean McCullough
Comment 18 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.
Armin Nikdel
Comment 19 2019-06-01 11:03:45 PDT
This bug/feature request has been dormant for years. With rise of GIF animations, it is necessary for somebody to look into it. Currently lot of websites have to implement complicated javascript codes to provide a way to play and pause GIFs. It should be part of browser, an Javascript command call should pause and play GIF.
Nathaniel
Comment 20 2020-03-23 13:50:57 PDT
Please implement this - it is painful to be bombarded by repeating gifs that can't be paused.
Note You need to log in before you can comment on or make changes to this bug.