https://bugzilla.mozilla.org/show_bug.cgi?id=111373
Bugzilla
Quick Search
[ ]
* Browse
* Advanced Search
* Reports
*
* Documentation
* New Account
* Log In
Sign in with GitHub or
[ ] [ ]
[password ] [*] Remember [Log in]
* Forgot Password
[ ] [Reset Password]
[moz]
* Mozilla Home
*
* Privacy
* Cookies
* Legal
Please enable JavaScript in your browser to use all the features on
this site.
Bugzilla will be having a scheduled maintenance on February 05, 2022,
approximately 3:00 PM UTC . The maintenance should only take a few
minutes. Bugzilla may be temporarily unavailable during that time.
Copy Summary
[ ]
View V
* Reset Sections
* Expand All Sections
* Collapse All Sections
*
* History
*
* JSON
* XML
Open Bug 111373 Opened 21 years ago Updated 1 year ago
Don't allow animated favicons
Summary:
Don't allow animated favicons
Categories
(Firefox :: Tabbed Browser, enhancement, P3)
Product:
Firefox V
Firefox
For bugs in Firefox Desktop, the Mozilla Foundation's web browser.
For Firefox user interface issues in menus, bookmarks, location bar,
and preferences. Many Firefox bugs will either be filed here or in
the Core product. Bugs for developer tools (F12) should be filed in
the DevTools product. (more info)
See Open Bugs in This Product
File New Bug in This Product
Watch This Product
Component:
Tabbed Browser V
Firefox :: Tabbed Browser
For problems in the browser tab features or problems with the widget
itself.
See Open Bugs in This Component
Recently Fixed Bugs in This Component
File New Bug in This Component
Watch This Component
Version:
Trunk
Platform:
All
All
Type:
enhancement
Priority:
P3
Severity:
S3
Points:
---
Tracking
()
Status:
REOPENED
Status:
REOPENED
---
Mark as Assigned
Milestone:
Future
Iteration:
---
Project Flags:
a11y-review [---]
Performance [---]
Webcompat Priority [---]
Root Cause [---]
user-doc-firefox [---]
Fission Milestone [---]
Tracking Flags:
Tracking Status
relnote-firefox [---]
firefox-esr91 [---] [---]
firefox96 [---] [---]
firefox97 [---] [---]
firefox98 [---] [---]
People
(Reporter: cgushue, Unassigned)
Assignee:
Unassigned
Assignee:
[ ] Reset Assignee to default
Mentors:
---
QA Contact:
[ ] Reset QA Contact to default
Reporter:
# cgushue
Triage Owner:
# dao
CC:
82 people
References
(Blocks 2 open bugs,
URL
)
Depends on:
---
Blocks:
119597
1478597
120352
Dependency tree / graph
Regressions:
---
Regressed by:
---
Duplicates:
112188, 113166, 132498, 160240, 180261, 292471, 383516, 620052,
1358869
113761, 511928, 649784
URL:
animatedfavicon.com
See Also:
873217
Details
(Keywords: access)
Alias:
---
Keywords:
access
Whiteboard:
---
QA Whiteboard:
---
Has Regression Range:
---
Has STR:
---
Votes:
82
Bug Flags:
behind-pref [ ]
blocking-fx-sync1.7 [ ]
firefox-backlog []
sec-bounty [ ]
sec-bounty-hof []
in-qa-testsuite [ ] [ ]
in-testsuite [ ]
qe-verify []
Crash Data
Signature:
Security
(public)
This bug is publicly visible.
User Story
Attachments
(1 file)
patch v1 fryn
11 years ago : review- Details | Diff | Splinter Review
Bobby Holley (:bholley) mak
2.90 KB, patch : feedback-
Bottom |
Tags V
* Reset
Timeline V
* Reset
*
* Collapse All
* Expand All
* Comments Only
Chris Gushue
Reporter
[119] Description
*
21 years ago
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 to
display it.
Chris Gushue
Reporter
[119] Updated
*
21 years ago
Summary: animate site icons - animated site icons
Boris Zbarsky [:bzbarsky]
Comment 1
[def]
*
21 years ago
Imagelib.
Assignee: hyatt - pavlov
Status: UNCONFIRMED - NEW
Component: Tabbed Browser - ImageLib
Ever confirmed: true
QA Contact: blakeross - tpreston
Stuart Parmenter
Comment 2
[a17]
*
21 years ago
any bugs related to favicon are hyatt's :)
Assignee: pavlov - hyatt
R.K.Aa.
Comment 3
[f4d]
*
21 years ago
*** Bug 112188 has been marked as a duplicate of this bug. ***
Tim Powell
Comment 4
[bec]
*
21 years ago
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. :-(
Tim Powell
Updated
[bec]
*
21 years ago
Summary: animated site icons - animated site icons (favicons)
Chris Gushue
Reporter
[119] Comment 5
*
21 years ago
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
David Hyatt
Updated
[068]
*
21 years ago
Status: NEW - ASSIGNED
Target Milestone: --- - mozilla1.1
Boris Zbarsky [:bzbarsky]
Comment 6
[def]
*
21 years ago
*** Bug 113166 has been marked as a duplicate of this bug. ***
Boris Zbarsky [:bzbarsky]
Comment 7
[def]
*
21 years ago
Looks like favicons are not obeying the animation prefs at all (bug 113166)
eberry
Comment 8
[2c0]
*
21 years ago
*** Bug 113761 has been marked as a duplicate of this bug. ***
SineSwiper
Comment 9
[8af]
*
20 years ago
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?
Andrew Hagen
Updated
[29c]
*
20 years ago
Blocks: 119597
Greg Valure
Updated
[bbb]
*
20 years ago
Blocks: 120352
Jonas Jorgensen
Comment 10
[a75]
*
20 years ago
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)
David Hyatt
Updated
[068]
*
20 years ago
Target Milestone: mozilla1.1 - Future
Julien Cegarra
Comment 11
[ee5]
*
20 years ago
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 .2EUR
/jc
John Morrison
Comment 12
[c8c]
*
20 years ago
*** Bug 132498 has been marked as a duplicate of this bug. ***
Johannes la Poutre
Comment 13
[28b]
*
20 years ago
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.
Jeremy M. Dolan
Comment 14
[8e1]
*
20 years ago
*** Bug 160240 has been marked as a duplicate of this bug. ***
R.K.Aa.
Comment 15
[f4d]
*
20 years ago
*** Bug 180261 has been marked as a duplicate of this bug. ***
Niklas Dougherty
Comment 16
[5d2]
*
20 years ago
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...
dylang
Comment 17
[9cd]
*
20 years ago
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.
Niklas Dougherty
Comment 18
[5d2]
*
20 years ago
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).
Andrew Hagen
Updated
[29c]
*
19 years ago
Keywords: mozilla1.3, mozilla1.4
Andrew Hagen
Updated
[29c]
*
19 years ago
Keywords: mozilla1.3
Jo Hermans
Comment 19
[dd4]
*
19 years ago
*** Bug 199435 has been marked as a duplicate of this bug. ***
emmet
Comment 20
[198]
*
19 years ago
I have separated this general discussion bug from the specific instance of the
bookmark sidebar by Bug 199435
Sergey <> Sokoloff
Comment 21
[8f5]
*
18 years ago
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.
Jo Hermans
Comment 22
[dd4]
*
17 years ago
*** Bug 292471 has been marked as a duplicate of this bug. ***
Martin F.
Comment 23
[5f3]
*
16 years ago
Stopping the animation by pressing [Esc] like in-page GIFs would be useful.
Grick
Comment 24
[a16]
*
16 years ago
Has it been decided whether this should obey the already-existing animated gif pref, or will another pref be added?
Adam Guthrie
Updated
[23f]
*
15 years ago
Duplicate of this bug: 383516
Timwi
Comment 26
[694]
*
14 years ago
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.
Dan Harkless
Comment 27
[2ef]
*
13 years ago
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.
Sean Malloy
Comment 28
[e4f]
*
13 years ago
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.
Jo Hermans
Updated
[dd4]
*
13 years ago
Duplicate of this bug: 511928
Phil Ringnalda (:philor)
Updated
[2b6]
*
13 years ago
QA Contact: tpreston - imagelib
winterknight
Comment 30
[af8]
*
13 years ago
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.
Bobby Holley (:bholley)
Comment 31
[ac5]
*
13 years ago
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.
Jesse Ruderman
Updated
[d2d]
*
12 years ago
Assignee: hyatt - nobody
Michael Kohler [:mkohler]
Comment 32
[984]
*
12 years ago
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
Bob Jones
Comment 33
[472]
*
12 years ago
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.
Shlomi Fish
Comment 34
[f91]
*
12 years ago
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!
Bobby Holley (:bholley)
Comment 35
[ac5]
*
12 years ago
(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?
Joe Drew (not getting mail)
Comment 36
[7a4]
*
12 years ago
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.
Bobby Holley (:bholley)
Comment 37
[ac5]
*
12 years ago
(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: 12 years ago
Resolution: --- - WONTFIX
Timwi
Comment 38
[694]
*
12 years ago
You should have just reopened bug 383516, which was incorrectly marked as a duplicate of this.
Timwi
Comment 39
[694]
*
12 years ago
In fact, almost all of the supposed "duplicates" that link to here are now actually duplicates of bug 605197...
Susanne Jaeger
Comment 40
[c18]
*
12 years ago
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.
Dao Gottwald [::dao]
Updated
[d94]
*
11 years ago
Duplicate of this bug: 620052
(mostly gone) XtC4UaLL [:xtc4uall]
Updated
[def]
*
11 years ago
Duplicate of this bug: 649784
Glenn Maynard
Comment 43
[e92]
*
11 years ago
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.
winterknight
Comment 44
[af8]
*
11 years ago
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.
Mac
Comment 45
[807]
*
11 years ago
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?
Daniel Holbert [:dholbert]
Comment 46
[cd9]
*
11 years ago
(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.
Brian R. Bondy [:bbondy]
Comment 47
[47d]
*
11 years ago
Specifically:
http://en.wikipedia.org/wiki/Favicon#Browser_implementation
winterknight
Comment 48
[af8]
*
11 years ago
(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.
Alex Faaborg [:faaborg] (Firefox UX)
Comment 49
[ffb]
*
11 years ago
Reopening. Slight morph: there shouldn't be a preference and the animation should be disable by default.
Status: RESOLVED - REOPENED
Resolution: WONTFIX - ---
Bobby Holley (:bholley)
Comment 50
[ac5]
*
11 years ago
(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!
Glenn Maynard
Comment 51
[e92]
*
11 years ago
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.)
Alex Faaborg [:faaborg] (Firefox UX)
Comment 52
[ffb]
*
11 years ago
>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.
Joe Drew (not getting mail)
Comment 53
[7a4]
*
11 years ago
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
Bobby Holley (:bholley)
Comment 54
[ac5]
*
11 years ago
(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
Glenn Maynard
Comment 55
[e92]
*
11 years ago
(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; }
Bobby Holley (:bholley)
Comment 56
[ac5]
*
11 years ago
(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.
winterknight
Comment 57
[af8]
*
11 years ago
(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.
Timothy Nikkel (:tnikkel)
Updated
[064]
*
11 years ago
Component: XUL - ImageLib
Joe Drew (not getting mail)
Updated
[7a4]
*
11 years ago
Component: ImageLib - XUL
Bobby Holley (:bholley)
Comment 58
[ac5]
*
11 years ago
Attached patch patch v1 -- Details -- Splinter 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)
Dan Mellem
Comment 59
[76e]
*
11 years ago
(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 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;
+ }
Marco Bonardo [:mak]
Comment 64
[0d6]
*
10 years ago
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-
Kyle Huey (Exited; not receiving bugmail, old account, do not
use)
[d8b] Comment 65
*
10 years ago
How big are favicons (in bytes)? Data URIs increase memory usage (by storing the entire base64 encoded string in the URI), sometimes noticeably.
Marco Bonardo [:mak]
Comment 66
[0d6]
*
10 years ago
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.
Frank Yan (:fryn)
Comment 67
[def]
*
10 years ago
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-
Justin Dolske [:Dolske]
Comment 68
[109]
*
10 years ago
animatedfavicon.com?! *facepalm*
Bobby Holley (:bholley)
Comment 69
[ac5]
*
10 years ago
(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
Bobby Holley (:bholley)
Updated
[ac5]
*
10 years ago
Attachment #552232 - Flags: review?(gavin.sharp)
[:Aleksej]
Updated
[def]
*
9 years ago
See Also: - 873217
Russell Haley
Comment 70
[255]
*
9 years ago
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.
a2579537
Comment 71
[f87]
*
8 years ago
off-topic
Comment hidden (off-topic)
This is the most awful feature, after all the others, that FF has! Controlling the **** on the modern web is very difficult, and FF does not make this very easy.
Animated gifs are mostly reign-in-able, I think the pngs are a bit of a problem, but CSS animations (and fades and transitions and other shiny-shiny) required manual overriding (and a browser restart - what is this, spawn of Windows 98?).
Hell, even browser.tabs.animate is still animated when the user turns the stupidity off! Why can designers soooooo often not recognise that their views are subjective, and thus there is no right or wrong (unless the speaker thinks there is some superiority available to them)? When someone says they don't want animation it means no animations, not just a little bit, not just some things with an tedious UI, etc..
Animations make things feel slow, the user has to wait when really the machine could do things instantly. Maybe if you have no idea of the abstract nature of computers, and no desire to learn (woohoo for anti-intellectualism!), then animations provide useful visual cues? But the user is like that then anims are just **** and interfere. I know Mozilla is trying to get the success of IE (like sheer number of users is respectable!), and that to do so you have to wreck the products and dumb things down and optimise things for sponging middlemen (web2.0 is about computing not on the user's computer. Why do some FOSSers get drawn into the hype?).
Also, WTF is bugzilla doing blocking sign ups from privacy-enhancing services? It took me a couple of tries before I found a disposable email service that hasn't been blacklisted. The Google zero-privacy, must objectify all and everyone, policy contagious?
Daniel Holbert [:dholbert]
Comment 72
[cd9]
*
8 years ago
(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.
Glenn Maynard
Comment 73
[e92]
*
8 years ago
off-topic
Comment hidden (off-topic)
He was posting with a throwaway email, so he probably knows that he's flaming.
crxssi
Comment 74
[453]
*
7 years ago
(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.
laurens
Comment 75
[316]
*
6 years ago
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.
Alice0775 White
Updated
[def]
*
5 years ago
Duplicate of this bug: 1358869
Stephan Sokolow
Comment 77
[8f7]
*
4 years ago
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.
Simon Lindholm
Comment 78
[69a]
*
4 years ago
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.
Marco Bonardo [:mak]
Comment 79
[0d6]
*
4 years ago
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.
crxssi
Comment 80
[453]
*
4 years ago
(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.
Dan Harkless
Comment 81
[2ef]
*
4 years ago
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, a 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.
Dan Harkless
Comment 82
[2ef]
*
4 years ago
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? :-)
crxssi
Comment 83
[453]
*
4 years ago
(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.
Stephan Sokolow
Comment 84
[8f7]
*
4 years ago
*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.
Dan Harkless
Comment 85
[2ef]
*
4 years ago
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).
Benjamin Melancon
Comment 86
[b3b]
*
4 years ago
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.
dalias
Comment 87
[73c]
*
4 years ago
Doh, I missed sending this bug a birthday cake to celebrate it getting its driver's license.
crxssi
Comment 88
[453]
*
4 years ago
(In reply to Benjamin Melancon 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.
markham breitbach
Comment 89
[7e9]
*
4 years ago
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.
Bryan H
Comment 90
[149]
*
3 years ago
When this "bug" can legally purchase a Stout in the States, I will fix it.
Dave Townsend [:mossop]
Updated
[8f5]
*
3 years ago
Component: XUL - Tabbed Browser
Product: Core - Firefox
flying sheep
Comment 91
[da5]
*
3 years ago
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/
crxssi
Comment 92
[453]
*
3 years ago
(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.
Stephan Sokolow
Comment 93
[8f7]
*
3 years ago
(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.)
Rich Felker
Comment 94
[d9b]
*
3 years ago
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.
crxssi
Comment 95
[453]
*
3 years ago
(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.
Stephan Sokolow
Comment 96
[8f7]
*
3 years ago
(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.
Dao Gottwald [::dao]
Updated
[d94]
*
1 year ago
Blocks: 1478597
Severity: normal - S3
Keywords: access
Priority: -- - P3
Summary: don't allow animated site icons (favicons) - Don't allow
animated favicons
Ckat
Comment 97
[649]
*
1 year ago
advocacy
Comment hidden (advocacy)
please dont ruin any more fun and instead consider fixing actual bugs
You need to log in before you can comment on or make changes to this
bug.
Top |