Open Bug 111373 Opened 23 years ago Updated 5 months ago

Don't allow animated favicons

Categories

(Firefox :: Tabbed Browser, enhancement, P3)

enhancement

Tracking

()

REOPENED
Future
Accessibility Severity s3

People

(Reporter: cgushue, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: access, Whiteboard: [fidefe-quality-foundation])

Attachments

(1 file)

There should be a preference setting to be able to disable site icon animation.
It tends to be rather distracting with animation in the page tab and address
bar. The linked page is using <link REL="shortcut icon" HREF="favicon.gif"> to
display it.
Summary: animate site icons → animated site icons
Imagelib.
Assignee: hyatt → pavlov
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → ImageLib
Ever confirmed: true
QA Contact: blakeross → tpreston
any bugs related to favicon are hyatt's :)
Assignee: pavlov → hyatt
*** Bug 112188 has been marked as a duplicate of this bug. ***
Just a note that my bug (marked dupe) suggests that this should not be a 
preference. Animated site icons should be banned for the good of the user. 
Blinking and spinning icons in a bookmark list? Yikes!

For 2001112706 on Win2000 Mozilla ignores the image animation looping 
preference for animated site icons. :-(
Summary: animated site icons → animated site icons (favicons)
Tim: You're right, I'd prefer them to be completely disabled myself. I wouldn't
want it to follow the preference for regular animated icons, because that's
actually somewhat useful at times (well, not so annoying).

I assume this isn't Platform/OS specific? I know at least one person using
something different, and agrees with getting rid of animated site icons.
OS: Windows 2000 → All
Hardware: PC → All
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
*** Bug 113166 has been marked as a duplicate of this bug. ***
Looks like favicons are not obeying the animation prefs at all (bug 113166)
*** Bug 113761 has been marked as a duplicate of this bug. ***
I, for one, think the idea of animated favicons is kinda neat...on the URL bar.
 I can understand the bookmarks, however.  Hundred of spinning and bobbing icons
as you hit the bookmarks menu...ugh!  Maybe there's a way to go halfway on this
issue?
Blocks: 119597
Blocks: 120352
Changing summary so it doesn't sound like an RFE for /implementing/ animated icons.
Summary: animated site icons (favicons) → don't allow animated site icons (favicons)
Target Milestone: mozilla1.1 → Future
Wont that be better to allow just one loop (and for example no more than 20
frames in that loop) ? That way icons could have a little effect like a fade and
that wont  distracte users.

Just my .2€

/jc
*** Bug 132498 has been marked as a duplicate of this bug. ***
Just an observation with build 2002040203 / WinNT4:

if I load the favicon.gif (or how it's named) directly in the browser window,
the "loop only once" setting is obeyed. Going back to the offending web page has
now disabled looping in both the location bar and the tab (if appliccable).

So... the pref seems to be "sticky", after being triggered by rendering in the
main window. This effect might have to do with caching, as the animation gets
enabled again after browsing some more and then returning to the "animated page"
(all tried with URL from original bug report).

Oh yes, IMHO just one global "image animation" preference for Mozilla is fine.
*** Bug 160240 has been marked as a duplicate of this bug. ***
*** Bug 180261 has been marked as a duplicate of this bug. ***
I think you unleashed the demon when introducing site icons in Mozilla.
Logically, any image would do (GIF, PNG, MNG), as is the case for page elements.
Blinking and spinning backgrounds and buttons are just as annoying as ditto site
icons.

Site icons in bookmark lists... the concept is flawed to begin with, as it is
evident such a feature would hurt performance regardless of animation.

If the whole purpose of site icons is to further give some personality to a web
page, then animation could be a doubleplusgood extension of this very concept,
provided it is done in a cool way.

I toyed with an animated icon for a while, but only dropped it because I had no
way of making an MNG animation on a Mac. GIF animations suck as they only have
single bit transparency, which looks **** on a blue tab.

Anything can be both used and abused. The fact that something can be abused is
no reason for disabling a cool feature.

This said in defense of the animated site icon...
Niklas, your comment seems very tangental.  What exactly are you saying?

If you're wondering why icons are good, it allows easier differentiation in
Mozilla of tabs (especially when you have lots open).  Ditto for making
bookmarks quicker to navigate.
No, I am not wondering why site icons are good, I am stating that animated site
icons can also be good. I am stating that site icons, animated or not, can have
its uses in tabs and URL fields. I am stating that site icons, animated or not,
are probably not good to show in bookmark lists, but this fact shouldn't mean
that site icons cannot be animated at all (as comment 4 suggests).
Keywords: mozilla1.3
*** Bug 199435 has been marked as a duplicate of this bug. ***
I have separated this general discussion bug from the specific instance of the
bookmark sidebar by Bug 199435 
Please make it a preference. Personally I like animated web site icons very
much, in bookmarks toolbar and in menu.

And, making it a pereference, let animation be TURNED ON by default.
*** Bug 292471 has been marked as a duplicate of this bug. ***
Stopping the animation by pressing [Esc] like in-page GIFs would be useful.
Has it been decided whether this should obey the already-existing animated gif pref, or will another pref be added?
If a user sets image.animation_mode to "none", the expectation is that they won't see animations. I think we can all agree on that. Whether to allow animated favicons when image.animation_mode is NOT set to "none" is irrelevant to almost all of the bugs that were marked as duplicates of this one. If you want a discussion about this case, then I strongly suggest to have two separate bugs here, because the case where image.animation_mode is set to "none" is uncontroversial and should be fixed ASAP.
Please note that Martin F. filed a bug to have animated favicons properly obey the Esc key as per his comment #23 as Bug 392866.  That is also my desired solution for this.
Having a number of animated favicons is just as bad in the tabs as it is in the bookmarks folder; get six or seven spinning icons sitting just above the page content regardless of which tab you're reading is a seriously annoying distraction. All animated images served from a website should follow the animation preferences that the user set.
QA Contact: tpreston → imagelib
This bug is almost 8 years old. For perspective, Phoenix 0.1 will be 7 years old next week. I will look into fixing this bug, but I make no promises.
In general, animation starting/stopping is kind of broken, as I mentioned over in bug 502693. You might want to wait until that gets fixed before doing this, as it will probably be a lot easier.
Assignee: hyatt → nobody
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
I believe there should be a separate animation preference for favicons, with the same option as for regular animated images.

Animated images in webpages *can* be useful (for the rest, there's Adblock Plus :) but I don't want to see animation in my tab bar or address bar *at all*.

Currently, the only workaround (short of spending ages trying to create blocking rules) is to set browser.chrome.favicons to false and do away with them altogether. That's a bit extreme, TBH.
Wow! Such an old bug, an annoying one and it's still not resolved. I've noticed this bug for a long time and it's annoying. Hopefully, I'll dedicate some time to work on it, just before the 4.0 release. Die animated favicons! Die!
(In reply to comment #34)
> Wow! Such an old bug, an annoying one and it's still not resolved. I've noticed
> this bug for a long time and it's annoying. Hopefully, I'll dedicate some time
> to work on it, just before the 4.0 release. Die animated favicons! Die!

I think it's quite unlikely that this will ship with Firefox 4 given the timeline.

Joe - is this something we want? Would you take this for ff.next?
I don't think it's something we want in general. If this isn't handled by the general "don't animate images" pref, we should ensure that it is, though.
(In reply to comment #36)
> I don't think it's something we want in general. If this isn't handled by the
> general "don't animate images" pref, we should ensure that it is, though.

Ok, WONTFIXing.

Sorry about that Shlomi. :( I just don't want you to spend time on a patch that's unlikely to be taken.

Apparently favicons still animate with animation disabled, which is wrong. I've filed bug 605197, which we'd definitely take a patch for.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You should have just reopened bug 383516, which was incorrectly marked as a duplicate of this.
In fact, almost all of the supposed “duplicates” that link to here are now actually duplicates of bug 605197...
I think it should be a possible to handle animations in webpages and animated favicons (which are part of the user interface) different. I know pages where I want to see animated gifs without being distracted by moving favicons from other tabs.
Why is this WONTFIX?

I don't want to disable *all* animated GIFs.  I only want to disable animations in tabs, which are obnoxious and constantly distracting, even when I'm using other tabs.

I can't imagine that anyone actually wants to see this distracting garbage, though, or others like it: http://dhl-usa.com/

Please reopen this.  Animated tab icons are *blatently abusive*, and Firefox shouldn't allow them by default.
Glenn is right. This is a terrible bug, and should be fixed. 383516 and it's duplicates such as 605197 are only a half fix.
I feel like I want to vomit ( along with headache ) when I visit this website and my tabs are moving like a live creature. It is sad that I need the website and I am forced to visit it.

Why is this set to Won't fix? because users' opinion and requirements does not matter? 

Why an .ico file should contain gif and still be shown?
(In reply to Mac from comment #45)
> Why an .ico file should contain gif and still be shown?

Is it specified anywhere that favicons should be restricted to .ico files?  

AFAIK, Mozilla (along with IE/Opera/WebKit) support all image formats for favicons -- not just .ico.
(In reply to Mac from comment #45)

> I feel like I want to vomit ( along with headache ) when I visit this website > and my tabs are moving like a live creature. It is sad that I need the website > and I am forced to visit it.

I feel the same way. There is no excuse for animated favicons. This is a bug in Firefox that some sites are exploiting for attention. The only way to completely and safely prevent animated favicons is to disable favicons completely.

> Why is this set to Won't fix?

It's not clear, but it looks like a misunderstanding above. The developers might fix 605197, which is a dupe of 383516. I wouldn't count on it happening in the next few years though.

> because users' opinion and requirements does not matter?

It seems like that sometimes.

> Why an .ico file should contain gif and still be shown?

There aren't any official standards in play here. favicon is something Internet Explorer just started doing, and other browsers picked it up and extended it. .ico is just an extension, and not as relevant as the mime type for determining the file type. And lots of programs will open any file, and determine its type by its contents. It would be nice if we could identify and disable all gifs while allowing other types of favicons, though.

Whether or not this bug is ever fixed in Firefox, it would be nice to have an extension. I tried to fix this bug a couple of times, but the firefox code is so big and complex and windy, I just don't have that kind of time for a free project. I would, however, donate $10 to anyone who provides an extension that fixes this bug.
Reopening.  Slight morph: there shouldn't be a preference and the animation should be disable by default.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #49)
> Reopening.  Slight morph: there shouldn't be a preference and the animation
> should be disable by default.

Does "disabled by default" imply that there should be a way to enable it? Or just that we should kill animated favicons entirely?

This sounds fine to me personally. If UX wants this and we don't care about breaking compat, then it should be simple enough to do. I think it'll actually simplify some code!
Note that pages that have animated favicons without a presentable first frame are already broken; favicons are never animated in eg. the Bookmarks menu.  They'll be broken in other browsers, too: Chrome doesn't animate favicons.  http://dhl-usa.com's favicon shows up as a solid orange rectangle in both of these.

Aside, bug 653035 is related to this one.  (If it's implemented this way and someone really needs to reenable the animations for some reason, they could do it with userChrome.css.)
>Does "disabled by default" imply that there should be a way to enable it? Or just that we should kill >animated favicons entirely?

no way to enable

>If UX wants this and we don't care about breaking compat, then it should be simple enough to do.

If someone can name an actually legitimate usage of animated favicons that would be interesting on an intelectual level, but I'm nonetheless totally fine with breaking any existing expected compatibility.
I think what we want is an attribute on XUL images that makes them ignore the FrameChanged callbacks, in the same way that XUL trees currently don't ever redraw when frames change.

(I'm really not enthusiastic about adding yet another way to disable animated images inside imagelib.)
Component: ImageLib → XUL
QA Contact: imagelib → xptoolkit.widgets
(In reply to Joe Drew (:JOEDREW!) from comment #53)
> I think what we want is an attribute on XUL images that makes them ignore
> the FrameChanged callbacks

Specifically, we need a way for chrome to communicate to XUL that the image here shouldn't be animated:

http://hg.mozilla.org/mozilla-central/file/a0e3c589c8fa/browser/base/content/tabbrowser.xml#l3996

At least I think so. I haven't verified that this is, in fact, the implementation of the favicon in the tabstrip, but it sure looks like it.

And I think we can avoid doing anything fancy with the FrameChanged callbacks. I'm pretty sure we can just tell the image not to animate with this API here:

http://hg.mozilla.org/mozilla-central/file/a0e3c589c8fa/modules/libpr0n/public/imgIContainer.idl#l264
(In reply to Bobby Holley (:bholley) from comment #54)
> Specifically, we need a way for chrome to communicate to XUL that the image
> here shouldn't be animated:
> 
> http://hg.mozilla.org/mozilla-central/file/a0e3c589c8fa/browser/base/content/
> tabbrowser.xml#l3996
> 
> At least I think so. I haven't verified that this is, in fact, the
> implementation of the favicon in the tabstrip, but it sure looks like it.

I'm sure it is, as I've been using this in my userChrome for a while as a half-baked workaround for this:

.tab-icon-image[src $= ".gif"] { visibility: hidden; }
(In reply to Glenn Maynard from comment #55)

> I'm sure it is, as I've been using this in my userChrome for a while as a
> half-baked workaround

Marvelous.

The Imagelib folks are unlikely to work on this anytime soon, so I thought I'd list some concrete steps for anyone who wants to work on this:

1 - Talk to a xul peer (almost certainly bz) about designing an interface to inform XUL that an image should not be animated.
2 - Talk to a tabbrowser peer (gavin or dao probably) about using this interface from tabbrowser.
3 - If both sides sign off on something, implement it.
(In reply to Glenn Maynard from comment #55)

> .tab-icon-image[src $= ".gif"] { visibility: hidden; }

Holy ****! I wish I knew about that a few years ago. Thank you.

It only disables gifs in tabs. It still allows them in the urlbar. I've added another line to disable that, and so my userChrome.css has these lines:

/* Disable gif favicons in tabs and urlbar */
.tab-icon-image[src $= ".gif"] { visibility: hidden; }
#page-proxy-favicon[src $= ".gif"] { visibility: hidden; }

As far as I know, these are the only places that animated favicons are allowed, bookmarks and awesomebar just show the first frame.
Component: XUL → ImageLib
Component: ImageLib → XUL
Attached patch patch v1Splinter Review
It looks like I was wrong about the above approach. Because animation state is shared among all consumers of an image (ugh!), stopping animation for the favicon will stop it on any other content that happens to use the image. This isn't something we want.

Last night on IRC, gavin and I tossed around ideas for using extractFrame within XUL to make a static copy of the first frame using extractFrame(). It seemed like it would be messy though, and neither of us really felt like doing it.

I later remembered that this could be simplified a bit with the imgIRequest::getStaticRequest() API that smaug implemented for print preview. I think that this is a pretty viable option - we could add a 'static' attribute on XUL images that causes them to call getStaticRequest() on any images that come their way. But would require a minor change to the API, because getStaticRequest() returns an imgIRequest with the _current_ animation frame, rather than the first frame.

This morning I looked into the favicon service a little bit more. It turns out that the reason bookmark favicons don't animate is not that they use some antiquated xul widget without animation support, but that they're read out of the service. Internally, the service reprocesses all favicons into pngs, stripping out any animations in the process.

So it seems like a simple solution would be to just have tabbrowser read its favicon from the service. That's what this patch does. But let's see what gavin thinks.
Attachment #552232 - Flags: review?(gavin.sharp)
(In reply to Daniel Holbert [:dholbert] from comment #46)
> Is it specified anywhere that favicons should be restricted to .ico files?  

There are two different ways of setting the favicon - the IE way of requesting /favicon.ico as a 16x16 Windows icon file (or 32x32 or 48x48), or using a <link rel="icon"..., which can theoretically use any image file.

There are other icon files, such as <link rel="apple-touch-icon"... for when they save a bookmark as an application, but I don't think Mozilla uses any of those.
Fixing this would basically fix/WONTFIX bug 597860, bug 534862 and bug 392866 and possibly more.
Assignee: nobody → bobbyholley+bmo
gavin, can you suggest an alternate reviewer with more bandwidth?
Hrm. I'd have two slight concerns with this approach:

1) Last I checked, the favicon service only re-encodes images below a certain threshold (in bytes). So, say, a tiny image that just blinks wouldn't be re-encoded. And thus this doesn't fully fix this bug (although it might be "good enough"? seems simple enough).

2) I'd want to check to see if there's any visible jankyness with first setting the icon to the original URL, and then flipping it to the output from the favicon service. Seems like this could cause favicons to blink slightly when a page is loaded.

Let's have Frank take a look.
Attachment #552232 - Flags: review?(fryn)
Comment on attachment 552232 [details] [diff] [review]
patch v1

(In reply to Justin Dolske [:Dolske] from comment #62)
> 2) I'd want to check to see if there's any visible jankyness with first
> setting the icon to the original URL, and then flipping it to the output
> from the favicon service. Seems like this could cause favicons to blink
> slightly when a page is loaded.

I didn't see any flicker when testing this patch.

This doesn't prevent the favicon on about:robots from animating. If that's due to about:robots having special handling, that's okay.

Nit: tabBrowser should be spelled tabbrowser. (Simply convention.)

It seems like the code works fine from my limited testing, but I'm not confident enough to give it an r+ yet, since I'm not familiar with the favicon service. Dolske's first concern still needs to be addressed.

In case this approach doesn't work out, here's an alternate approach, albeit a bit heavy (since it creates temporary DOMElements):

             if ((browser.mIconURL || "") != aTab.getAttribute("image")) {
-              if (browser.mIconURL)
-                aTab.setAttribute("image", browser.mIconURL);
+              if (browser.mIconURL) {
+                let img = new Image;
+                img.onload = function() {
+                  let canvas = document.createElementNS("http://www.w3.org/1999/xhtml", "canvas");
+                  canvas.width = this.width;
+                  canvas.height = this.height;
+                  canvas.getContext('2d').drawImage(this, 0, 0);
+                  aTab.setAttribute("image", canvas.toDataURL());
+                };
+                img.src = browser.mIconURL;
+              }
Comment on attachment 552232 [details] [diff] [review]
patch v1

Review of attachment 552232 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/tabbrowser.xml
@@ +709,5 @@
>                  aURI = makeURI(aURI);
> +              var tabBrowser = this;
> +              var callback = {
> +                onFaviconDataAvailable: function(aURI, aDataLen, aData, aMimeType) {
> +                  var dataURL = tabBrowser.mFaviconService.getFaviconDataAsDataURL(aURI);

You don't want to do this, getFaviconDataAsDataURL will synchronously read the data AGAIN from the database, causing mainthread IO.

Either convert aData to a dataURI (avoiding any further db access), or set the icon url to "moz-anno:favicon:" + aURI that will still fetch from the database, but asynchronously. The former is preferrable (we may add an helper to the favicons service to do the conversion eventually)
Attachment #552232 - Flags: feedback-
How big are favicons (in bytes)?  Data URIs increase memory usage (by storing the entire base64 encoded string in the URI), sometimes noticeably.
about:robots icon is not replaced because we don't store icons to pages which history can't be stored (the list here http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsNavHistory.cpp#1353), thus the callback is not invoked.
The same will happen in private browsing mode or when history is disabled.

So this is probably not the best way to always stop the animation.

Fwiw, the favicons service resamples the icon if it's > 16*16*4 (32*32*4 on XUL Fennec) but that value may change in future, breaking this.
Comment on attachment 552232 [details] [diff] [review]
patch v1

(In reply to Marco Bonardo [:mak] from comment #66)

Ah, in that case, this doesn't seem like the right approach to fix this bug. :(

Thanks for your work on it so far, bholley. :)
Attachment #552232 - Flags: review?(fryn) → review-
animatedfavicon.com?! *facepalm*
(In reply to Frank Yan (:fryn) from comment #67)
> Ah, in that case, this doesn't seem like the right approach to fix this bug.
> :(

Alright, I appreciate everyone taking a look at it. :-)

My time is probably better spent on DOM-y things at this point, so I'm relinquishing the bug. If you want to work on this, feel free!
Assignee: bobbyholley+bmo → nobody
Attachment #552232 - Flags: review?(gavin.sharp)
See Also: → 873217
These animated favicons are a huge problem for laptops.  I just reduced Firefox's CPU usage from 21.6% to 2.8% by closing a single background tab with an animated favicon.
(In reply to a2579537 from comment #71)
> even browser.tabs.animate is still animated when the user turns the stupidity off!

That about:config preference is intended to control whether the tabstrip animates its open/close-tab events -- nothing more. (It's also not exposed in the UI anywhere, as far as I know. Poke at about:config preferences with caution, and without strong expectations about specific results, unless you know the details of the pref in question.)

That pref does seem to work fine for me, for the behavior that it actually controls.  Though it has nothing to do with this bug. If you have an issue with that pref's functionality, please file a separate bug.

> Also, WTF is bugzilla doing blocking sign ups from privacy-enhancing
> services?

Again, nothing to do with this bug; but I believe certain throwaway-email-services were blacklisted when bugzilla was crippled under an avalanche of malicious spam-comments coming from those services at some point over the past year or two.  Feel free to ask around in irc.mozilla.org #bmo for more details if you're curious.

Please see also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - your comments come off as quite hostile, and you're not likely to receive productive responses anywhere if you keep it up.
(In reply to Russell Haley from comment #70)
> These animated favicons are a huge problem for laptops.  I just reduced
> Firefox's CPU usage from 21.6% to 2.8% by closing a single background tab
> with an animated favicon.

And on thin clients, animation is a huge no-no.  It robs CPU and network resources, affects other users on multi-user systems, and becomes quite slow.  It seems people forget about people who run Firefox remotely...  and then there are just older, slower machines which are also suffering from needless, distracting, and annoying animation.

This issue is almost 14 years years old now and find it amazing there is still no preference to control turning off animated icons in the UI.  The related bug 605197 is interesting, but I do think it makes more sense to have a separate preference rather than just depend on only image.animation_mode=none but I will take anything I can get at this point.
20% CPU usage (27% compared to 7% when that tab is closed) to animate favicon on 2.7GHz Macbook Pro (FF 47.0.1) is very very high and drains a lot of battery.

IMO favicon animation is almost always just bad website design, but FF should not use 100s of MIPS to animate an 8bit sprite (!). Please fix, or allow disable.
As was pointed out in bug 1378939, a solution which could fix both this as well as meet several other needs within Firefox and, once more widely adopted, out on the web, would be a CSS property for disabling animation.
I forgot to make a note of it in that bug, but I opened a csswg-drafts issue for such a property: https://github.com/w3c/csswg-drafts/issues/1615. No real response though; I suppose it's not seen as very high priority.

With e10s the image cache is less of a problem for this bug, so I guess the approach in comment 56 should be viable again.
Note that with the new favicons service approach, the icon should be animated only in the tab, the rest of the UI should not get animated favicons.
(In reply to Marco Bonardo [::mak] from comment #79)
> Note that with the new favicons service approach, the icon should be
> animated only in the tab, the rest of the UI should not get animated
> favicons.

Any improvement is good, but I know I won't be happy until I can shut off all animation in my field of view, including the favicon animation in the active tab.  Of course all this pales in comparison to how much horrible, distracting, useless animation being done inside websites now with javascript :(  But most of the time those objects can be manually hidden or removed... something not possible with the favicon because it is part of the UI.
I agree with crxssi.  Further, this bug should be tagged as an accessibility issue.  Many people have unusual brain wiring that results in them having hypervigilance and little to no ability to employ selective attention.  Unlike most people, these folks can't "just ignore it" / "just tune it out", and the inability to stop animation in the field of view is a thus a serious problem.  

It's crazy that the longstanding ability to stop all animated GIFs (and PNGs) by hitting the Esc key was removed in Firefox some time back.  I use the add-on SuperStop to bring this back (as Shift + Esc), but it's a XUL/XPCOM add-on last updated in 2012, and will stop working next month with Firefox 57.  I am not aware of any WebExtension-based replacement, and I suppose that wouldn't even be possible until a CSS property regarding animation were added.  How about adding a Firefox-specific property until the CSSWG considers the proposal for a general version, à la -moz-user-select?  In the meantime, even for people moving to ESR or a Firefox fork to continue being able to use "legacy" extensions, SuperStop does not have the ability to stop animated favicons.

My preferred solution is to have image animations play by default, and then be able to instantly stop all of them on the page/tab with a keystroke, since animations are sometimes informational (e.g. looping video clips that constitute actual content on the page).  However, lacking that ability, one could go to about:config and set image.animation_mode = once.  This can still result in a ton of distracting animation, though (e.g. while scrolling through forum threads that use animated emoticons), since image animations will not stop until they get through all their frames (which sometimes takes quite a long time, if frame count and/or interframe delay are high) while visible in the window.  And even if one were able to tolerate that, setting image.animation_mode = once does not affect animated favicons, which keep looping forever.

With the above two solutions unable to stop animated favicons, a third possibility would be the ability to quickly switch off image animation globally on demand.  I use the QuickJava add-on to achieve this.  Unfortunately it, too, is a XUL/XPCOM add-on with no announced plans to make a WebExtension version.  Presumably much of the functionality (including animated image disabling) wouldn't be possible as a WebExtension anyway.  And, once again, this is still not a solution for people migrating to a browser version that continues to support traditional add-ons, since turning off QuickJava's "A" button does not stop animated favicons.

I hope the accessibility needs of users who do not have the ability to ignore distracting extraneous animations will be considered here, and some ability to stop animated favicons will be provided, whether it's implemented by making the existing solutions for stopping image animations apply to favicons as well, or whether it's implemented with a favicon-specific about:config setting.
Just wanted to add that I just discovered the BetterStop add-on, but it, like SuperStop, is unable to stop animated favicons.  Also notable is that the old ability to stop all animated images with Esc reportedly goes all the way back to Netscape version 1 (I've certainly been using it since the Netscape days).  Also, this bug was reported 16 years ago — any chance for movement before we hit the 20-year mark?  :-)
(In reply to Dan Harkless from comment #81)
> I agree with crxssi.  Further, this bug should be tagged as an accessibility
> issue.  Many people have unusual brain wiring that results in them having
> hypervigilance and little to no ability to employ selective attention. 
> Unlike most people, these folks can't "just ignore it" / "just tune it out",
> and the inability to stop animation in the field of view is a thus a serious
> problem. 

I never quite thought of it as an accessibility issue, but you are right, it probably could fall in the definition.  And it does seem I am one of those people that can't "just ignore it."  I wouldn't wish the issue on anyone, but it is nice to know we are not alone out there.... and there are probably a lot of us.
*raises hand*

Another person who can't "just ignore it" here.

I currently rely on the legacy "Toggle animated GIFs" extension to minimize the scope of the problem.
Thanks, guys.  Yeah, I don't have any statistics at hand right now, but I believe the "1% of users" that Mozilla believes are affected by this issue is a significant understatement.  And in any case, the goal of Accessibility is to make software usable by all, not just "the majority".  Note that most OSes have options to disable their use of unnecessary animations, and on Windows and iOS in particular, these are located under the Accessibility settings.  Similarly, W3C and Android accessibility guidelines require the ability to pause, stop, or hide looping animated elements.

The bug requesting that the ability to stop animations with a keystroke (without a XUL/XPCOM add-on) be restored, bug 825486, was not only closed as WONTFIX, but has been set so that normal Bugzilla users are prohibited from adding any comments, e.g. to provide reasoning why the developers should consider reopening it.  That strikes me as incredibly user-hostile; I've never seen a bug-tracker issue set that way before.  And of course opening a new bug would just be RESOLVED DUPLICATE of the WONTFIX.  This might even be seen as a contravention of the Americans with Disabilities Act, since Mozilla is U.S.-based.

The rationale for the WONTFIX was that web apps might want to use the Esc key; that's fine, but I think that's a far far more niche case than people who need to be able to stop animations.  And if you make the keystroke Shift + Esc, I think that tiny niche essentially disappears.  If it were really a concern, an about:config setting could certainly be provided to allow changing and/or disabling the keystroke (and an addable toolbar button could be provided so animations could be stopped even with the keystroke disabled).
Firefox Quantum 57.0.1 (64-bit) and distracting, annoying, utterly unwanted animated gif is moving when the tab is inactive as well as when it is active.  Please allow us to turn this off.
Doh, I missed sending this bug a birthday cake to celebrate it getting its driver's license.
(In reply to Benjamin Melançon from comment #86)
> Firefox Quantum 57.0.1 (64-bit) and distracting, annoying, utterly unwanted
> animated gif is moving when the tab is inactive as well as when it is
> active.  Please allow us to turn this off.

Mozilla added a relatively new setting, toolkit.cosmeticAnimations.enabled which is a great start (Bug 1352069), but unfortunately, it does not include several UI animations, including the topic of this bug.
Honestly, animated .favicon is the digital equivalent to standing on a table at the library, dropping your pants and noisily passing wind.

I would suggest that a better solution, instead of disabling animated .favicon is to completely refuse to load any site that uses a .favicon.
When this "bug" can legally purchase a Stout in the States, I will fix it.
Component: XUL → Tabbed Browser
Product: Core → Firefox

I think this can be closed. Firefox doesn’t support no-JS mode anymore, and it’s always possible to replace the favicon via JS (manually animating it), so even if using animated GIFs would be prohibited, people could still go the javascript route.

There’s easy-to-use libraries and everything: http://lab.ejci.net/favico.js/

(In reply to flying sheep from comment #91)

I think this can be closed. Firefox doesn’t support no-JS mode anymore, and it’s always possible to replace the favicon via JS (manually animating it), so even if using animated GIFs would be prohibited, people could still go the javascript route.

There’s easy-to-use libraries and everything: http://lab.ejci.net/favico.js/

Good find. So my question now shifts to- Why in the world would Firefox ALLOW javascript for/in favicon?

Instead of giving up on this, perhaps that ridiculous "feature" should be removed AND also honor the toolkit.cosmeticAnimations.enabled by disabling animated png/webp/gif/etc.

(In reply to flying sheep from comment #91)

I think this can be closed. Firefox doesn’t support no-JS mode anymore, and it’s always possible to replace the favicon via JS (manually animating it), so even if using animated GIFs would be prohibited, people could still go the javascript route.

There’s easy-to-use libraries and everything: http://lab.ejci.net/favico.js/

There are multiple extensions (eg. NoScript, uMatrix, etc.) which allow disabling JavaScript but, as of yet, I'm unaware of an extension which is capable of blocking GIF or APNG animation in favicons.

(In reply to crxssi from comment #92)

(In reply to flying sheep from comment #91)
Good find. So my question now shifts to- Why in the world would Firefox ALLOW javascript for/in favicon?

JavaScript is able to change a site's favicon. That's how things like the unread message notifications on GMail and Discord work.

Change it frequently enough and you've got animation. (Sort of like how, as a very stupid and inadvisable trick, you can reinvent Ye Olde Statusbar Marquee in the address bar by calling history.replaceState very frequently.)

Exactly what was said in comment 92. The reasoning in comment 91 is essentially "oops, we made this even worse, so that means now it's not a bug!"

Allowing sites to change their favicon via js is not a feature. It's a nuisance, and possibly a critical issue for users with certain disabilities. That capability, along with gif-based animation, should be blockable via configuration. Some of us do not care about "unread message notifications" being possible and consider them a distraction/annoyance.

No, blocking javascript in general is not a solution.

(In reply to Stephan Sokolow from comment #93)

JavaScript is able to change a site's favicon. That's how things like the unread message notifications on GMail and Discord work.

Ah, thanks for that info. So, although it might not be possible to disable JS controlling favicon, it still seems reasonable that we would want to restrict other, easily-controllable animations. No perfect outcome, but it is better than allowing ALL types of animation in something that really shouldn't be animated.

(In reply to Rich Felker from comment #94)

Exactly what was said in comment 92. The reasoning in comment 91 is essentially "oops, we made this even worse, so that means now it's not a bug!"

Allowing sites to change their favicon via js is not a feature. It's a nuisance, and possibly a critical issue for users with certain disabilities. That capability, along with gif-based animation, should be blockable via configuration. Some of us do not care about "unread message notifications" being possible and consider them a distraction/annoyance.

No, blocking javascript in general is not a solution.

I agree with crxssi on this front. I've yet to see someone go to the effort to animate a favicon using JavaScript, and I rely on unread message notification via favicon from sites like Discord, but, whenever I encounter a site using an animated GIF favicon, one of the first things I do is either leave or open up the DOM inspector and deal with the animated favicon manually.

In the era of legacy extensions, I relied on one called Toggle Animated GIFs which prevented animation in favicons and presented "click to play" behaviour for in-page GIFs but its author has yet to find a way to reimplement it as a WebExtension.

Blocks: 1478597
Severity: normal → S3
Keywords: access
Priority: -- → P3
Summary: don't allow animated site icons (favicons) → Don't allow animated favicons
See Also: → 1821864
Whiteboard: [fidefe-quality-foundation]
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.